开源可控云原生平台-MegaEase左耳朵耗子创业项目学习

陈皓，网名左耳朵耗子，也是小灰为数不多非常敬重的技术大牛，大家应该都认识吧。资深技术专家，骨灰级程序员，MegaEase创始人，有着20年以上的研发与管理经验。曾在阿里，亚马逊等公司任职，精通架构。此外在团队管理、项目管理，以及程序员的个人成长等方面也有自己一套独特的见解和方法。

今天我们来学习下大牛离开阿里后自主创业，创办MegaEase自主可控，开源的云原生平台项目的一些产品架构和核心能力方面的知识。

对于大牛创办MegaEase，网上有一篇专门的创业复盘专访，大家可以参考。

sohu/na/408676930_120780733

里面谈到很重要的一段，摘录如下：

在MegaEase这种技术类需求领域，竞争对手基本都是巨厂、巨头，老百姓都能叫出名字的那些家。至于竞争优势，我现在也时常有点梦幻的感觉，怎么对方就选择我们了呢？其实技术需求还是需要专业、专注的态度，还有专业的服务模式。MegaEase专注一件事，因此能打造出完整且有技术含量的服务模式。一方面，我们是架构师参与销售、打单、咨询、调研，而竞争对手大部分都是销售人员先行，大厂的那些技术大咖基本不可能参与售前，另一方面，我们不是卖产品给用户，我们是真正的赋能，与用户合作研发，在过程中“磨刀不误砍柴功”地提升用户工程师的技术能力，甚至帮助用户做2-3年的技术规划，这点别的公司没法做到！因为我们是国内为数不多的能把整个互联网分布式技术地图和路线完美说清楚的团队。

另外，对外采访中提到了创业信念的一小段说法个人也很赞同，即我要证明技术思维对比非技术思维的优势，希望MegaEase成为一家由技术人员、技术思维领导的出色企业。

最近几年，我们也看到大量的技术类人员出来创业取得了巨大的成功，这个不仅仅说是技术大V本身自带大厂光环，更加重要的还是在大型互联网公司大量的项目实践和案例积累，这些形成的技术服务能力才是外部客户真正看重的内容。

最简单的道理就是一个大集团企业要做数字化转型，自建能力开放平台或大中台，如果你的公司去应标，真正的说服力在哪里？最简单的硬实力就是你做过类似项目，而且可能比客户的高可用需求场景更加复杂。

云原生平台整体架构和项目分析

注意，在这里关于产品架构和功能特点的说明都来源于官方网站。

megaease/zh/

这个开源项目自己还没有试用过，这里仅仅只能够是通过网站提供的一些产品介绍材料进行初步的学习和分析。

开源云原生平台整体架构

虽然，现在所有的云平台都以能帮助企业提高软件的稳定性和性能来标榜自己。但是，我们知道，事实上来说，用户的应用架构才是决定稳定性和性能的关键地方。所以，只有做到了应用的云化架构，我们才能让软件架构达到最终的稳定性和性能。

然而，应用的云化架构还意味着：

扩展性。 应用层的服务会和基础层的平台一同扩展，而应用中的服务也很容易被编排和调度。服务化。 一个企业内部的游戏下载服务很容易对外服务，可以让企业对外提供SaaS化的平台服务。生态圈。 开放平台是生态圈的关键，把企业的服务以 Open API 这种方式对外暴露，可以让更多的第三方软件提供商的软件接入到我们的平台中，从而造就一个广阔的生态圈。

要让自己的架构变成一个云化的架构，这个挑战对于大多数企业来说挑战都非常的大。而对于MegaEase开源项目，希望达到的一个目标就是为大企业构建自主可控的云原生平台。将互联网关于云原生，技术中台的最佳实践引入到企业内部IT建设和数字化转型。

究竟是否在重复造轮子？

如果你详细浏览了项目和相关子产品的功能概述和介绍说明，会看到不断地在提为何重复造轮子，或者我没有重复造轮子这样的内容。

那么整个MegaEase开源项目究竟是否是在重复造轮子呢？

简单来说对于MegaEase项目并不是新创建了一个类似SpringCLoud，类似ServiceComb的微服务开发框架，或底层云集成技术平台。而是在考虑如何更好地整合当前已有的各种开源工具，开源技术使其形成一个完整的整体。

而这种整合需要的就是各种兼容和适配，增加原有微服务，业务应用本身的平滑迁移能力。增加对整个微服务应用后期的管控治理能力，提升系统可观测性。

对于各种开源项目的整合和适配，这件事看起来并不复杂，但是真正做起来往往需要大量的项目实践和经验积累。举个简单的例子，当前配置中心就有Eureka，Nacos，Consul多种实现方式，那么我当前的前面能否做到完全兼容适配，能够快速地从某种配置中心在不修改代码，或者极少配置修改的情况下迁移为另外一个配置中心。

或者当我原来已经采用了SpringCLoud来进行微服务开发和微服务治理的时候，如果我们当前希望实施Istio的服务网格，我能否做到完全平滑迁移？

包括底层技术服务的选择也同样道理，类似的消息中间件本身有RoketMQ，ActiveMq，RabbitMQ多种实现方式，那么我能否做到灵活适配多种消息中间件。某天你发现不希望用ActiveMq了要迁移到RabbitMQ，能否做到平滑和零成本迁移？

Easegress

全功能型的流量调度和编排系统

Easegress （之前叫Ease Gateway） 通过API网关技术，可以在不改一行代码的情况下，最大限度地帮助后台服务扩大系统可用性和稳定性，并且可以增加整体的性能。其可以让企业在快速业务增长的同时不用对整个技术架构进行大改造，以赢得并抓住稍瞬即逝的商业机会。

Easegress 不仅仅只是一个7层的API Gateway， 也可以是一个Service Mesh的边车，而且，Easegress可以和很多的第三方软件集成（比如：Kubernetes Ingress, KNative FaaS, Eureka/Consul/Etcd/Nacos），从而完成更为强大的功能。

注：实际来看Easegress核心就是一个API网关，同时也可以做为Kubernetes Ingress的实现方案。当前Kubernetes Ingress除了最早的Ngnix，Kong网关也推出了Kong Ingress网关实现，Easegress只是一种新的实现方式。

对于Easegress网关，个人理解没有必要和ServiceMesh边车放到一起，这本身就是两种完全不同的实现思路。估计文中希望说明的是Easegress网关的核心流量调度，代理，安全，负载均衡，链路跟踪等能力可以下放到Sidecar边车中实现。

就当前网站发布的功能清单来看，并没有太多值得一谈的地方。

唯一的还是和Kubernetes Ingress Controller 集成，和主流的服务注册中心Eureka, Consul, Etcd, Nacos的集成能力。包括通过和Kubernetes Ingress Controller 集成可以更方便的实现蓝绿发布或灰度发布能力。

而对于服务代理，API流量调度，服务路由，安全，负载均衡，限流熔断，链路监控，API服务注册接入等能力都是API网关提供的标准能力。

安全API网关一个发展趋势就是增加API接口服务的编排能力，在网站功能说明里面也看到高级功能提供了后端API聚合调用，后端API流程编排等功能，但是估计离真正的API服务编排能力还有差距，对于API编排能力需求可以参考我前面发布过的文章。

Ease Mesh

高效，Java生态的服务网格治理

EaseMesh是一个更好的服务治理的解决方案，它是完全基于服务的视角进行增强和治理，致力于实现更好地诊断服务运行时的问题和监控服务状态。它还具有丰富的服务治理功能。EaseMesh专注于Java领域。为Java应用提供最低的迁移成本。它符合Kubernetes标准，易于与基于Kubernetes的解决方案进行集成。

简单来说EaseMesh就是一个基于ServiceMesh服务网格思路的微服务治理方案，这个和Istio类似，估计也是底层集成的各种开源软件，但是文字提到的一个好处就是无侵入式设计，特别是对于对Java Spring Cloud应用程序的迁移无需任何代码修改，只需要进行少量的配置更新。

而对于其它能力，类似流量编排，服务注册发现，灰度发布，限流熔断，可观测性都是标准的ServiceMesh服务网格开源实现提供的功能。

为什么要重新发明一个轮子？

文中也提到重点是与Spring Cloud生态系统兼容： 在Spring Cloud生态系统中开发的微服务有自己的服务注册/发现系统，目前，主要的服务网格解决方案（如：Istio）使用 Kubernetes 领域技术。因此，与 Java Spring Cloud 领域有冲突，并且让 Java 开发者需要放弃Java的相关生态。EaseMesh 旨在使 Service Mesh 与 Java Spring Cloud 完全兼容。

同时进一步提高集成可观察性，目前基于 Kubernetes 服务网格只能看到入口/出口流量，它不知道服务/应用中发生了什么。因此，结合Java Agent技术，我们可以拥有观察服务/应用内部和外部的全部能力。

从网站提供的架构图可以看到。

实际在传统Mesh方案的Sidecar基础上增加了JavaAgent代理。简单来说Sidecar开发者可能是透明和无感知的，但是对于JavaAgent或SDK代理包，对于开发者是可见可感知的。

在Sidecar基础上再增加一个Agent代理，个人理解应该是不影响当前主流的Istio开源方案的修改，而是在当前开源方案的外部再增加了一层代理和适配。这个思路本身应该是没有问题的，可以很好的解决前面谈到的迁移和兼容性问题。

Ease Service

原生开发框架Ease Service 基于 Spring Cloud / Spring Boot 等开源软件通过标准开放的技术帮助用户更容易地进行整个微服务服务架构，其中主要集成了很多的服务治理，弹力容错，关键中间件，服务运行数据收集，以及日志、异常等统一开发，从而达到企业级可用的工程方案和能力。

注意这里不是单独又从头开发了一个类似SpingCLoud的微服务开发框架，而是基于SpingCLoud的微服务开发生态，对外围大量的开源工具，技术服务能力进一步整合。

比如对各种开源服务注册中心，配置中心，服务链监控，限流熔断解决方案的整合等。也包括了对主流技术服务，如消息，缓存等能力的整合。

整合这些内容有无意义？

简单来说还是看整合到哪个程度，如果整合到可以平滑地从一个注册中心迁移到另外一个注册中心，从一个消息中间件迁移到另外一个消息中间件，那么这种整合和适配本身有意义，但是这层必须足够轻量，不能太重而影响到本身的性能。

当然在这个整合中，还包括了对日常开发的一些最佳实践，技术组件的整合，比如日志管理，系统和权限管理，基于Swagger的API接口开发和管理，这些内容本身你在使用微服务开发框架的时候也是在做这些事情。

在谈微服务开发框架的时候谈得最多的就是SpingCLoud微服务生态体系，但是整体微服务发展到今天，从开发态到运行态，从运维到管控治理，诞生了诸多的围绕微服务的开源工具和技术，包括注册中心，配置中心，限流熔断，消息中间件，缓存，服务治理，服务链监控等，基本每个技术点都有多种开源技术实现。

在上面的很多工具里面你会看到大部分是管控治理工具，而非微服务开发态的工具，因此我一直以来也强调将开发态和运行态，运维治理态全部分离。

即我只需要用最小的Spingboot来开发微服务模块并暴露Http Rest API接口即可。而且在开发态我不应该考虑任何治理相关的内容，不会因为考虑治理管控而增加额外的注解，配置文件或扩展类代码实现。开发应该专注于业务功能和逻辑的实现，不应该将管控治理复杂度引入到开发阶段。

这也是ServiceMesh服务网格所倡导的一个关键方式，包括Sidecar边车对开发者都应该是透明的，开发者只需要按标准开发微服务，所有后续管控治理，监控运维的能力都应该是自动附加上去的，而且可以灵活配置。

Ease Stack

微服务编排和调度Ease Stack 主要帮助用户管理整个系统的服务架构的编排和运行时的调度，其不但可以通过一个预先定义好的架构清单来一键部署整个架构，并且可以在运行时对整个架构中的各个服务进行调度。

所谓架构定义，就是用户只需要定义好一个架构中各个服务的构成，其中包括，服务的实例数量，需要的资源，部署方式（Docker），以及相关依整性，等。Ease Stack 可以通过这个定义文件启动整个架构。这对于需要创建环境的场景非常的简便易用。

每一个服务在其生命周期中有很多的状态，如：部署、就绪、更新、伸缩、故障、销毁……等，自动化运维就是要自动化地维护好服务的这些状态。Ease Stack 可以方便地对整个架构中各个服务的全生命周期进行有效的管理。

可以看下以上内容，核心还是围绕微微服务的应用PaaS平台，实际是构建在K8s+Docker之上的一层适配。增加了应用管理，微服务模块管理，应用生命周期管理，接口管理，DevOps持续集成和交付等方面的内容。

对于服务弹性伸缩和服务故障隔离，故障恢复等本身应该是容器云PaaS平台提供的基础能力，Ease Stack应该是在基础能力基础上进行了扩展。

这也正如网站文档描述的，EaseStack是一种两层服务编排。下层是服务，上层是堆栈。而下层则是委托给目前业界成熟的解决方案，例如Kubernetes和Mesos。上层尽量让下层透明，专注于整个栈调度。