Microservice Governance in Focus: What’s EDAS?
Xu Jingfeng, nicknamed Daofeng at Alibaba. Xu is a senior development engineer at Alibaba who is responsible for the R&D of Alibaba service governance frameworks. Xu specializes in microservices, service governance, and software design.
This article is the first article in a multi-part series on microservice governance. In this article, we will take a look at Alibaba Cloud’s Enterprise Distributed Application Service (EDAS), and discuss what exactly it is and why you may want to use it.
What Is EDAS?
When people ask me what I do at Alibaba, I used to answer: “I am mainly responsible for the R&D and commercialization of the Dubbo, High-speed Service Framework (HSF), and Spring Cloud Alibaba microservice frameworks at Alibaba.” If you are familiar with Alibaba Cloud, you probably know that we provide many Platform-as-a-Service (PaaS) products. Among them, I am primarily responsible for the development of EDAS. If you are new to Alibaba Cloud, you may be confused by so many product names and terms, such as Enterprise Distributed Application Service (EDAS), Microservice Engine (MSE), ACM, and OAM. When I got my hands on EDAS at the very beginning, I was annoyed by these terms and acronyms too. However, as I gradually grew to understand them, these cloud products became as familiar to me as Redis, database, and message queuing. In this article, I will introduce EDAS, an Alibaba Cloud product.
EDAS is a PaaS platform for application hosting and microservice management. It provides full-stack solutions such as application development, deployment, monitoring, and O&M. It supports Apache Dubbo, Spring Cloud, HSF, and other microservice runtime environments, helping you easily migrate applications to Alibaba Cloud.
To start this article, we will look at the core capabilities of EDAS, which include application development, deployment, monitoring, and O&M. In this article, I won’t be able to cover all of the capabilities of the entire PaaS platform. Instead, I will go deeper into the capabilities related to EDAS and microservice governance.
Why Use EDAS?
In the preceding figure, I have associated different microservice framework deployment methods with cloud computing methods to help you understand them better.
Among them, the “seeds” are the easiest components to understand. The open-source tool Apache Dubbo is used as a microservice framework and deployed on machines in user-created data centers. This approach is generally adopted by small- and medium-sized companies and requires dedicated O&M engineers to build operating systems and design network topologies. This is also the practice of most companies before the emergence of cloud computing.
In the real world, turning seeds into wheat is done by a farmer. No one sows seeds simply because they want to eat bread for lunch. This is why many Internet startups could not accept this traditional method. If you want to launch a product shortly, the first step is not to build a data center. Instead, companies turn to Infrastructure as a Service (IaaS). Many cloud computing companies provide cloud servers, such as Alibaba ECS instances, to solve basic hardware problems, and the rest can be done by R&D engineers. This means that programming skills are no longer as necessary in business development. In the IaaS phase, you can use ECS instances to deploy databases, deploy Redis, and deploy Dubbo nodes. If a problem occurs on a server, you can try to solve it simply by submitting a ticket to the cloud vendor, which greatly reduces your own O&M costs. Meanwhile, this allows your R&D engineers to focus more on business development.
Many Dubbo users are in the “seed” and “wheat” stages. Many people told me that their companies used Dubbo on Tencent Cloud. Certainly, there is no problem with this approach. Open-source frameworks are accessible to any cloud vendor. This is also true for Pivotal’s Spring Cloud and the Alibaba-led Dubbo. However, why do we have to go another step to the “flour” stage?
If we take Dubbo as an example, we can see some of the problems with open-source frameworks. For example, open-source frameworks give priority to the universality of functions and provide less support for individual needs such as phased release. Open-source frameworks find it especially difficult to support more advanced functions. For example, end-to-end tracing on Dubbo is frequently asked about after each Dubbo Meetup.
Some companies have their own infrastructure teams. Although they use the open-source Dubbo program, they have the ability to modify it. For example, Dangdang and Koala have their own branches for iteration. However, I believe that the priority of their extensions is to serve the scenarios of their respective companies.
Yet, there is another problem: Open-source products have bugs. Sometimes, if you find a bug and report it to the community, you have to wait for others to review and merge requests. This means it will take some time for the bug to be fixed. This is another important reason why many companies maintain their own R&D branches and have their own maintenance teams. So far, you can clearly see the disadvantages of “wheat”. But, how are these problems solved in the “flour” stage?
In the figure, I placed EDAS at the “flour” stage mainly for the following reasons:
The IaaS layer solves the relevant problems in a better way. EDAS allows you to manage the application lifecycle, including elastic scaling, throttling and degradation, and graceful online and offline, without needing to purchase servers.
In terms of microservices, it supports mainstream microservice frameworks such as Dubbo, Spring Cloud, and HSF. In addition, it enhances microservice capabilities. It also provides many commercial features, such as a white-screen service governance interface, distributed tracing analysis, phased release, outlier removal, service throttling, and high registry availability. In the future, EDAS will support more features such as distributed transactions and gateways.
Alibaba Cloud runs a dedicated team to ensure the stability of microservices so that customers can focus on more important work.
In my opinion, to produce, it is best to start from “flour”. You can cook anything you want from flour. Similarly, EDAS does not restrict the format of your products.
The History of EDAS Microservice Support
Alibaba Cloud has been considering how to attract users to our services for some time now. There are too many Alibaba Cloud services to consider here, so let’s limit ourselves to microservices. Some years ago, when EDAS was in the public beta stage, its main microservice framework was HSF. If you are familiar with HSF, you know that it is a proprietary microservice framework used within Alibaba Group. Over the years, it has supported the stable operations of all Alibaba products during the Double 11 Shopping Festival. After HSF proved its value in Double 11 and earned the endorsement of Alibaba, it was natural that EDAS would provide support for HSF. Currently, it works like this:
If Dubbo users want to migrate to the cloud and use EDAS, they have to use Alibaba Cloud’s HSF framework to rewrite their business code. However, this is costly. This remains a problem even when HSF is used for new businesses.
From the perspective of developers, the open-source Dubbo community is very active and provides detailed documentation. If you encounter a problem, you can usually find a solution through an Internet search. HSF, in contrast, is a closed-source framework. Even internal Alibaba users do not always know much about HSF. When an error occurs, you have to submit a ticket or consult the Q&A group for the solution. This is due to the fact that users cannot see the source code. Despite the stability of HSF, users may worry about hosting their code in a black box.
Many cloud platforms have similar problems. Migrating businesses to the cloud often involves the migration of a company’s technology stack. As you can imagine, this is a costly procedure.
With Alibaba’s relaunch of the open-source Dubbo service, EDAS began to support open-source Dubbo. This solved many of the preceding problems. Dubbo users who are in the “seeds” or “wheat” stage can take advantage of the numerous enhancements provided by EDAS without modifying a single line of code.
Next, we made Spring Cloud Alibaba open-source, and EDAS was fully compatible with it. Now, both Dubbo and Spring Cloud applications can be migrated to the cloud, where they can be used with EDAS.
Open Source, Commercialization, and Cloud-native
In the section above, we can see the approach adopted by cloud vendors. Dubbo and Spring Cloud Alibaba were the first products to be made open-source under Alibaba’s direction. They have received preferential support compared to other commercial cloud products. This approach was not only adopted by Alibaba. To name some of other vendors, Huawei made ServiceComb open-source, Ant Financial made Sofa Stack open-source, and Tencent made Tars open-source. All of these companies have their own cloud platforms and coincidentally encourage their users to migrate to their own microservice frameworks. The open-source ecosystem has cultivated user habits and grown very influential.
Integrating open-source SDKs has gradually become the consensus approach among cloud vendors. However, open-source SDKs are vendor-specific. Despite, this is still a major step forward because open-source products do not trap users. Instead, users can easily turn to whichever cloud vendor as long as they want. Compared with using SDKs provided by cloud vendors, using open-source SDKs is a more modern practice.
At this point, it was inevitable that someone would put forward the concept of cloud-native. While there are so many open-source SDKs, we actually need a single set of standards that everyone complies with. This is the basic mission of cloud-native. As the saying goes, third-class programmers write code, second-class programmers write frameworks, and first-class programmers define standards. Currently, there is no single standard for cloud-native open-source SDKs. However, some people have already proposed this idea, and those who are interested can learn more about OAM proposed by Alibaba.
Difficulties in EDAS Microservice Governance
As mentioned earlier, EDAS is not only a runtime container for running microservice frameworks. It also provides many enhanced capabilities for microservice frameworks as well. Before we look at the details of these capabilities, let’s first take a look at the difficulties facing EDAS microservice governance.
- Difficulty 1: EDAS supports a variety of microservice frameworks, including Dubbo, Spring Cloud, and HSF.
- Difficulty 2: There are multiple versions of each microservice framework:
- For Dubbo, EDAS supports versions 2.5, 2.6, and 2.7.
- For Spring Cloud, EDAS supports versions later than D.
- Difficulty 3: Traditional service queries require access registries, but there are a large variety of registries that are used by users:
- Zookeeper
- Nacos
- Eureka
- Difficulty 4: EDAS supports two deployment modes:
- ECS JAR package deployment
- Kubernetes image deployment
- Difficulty 5: We need to take the migration problems and transformation costs of existing users into account.
To summarize the above difficulties, many of the preceding factors must be taken into account in the implementation of EDAS microservice enhancements. When a trade-off is necessary, we try to solve as many pain points as possible and save users from having to make too many modifications.
Implementing EDAS Microservice Enhancements
The code that users deploy in EDAS uses open-source SDKs. EDAS also promises that users will not need to modify their code. So, how can we enhance microservice capabilities? Well, the JDK Instrument mechanism is the perfect solution to this problem. Readers who are familiar with distributed tracing analysis frameworks such as Pinpoint and SkyWalking should be familiar with this technology. A long time ago, I wrote an article about it: Java Insights — Instrument Mechanism.
With the help of a demo, this article showed how non-invasive aspect-oriented programming (AOP) can be implemented through the Instrument mechanisms.
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;
}
}
To assemble this class, the first step is to write a GreetingTransformer class, which is inherited from java.lang.instrument.ClassFileTransformer.
MicroServiceAgent
In addition to the aforementioned Transformer, we also need a container for loading it.
public class MicroService {
public static void premain(String options, Instrumentation ins) {
ins.addTransformer(new MicroServiceTransformer());
}
}MicroServiceAgent is the agent mounted to the end user's JAR runtime environment. For more information about how to load the agent, check out the article I've mentioned above, which provides a full demo and tutorial. This article will mainly look at the assembly mechanism.
Like AOP, the EDAS microservice enhancement logic uses non-invasive mounting to provide enhanced logic. This process requires agents to be adapted to each different version. This way, we can achieve service query, phased release, distributed tracing analysis, and outlier removal.
Summary
This article has introduced the microservice capabilities of EDAS and is intended for the audience who are not familiar with EDAS. EDAS is a commercial cloud product. However, by looking at its development history, we can see some of the patterns in software architecture evolution. These insights can help us better understand future trends in technological development.
