EDAS 是什么

有很多读者问我在阿里是做什么的，我一般会回答：“我在阿里主要负责 Dubbo、HSF、SpringCloud Alibaba 这几个微服务框架研发和商业化相关的工作”，这样回答，如果对方是 Java 开发，一般都能知道个大概。熟悉阿里云的朋友会了解到阿里云上有很多的 PaaS 产品，我主要就是负责开发 “企业级分布式应用服务 EDAS” 这款产品；不熟悉阿里云的朋友，会对阿里云上一堆产品、一堆名词感到奇怪，什么 EDAS、MSE、ACM、OAM… 我开始接触 EDAS 时，也是吐槽了一下这次名词，但随着逐渐了解，也就觉得这些云产品像 Redis、DB、MQ 这些东西一样亲切了。这篇文章将围绕 EDAS 这款阿里云云产品进行介绍。

企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）是一个应用托管和微服务管理的 PaaS 平台，提供应用开发、部署、监控、运维等全栈式解决方案，同时支持 Spring Cloud、Apache Dubbo（以下简称 Dubbo ）、HSF 等微服务运行环境，助力您的各类应用轻松上云。

可以从简介中提取出 EDAS 的核心能力：应用开发、应用部署、应用监控、应用运维。我这一篇文章自然是没办法介绍整个 PaaS 平台的能力，而且说实话，应用部署和应用监控等等能力也都是我同事们开发的，我真的一无所知，想介绍都难，所以在设计到细节时，我会主要介绍 EDAS 和微服务治理相关的那部分能力。

为什么用 EDAS

上图中，我将微服务框架的不同部署方式和云计算进行了绑定，以方便下面的介绍。

“种子”用户最容易理解了，例如使用开源的 Apache Dubbo 作为微服务框架，部署在自建机房的机器上，通常以中小公司为主，会有专门的运维搭建操作系统，设计网络拓扑，这也是云计算之前大多数公司的玩法。

但大家都知道，在现实生活中，“种子”变成“小麦”一般是农民伯伯的活，应该很少有人会因为想吃一个馒头，而去播撒一波种子的。例如很多互联网创业公司肯定接受不了这种玩法，想要尽快落地产品，第一步一定不是搞一堆机器，于是 IaaS 成了他们的救星，很多云计算公司提供了云服务器（ECS），解决了基础硬件问题，剩下的东西研发工程师都能搞定，所以“我有一个很好的 idea，就差一个程序员了”就变得流行了起来。在 IaaS 阶段，可以用 ECS 部署数据库，部署 Redis，部署 Dubbo 节点，机器出了问题可以提工单给云厂商，大大减少了运维成本，可以让研发人员更加专注在业务开发上。

很多 Dubbo 用户都是在“种子”和“小麦”阶段，还有人跟我说：我们公司在腾讯云上使用 Dubbo。老铁没毛病，开源框架没有强制跟任何云厂商绑定，Pivotal 的 SpringCloud 和 Alibaba 主导的 Dubbo 都是如此。可是，那我又有什么理由去进阶为“面粉”阶段的用户呢？我从 Dubbo 微信交流群的一些讨论去尝试回答这个问题：

请教大家一个问题，开源的 Dubbo 控制台有一个 xx 的问题，大家有遇到吗？

• 请教一下大家，Dubbo 的限流你们是怎么做的？
• 有没有人做过 Dubbo 的全链路跟踪的？
• Dubbo 的灰度发布有人在生产实践过吗？
• Dubbo 的分布式事务怎么做？
• Dubbo 的网关怎么做？
  ······

以 Dubbo 为例，大家可以看到一些端倪，开源框架也会存在一些问题。例如开源框架优先考虑的是功能的普适性，对例如灰度发布这种定制化的需求支持较少，且功能越高端，越难以支持。再例如 Dubbo 的全链路跟踪，基本上是每次 Dubbo Meetup 之后收集到的高频问题。有一些公司有基础架构团队，虽然使用的是开源 Dubbo，但他们有能力去进行改造，例如当当、考拉都拉了自己的分支在进行迭代，但我相信，他们自己的扩展也一定是优先适配各自公司的场景。还有一类问题，开源产品也会存在 bug，有时候自己定位出了 bug 提给社区，还得等其他人 review & merge request，必然会有时间成本，这也是很多公司自己拉分支自己维护的重要原因。说了这么多，其实都是在说“小麦”的缺点，“面粉”阶段又是如何解决这些问题的呢？

我在图中将 EDAS 这款阿里云的产品定位在了“面粉”阶段，主要原因便是：

IaaS 层解决的问题，它都解决了，甚至做的更好。EDAS 甚至不需要用户去购买机器，可以进行诸如：弹性伸缩，限流降级，优雅上下线等应用生命周期的管理
在微服务侧，它支持 Dubbo、SpringCloud、HSF 等主流的微服务框架，并且对微服务能力进行了增强。有很多商业化的特性，例如：白屏化的服务治理界面、分布式链路追踪、灰度发布、离群摘除、服务限流、注册中心的高可用…等等，并且随着后续的迭代，会继续支持分布式事务、网关等特性
背靠阿里云，有专门的团队保障微服务的稳定性，让专业的人做专业的事
我认为”面粉“是一个恰到好处的阶段，你可以烹饪成面包、面条、馒头，却又不会束缚你的产品形态。

EDAS 支持微服务的发展史

在阿里云的角度，如何吸引用户使用阿里云的服务呢？阿里云的服务实在太多了，还是来看微服务这个点。在 N 年前，EDAS 刚刚公测时，EDAS 主打的微服务框架是 HSF（High Speed Framework），熟悉它的朋友知道 HSF 是阿里集团内部使用的自研微服务框架，在历年双 11 支持整个阿里各个产品的平稳运行，有了双 11 这样量级的考验和阿里的背书，EDAS 支持 HSF 也就成了理所当然的事。这时候玩法是这样的：

如果是 Dubbo 既存用户想要上云使用 EDAS，就必须要改用 HSF 框架改写自己的业务代码，这个迁移成本是很高的。那如果是全新的业务使用 HSF，是不是就没有这个问题了呢？也不尽然。站在开发的角度，开源 Dubbo 的社区非常活跃，文档详细，遇到问题时，搜索引擎也基本能提供解决方案。但 HSF 不同，它是一款闭源的框架，即使是阿里内部用户，可能对其也是一知半解，遇到问题，只能借助于工单、答疑群解决，看不到源码是原罪。尽管 HSF 非常稳定，但用户把自己的代码托管在一个黑匣子中，多多少少会有所顾忌。

很多云平台都有类似的问题，业务上云往往意味着迁移技术栈，这个成本可想而知。

随着阿里重启了 Dubbo 的开源，EDAS 开始支持了开源 Dubbo，这一下子解决了很多上面提到的问题。对于那些处于”种子“、”小麦“阶段的 Dubbo 用户而言，使用 EDAS 不需要修改任何一行代码，即可获得 EDAS 承诺的诸多增强能力。

紧接着是 SpringCloud Alibaba 的开源，EDAS 也提供了 100% 的兼容。至此，Dubbo 和 SpringCloud 应用上云，EDAS 都能够 cover。

开源与商业化与云原生

从刚刚的发展史可以发现云厂商的一个玩法，Dubbo、SpringCloud Alibaba 最早都是由阿里主导开源的，在商业化云产品上都得到了优先的支持，不仅阿里这一家这么玩，华为开源了 ServiceComb，蚂蚁开源了 Sofa Stack，腾讯开源了 Tars，这几家都有各自的云平台，基本都会让用户迁移至自家的微服务框架。开源一方面是培养了用户习惯，积累影响力，一方面也是在为商业化铺路。

对接开源 SDK 逐渐成为了云厂商们的共识，只不过这里的开源 SDK 现如今没有统一，各家都有各自的玩法。不过这已经是一个很大的进步了，因为开源不会绑架用户，哪一天这家云厂商用的不爽了，随时迁走。相比使用云厂商提供的 SDK 来说，使用开源 SDK 这个理念不知道先进到哪里去了。

说道这里，不免会有人提出云原生的概念，开源 SDK 实在太多了，如果只有一套大家都遵守的规范就好了，云原生大概就是在做这么一件事。俗话说的好，三等码农写代码，二等码农写框架，一等码农定规范。但目前来说，还没有一统江湖的”云原生开源 SDK“，但已经有人再按照这样的思路再推进了，有兴趣的可以去了解下阿里提出的 OAM。

EDAS 微服务治理的难点

前面我们介绍到 EDAS 不仅仅是作为一个跑微服务框架的运行时容器，还为微服务框架提供了很多增强能力。科普完发展史之后，下面对微服务增强的细节进行介绍，但在此之前，为了不让读者知其然而不知其所以然，我先梳理下 EDAS 微服务治理的难点。

难点一
EDAS 支持的微服务框架种类多，目前支持三种微服务框架：Dubbo、SpringCloud、HSF。

难点二
微服务框架版本多：

• Dubbo 支持 2.5.x，2.6.x，2.7.x
• SpringCloud 支持 D 以上的版本

难点三
例如传统的服务查询，需要访问注册中心，但用户使用的注册中心种类多：

• Zookeeper
• Nacos
• Eureka

难点四
部署形态多，EDAS 支持两种部署形态：

• ECS Jar 包部署
• K8s 镜像部署

难点五
需要考虑存量用户的迁移问题和改造成本。

总而言之，EDAS 微服务增强的实现方式必须要考虑以上众多因素，在不得不进行 trade off 时，也应该尽可能解决较多的痛点，避免用户进行过多的改造。

EDAS 微服务增强实现

用户部署在 EDAS 中的代码使用的是开源的 SDK，EDAS 又承诺用户不需要改动代码，那是如何做到微服务能力增强的呢？满足这个要求的正是 JDK 提供的 Instrument 机制，熟悉 pinpoint 和 skywalking 等分布式链路追踪框架的读者应该对这个技术不会感到陌生。很久之前我曾经写过一篇文章对它进行过介绍：JAVA 拾遗 – Instrument 机制。

借助一个 Demo，通过 Instrument 来实现无侵入式的 AOP。

MicroServiceTransformer

public class MicroServiceTransformer implements ClassFileTransformer {

    @Override
    public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
        if ("org/apache/dubbo/config/ReferenceConfig".equals(className)) {
            System.out.println("microservice improve");
        }
        return null;
    }
}

对类进行装配的第一步是编写一个 GreetingTransformer 类，其继承自：java.lang.instrument.ClassFileTransformer。

MicroServiceAgent

除了上述的 Transformer，我们还需要有一个容器去加载它。

public class MicroService {
    public static void premain(String options, Instrumentation ins) {
        ins.addTransformer(new MicroServiceTransformer());
    }
}

MicroServiceAgent 便是最终用户的 Jar 运行时挂载的 agent。具体如何加载 agent ，可以参考上述的文章链接，有完整的 demo 和教程。这里主要是为了引出装配机制。

EDAS 的微服务增强逻辑便如同 AOP 一样，利用无侵入式的挂载，以达到增强的逻辑，这个过程需要 agent 对不同版本进行逐一的适配，从而实现服务查询、灰度发布、分布式链路跟踪、离群摘除等能力。

总结

本文其实也是一个主观视角，从一个对 EDAS 一无所知的角度，侧重于 EDAS 的微服务能力介绍了一遍 EDAS。EDAS 本身是一个商业化的云产品，但结合开源我们可以从它的演进历史看到一些软件架构演进的规律，这对于我们把握今后的技术发展趋势也有一定的指导意义。

作者信息：
徐靖峰（花名：岛风），GitHub ID lexburner，阿里巴巴高级开发工程师，负责阿里巴巴服务治理框架的研发工作，关注微服务、服务治理和软件设计等领域。