MegaEase 究竟在做什么？

MegaEase 究竟在做什么？ by MegaEase

2021-09-09 业界对Cloud Native的解读很多，我们做的东西也相对基础和通用，能够用在多种不同的场景，并提供各式各样的技术方案，所以，大家都感觉我们做的东西太多，什么都在做。好多人会时不时的问我们到底在做什么，解决什么问题，以及我们的产品的核心技术是什么？今天我们把大家一直以来的疑问汇总一下，做个十问FAQ。

Q0: MegaEase要帮用户解决的核心问题是什么？

关于用户的核心问题，在这个时代，从业务的发展趋势来讲，整个数字化进程正在从“企业侧”转型到“用户侧”。

企业侧的数字化 - 主要是指企业做自己内部的IT需求，比如：ERP，CRM，OA，MIS，进销存，财务、HR、项目管理、审批流程…等等这些企业提升自己精细化管理和运作效率的数字化。
用户侧的数字化 - 主要是为了满足外部用户需求，增强用户的体验等，比如进行用户营销活动。所以，用户侧的技术要求是满足和感知用户的需求变化。手机App，自助服务，推荐系统，对接用户的生活和工作的场景……等等，这些都是用户侧的重要需求功能。

今天，企业如果不在进行用户侧的数字化转型，那么就会失去行业竞争力。用户侧的数字化，需要快速地满足用户的侧的需求，进入用户的场景，收集相关的数据，以及感知用户的需求变化。

所以，满足用户侧的数字化就需求底层的IT基础设施满足如下的这几个特性：

快速满足和适应用户快速变化的需求。这就需要更快的开发迭代速度，于是，需要整个IT团队可以做到把一个大的需求拆解成更小的碎片，然后并行上线（这需要微服务的架构），另外，在上线流程上，除了需要快速的生产流水线，还需要一个实时上线系统，因为很多用户侧的功能只能让用户来测试（这需要像灰度发布或A/B测试这样的系统）。
能够进行大规模的用户在线活动。比如一些像双11这样的营销活动，或是一些生活和工作场景。这都需要我们的系统有更高的性能和更快的响应，需要能够处理高并发流量，能够随时进行水平伸缩，以及对所有应用服务在流量适应上的管理。
整个系统能够运行的更为的稳定，有更高的SLA。并行快速上线，处理高并发，分布式，都会让企业的整个运维变得很复杂，所以，需要我们的底层平台，能够支持应用层面的高可用，服务冗余，以及更好的服务治理。需要我们把故障当成功能直接设计在整个架构中。
建立生态，进入场景，接入更多的数据。数据是数字化进程中非常重要的东西，用户侧的数字需要感知用户的数据，所以，需要进入更多的场景，为了进入更多的场景，这需要企业有一个自己开放的生态，开放平台，OpenAPI，大数据平台，就成了基中的关键技术。
更为自主可控以及更低的成本。对于上面的这几个系统，对于大多数企业来说，成本门槛都非常高，没有一个专业的研发团队或是整体架构师，以及大量的研发经费的投入，基本是不可能完成的，所以，用户需要更低的成本的技术方案。

所以，这一整套的系统，并不是可以简单的用一些开源软件或是找几个系统集成商就可以搭建出来的，其需要有自顶向下的设计和规划，以及大量专业的软件技术和方案构成，这并不是一般企业可以完成的。

MegaEase在过去的几年里积累了一整套的这样的技术底层和相关的解决方案，我们可以很容易的让用户享有一个精良设计、标准开放、而且还是低成本自主可控的技术平台，助力用户快速便捷地进行新型的数字化转型。

Q1：MegaEase的技术方向和核心能力是什么？

MegaEase的方向是Cloud Native的方向，Cloud Native就是把云计算的核心技术拿出来直接无缝地集成到应用层，让我们的应用Natively就是Cloud。这个时候，对于用户来说，无论上不上云都已经是云了。

举个经典的例子，Google上世纪90年代把自己的搜索引擎架在了廉价且不稳定的x86 + Linux的机器上（连服务器都不算），整个搜索引擎依然可以稳定的运行。这是因为软件架构做得好。所以，Google因为自己的这个实践向业内发布了三篇分布式的论文，而这三篇论文直接引领了整个技术架构的变迁。从这个例子，我们可以看到，对于云计算来说，软件和应用架构才是真正给企业带来能力的重要特性。用一句比较夸张的话来说，只要软件架构做的好，基础资源就变的不是很重要了。

所以，Cloud Native所带来的时代变革是——把云计算从以前以资源型的方式转向了以应用和服务的方向。所以，像Serverless、Service Mesh、Kubernetes、API Managment、MicroService，整体架构观测型……全部都是在说应用服务层的事，而不再是基础资源了。

但是，Cloud Native的技术是非常的繁杂纷乱，而且门槛也比较高，而且在实际应用上离企业的需求和痛点还是有一定的差距。（注：下面这的技术图并不完整）

然而，对于用户来说，除了纷乱复杂之外，还会发现，用上了这些技术后，还是没有解决他们的问题，而且还引入了更多的新的问题。依然不能高并发，开发速度还是不够快，运维更复杂了，故障也更多了，感觉成本还更高了……

怎么把这些技术零件拼装起来，而且能够打造成一个企业级的架构，这个是MegaEase过去几年一直在努力积累和沉积的。

一个好的系统架构的核心就是要有统一精良设计的控制和调度系统，这个是架构和系统集成的本质不同。

云计算本质上来说就是调度。调度需要很多的控制系统。
通过流量调度、资源调度和服务调度这三种调度控制系统可以让整个架构性能、稳定性和可运维性有非常大的提升。
通过开源再加上一个有良好的顶层设计的架构模型，我们才能真正达到所有的用户侧转型中的所有的技术基础能力。
我们的能力和优势是做云原生的软件架构，而不是系统集成。

系统集成几乎所有的软件厂商都可以完成，但是云计算和云原生架构则并不是。几乎所有的公司都可以用Cloud Native来标榜自己，但是只有少数的公司才会拿真正的技术能力来标榜自己。

MegaEase 更多的是用技术能力来标榜自己，比如：一行代码不改做秒杀，我们可以支持用户超高并发的场景。我们可以让用户获得更快的故障处理能力，可以让用户进行全链路的灰度发布和完美的无侵入式的生产线全链路压测，以及真正可用的灰度发布系统，高可用的中间件架构、跨数据中心的多活和部署系统……

我们的核心技术能力和优势有这么几点：

完整的无侵入式技术和对主流开放技术兼容，让用户的改造应用成本降到0。
让用户获得能力的同时还降低整个 IT 成本至少一半以上。
没有厂商锁定，所有的MegaEase的技术全是标准开放的开源软件，永不”魔改“。

Q2：这些东西找个高级工程师花2个月用开源一搭不就完了？

是的，只要花点时间，大家可以使用这些开源软件搭出一套系统，但是，仅仅只是搭出来而已，一旦需要更为高级的整体划一的企业级应用。比如，全链路的灰度发布，快速故障定位，生产线上的完全无侵入的全链路压力测试，高并发的大规模流量处理，完整并可以相互配合的的服务治理，流量调度和资源调度。从而让企业可以更快的发布，更稳定更高可用，并可以随时做高并发的大规模营销，异地多活，……等等。这些就不是一个高级工程师花1-2个月可以搞出来的了。基本上来说，不投入一个有丰富经验和技术高度的资深架构师，再加上七、八个资深工程师干个2-3年，基本上来说很难做出来，这里还是有比较大的研发费用的投入。

另外，我们花了大量的时间和精力在研究“无侵入”式的技术，我们希望用户不改任何一行代码就可以拥有顶级互联网公司的技术能力，这个高标准的要求让我们必须要做到下面的这几个事：

不重新发明轮子，兼容于现有的主流技术。比如：Java的Spring 生态。
使用多种无侵入式的技术。比如：Java的字节码注入，Side Car，网关……等。
新老技术架构的兼容和连通性。这样我们可能通过建立“新城区”的方式来完成“老城区”的改造。

通过这些技术，我们可以很容易地为用户建立一套先进的技术架构和基础设施，而企业用户利用这些技术架构和基础设施，可以很容易在上面做面向用户侧数字化的开发，而无需关心整个系统架构所带来的复杂性，使得用户一行代码不改拥有Cloud Native 的能力。

Q3：Easegress与其它网关有啥不一样？

有很多不一样，最重要的是下面两个点：

首先Easegress 并不仅是一个反向代理，而是一个云原生流量调度器。相当于AWS Open API Gateway 或是有Kubernete Ingress 特性的真正的以服务为视角的云原生网关。现有的一些API网关基于反向代理的nginx做的，他们可以完成一些网关上的事，但是可扩展的能力一般，也不是云原生的方式。
用户代码的扩展性是非常重要的。基于Nginx的网关在代码扩展性上只有两个选择，一个是C语言，一个是Lua语言，前者太底层，后者表达力不足。很难扩展更为丰富的业务逻辑。而Easegress的扩展能力非常强，有Go插件 + WebAssemebly + FaaS 的三种不同级别的扩展能力，想像空间很大。（参看：《用 Easegress + WebAssembly 做秒杀》）

下图是我们对一个云原生网关的理解，以及相关的技术选型。对于一个技术的扩展性来说，只有三种方式：

自身语言级的的扩展。只要是静态语言，都需要重编译，重新部署和重启。
外部调用式的扩展。现在这种方式在云原生下一般是通过FaaS来完成。
内嵌动态语言的扩展。比如：使用Lua或是WebAssembly。

正因为这样，我们在Github上开源的两周内就够得了1.5K的星，现在开源三个月了，有了近4K的星。而且社区的参与度还不错——我们过去四年，整个团队提交了400+的PR，现在才3个月，就有150+的PR，10+的Contributor。在关注者中，有近1/3的来自海外其它国家。

更多细节可以参看：《下一代服务型流量网关》

Q4：EaseMesh和Envoy/linkerd/Istio服务网格有啥不同？

EaseMesh 拥有真正意义上东西向流量调度（真正的跨服务，端到端），这意味着依托在EaseMesh的成熟的东西向流量调度上，可以让用户用一行代码不改直接有服务治理、服务监控、调用链跟踪、流量着色、一行代码不改做真正的基于用户侧属性的灰度发布，以及一行代码不改完美的全链路压力测式等高级的企业级的解决方案。

EaseMesh 是完全兼容Java技术栈的，而现有的Service Mesh则和用户的现行成熟方案冲突，需要用户去做适配和迁移，并放弃这样的技术栈。

EaseMesh 和 EaseMonitor 可以完美整合，打造了一个真正面向服务的体检和急诊特性的可观测性能力。（具体可以参考EaseMonitor章节的描述）这些都是是市场一些ServiceMesh 方案完全不可比拟的。

下图是一个对比较图表，比较了成熟的Java企业级的一个技术栈的对比。

我们可以看到，现有的Service Mesh基本上是完全基于Kubernetes的架构，这会逼着用户做在架构上做一个二选一。而EaseMesh则不需要，我们是完全兼容Java Spring Cloud的Service Mesh，可以让用户同时拥有两边的优势。

下面这个表格是 Spring Cloud 生态和现有的 Service Mesh 生态的子系统对比。

子系统

Spring Cloud 生态系统

Service Mesh 生态系统

服务注册和发现

开发简单方便，只需一个简单的注解。支持不同的服务注册系统。开发者很容易在本地搭建一个开发环境来完成编码和调试。

基于K8s的Service机制，提供自己的Registry来同步数据。开发者需要了解Kubernetes，开发环境不易搭建。

弹性和容错

Resilience4j 的官方集成提供了完整的容错机制。但是服务需要与SDK集成。

通过使用边车方式的架构，它是一种非侵入式容错机制，对服务完全透明。

可观测性

Spring Cloud 内置、spring mirco-meter、zipkin 等。所有service-inside 指标、跟踪和日志都可以轻松收集，并且通过javaagent 字节码注入的方式，对开发人员完全透明。

通过sidecar机制，它可以监控入口或出口通信。如果没有服务内部的可观察性，服务跟踪可能是不完整的。

流量调度

Spring Cloud 只有一个非常基本的流量调度。例如，负载均衡基于Ribbon（从最新版本中移除）

更多的流量调度方案，金丝雀部署，蓝绿都能优雅的完成。

我们希望，有这么一个系统可以兼有两边的优势，这就是EaseMesh在干的事。更多细节可参看这篇文章《与 Spring Cloud 完全兼容的服务网格可以干出什么样的事？》

Q5：EaseMonitor 和 Jaeger/Zipkin/Skywalking 有什么不同和又有什么优势？

EaseMonitor不仅仅只是一个调用链跟踪系统，其主要是做整个技术架构的“体验”和“急诊”，对整个分布式云原生架构做整体的可观测性。可以算是一个“统一监控系统”。

对于云原生的整体可观测性有如下的一些重点：

需要解决的问题是

“急诊”- 快速故障定位
“体检”- SLA报告 + 容量分析

几个核心思想

从服务的角度进行观测，而不是从中间件或是资源的角度。
CMDB - 应该是以服务的角度而不是资源的角度
中间件或是基础资源的性能应该是从服务侧的角度，而不是资源侧
所有的资源都应该围绕着服务和API
不是仅仅只是收集更多的监控数据，而是需要关联数据，数据不关联则没有意义。
需要找到这样的关联：
从API -> 服务调用 -> 应用日志 -> 中间件使用 -> 底层资源的数据关联
能够说清楚一些事情，如：
说清楚某台服务器会影响对外服务的哪几个API
说清楚某个外围服务是否会影响核心服务
需要关联的数据有
基础资源的Metrics（如：CPU，Memory, I/O，Network…）
中间件的Metrics, Logs（如：JVM、Redis、MySQL、Kafka、Proxy/Gateway…）
应用的 Metrices（如：吞吐量，响应时间，错误率，等等）
应用的 Logs（如：Access Log, Application log, Throughput, Latency, Error…）
API的调用链跟踪（需要穿过应用内的异步调用，消息中间件）

所以，EaseMonitor主要解决的数据关键和数据分析。而不是一个个割裂的监控系统。

EaseMonitor底层使用的组件，如数据采集telegraf/filebeat，数据总线Kafka，时序数据库InflexDB/Promethus，搜索数据库ElasticSearch，调用链协议Zipkins，都是非常主流和常用的监控协议，用户基本上来说不需要改造基础设施，只需要通过配置修改监控的数据格式，然后，剩下分析，关联，展示，急诊，体验，报警……等的事情就交给EaseMonitor了。

一句话，我们主要做有精良设计的统一监控系统，不是一个系统集成出来的东西。

Q6: 你们的全链路压力测试 EaseLoad 是怎么做的？

先说一下在生产环境做全链接压力测试的的难题。其最重要的就是——测试数据隔离。在生产线上做测试不能影响到生产业务，所以，你没有办法用生产的数据做测试，所以，你需要先伪造很多测试数据。所以，

测试数据都需要有一定的标签，或是做“影子表”以便测试完后删除。
对于一些关键的中间件，比如数据库、缓存，消息队列，你也要做一定的隔离。比如，使用不同的实例，可是使用不同的topic，不同的表，等等
所以，这些都是对应用有侵入性的，应用需要知道哪些是测试数据，哪些不是，因为还需要对测试做一些服务的mock，还可能要把数据路由到不同的中间件上。

这些技术难题都给在生产线上做压力测试带来了非常大的难题——要有非常大的改造成本。

EaseLoad 完全是一个我们在做 Service Mesh 的一个副产品。我们在做EaseMesh的时候，发现通过其中的无侵入式技术，我们可以非常完美的做到在生产线上的全链路压力测试，这其中完全不需要改造代码，只需要增加一定的服务器资源，对一些服务进行无侵入式的Mock，在测试完后，可以把数据和资源完美销毁，完全符合云计算和云原生的特征。

下面是一个示意图

我们可以看到 EaseMesh 进行了以下的工作：

首先，我们可以克隆这些服务所依赖的所有中间件（DB、Queue、Cache等），我们称它们为 "影子中间件"
其次，EashMesh为所有的服务部署测试服务，我们称它们为 "影子服务"。并可以对一些服务进行Mockup。
然后，EaseMesh将“影子服务”的中间件访问重定向到“影子中间件”。
然后，EaseMesh调度测试流量到“影子服务”和“影子中间件”。
最后，我们可以安全而轻松地删除所有的“影子服务”和“影子中间件”，并释放相关的服务器。

在不改变任何用户源代码的情况下，EaseMesh为生产中的性能测试带来了完美的解决方案，它是方便、简单和安全的。

Q7：是不是必须要上K8s，没有上K8S的系统我们是怎么处理的？如传统系统。

如果用户使用k8s系统的话，会获得最佳的工程能力。我们认为，不能一味的迁就这些老旧的系统，帮助用户提升工程能力和引领用户升级到更为先进的技术栈上是我们的价值观。所以，如何帮助用户通过K8s来进行更为科学和先进的管理和运维，让用户成长是我们的核心目标。

今天，几乎所有的公司，不分传统还是互联网都已经在尝试或是使用k8s以及云原生架构。所以，这个是技术的行业趋势。我们相信，k8s最终有可能会成为一个基础设施打在操作系统中，让未来的所有需要Cloud技术的企业都无法避开。

对于一些老旧系统，分成两种，一种基本没有什么需求要添加的，这类系统，不动就好了。另一种则有很多需求需要加的，那么我们还是建议使用微服务分布式的架构来重写，因为重写可以获得更快的开发速度，一味的兼容只会导致技术债要还的利息越来越高，未来这个技术债务的利息只会越来越大，用户的在这些系统上的维护成本只会越来高，动作只会越来越慢。软件本身是需要升级的，这些老旧的系统只要还有新的需求，就应该在适时的时候被重构或重写。

所以，与其花时间兼容老旧系统，不如把这些时候花在怎么还技术债上，这也是我们的一个技术价值观。我们有一些很不错的业务层面的合作伙伴可以帮助用户进行相应的应用改造和迁移。

Q8：是替换了全部还是替换了部分模块，用户是否需要改造?

如果用户用的是主流开放的技术（比如：Java Spring boot 2.x），那么用户基本上来说是不用改造的，而且我们花了很多心思和精力在零成本改造的技术，我们还要在这条路上精进下去。另外，再配合上“新城区”和“老旧区”的方式来兼容于存量系统，可以让用户更为灵活地按自己的计划进行迁移或改造。

如果用户使用的技术是封闭、不开放或是不标准的技术，这个只能通过一个“防腐层”的架构进行兼容，让这些老旧的技术不侵入到新的技术中，然后用户可以找到正确的时间更换为更为开放，更为标准的技术上来。

总之，我们所有的技术方案，还有我们的产品设计的第一准则，永远都是尽可能要把改造成本降到最低直到为0。

Q9：部署和接入你们的系统需要花多少时间？

我们给自己定的KPI是2个小时，这个2小时包括的我们的系统部署以及用户的接入时间。当然，实际情况下，用户的系统需要按计划有步骤的迁移。这里的2个小时，说的是每一次的改造和迁移时间，并不是整体的时间。这里除了需要我们把我们的产品和相关的工具，以及标准和开放的技术，共同来完成的。我们也相信，只有开放和标准才可能给用户带来最大的技术红利。

在近期我们给某个银行的应用做的PoC的测试，用户只花了10几分钟修改了一下配置，然后就顺利接入到我们的系统里了，全栈监控、灰度发度、流量调度、服务治理、弹性伸缩、高可用……一应俱全，用户只是给我们一个jar包，用我们的脚本做成一个Docker镜像就好了，接入就是这么简单。

最后，大家如果还有什么问题，欢迎留言中是发邮箱给我们 service@ megaease.com

qiwihui / pocket_readings