This article is the first in a series on microservices Governance, explaining what EDAS is. This series of articles is based on the micro-service practice of Alibaba Cloud’s commercial product EDAS “Product official website >>”. If your team has strong micro-service governance ability, we hope our practice and thinking behind micro-service governance can provide you with some reference.

What is the EDAS

When many readers ask me what I do at Alibaba, I usually answer, “I am mainly responsible for Dubbo, HSF, SpringCloud Alibaba, the development and commercialization of micro-service frameworks”, which gives you a general idea if you are a Java developer. Those who are familiar with Aliyun will know that there are many PaaS products on Aliyun. I am mainly responsible for the development of the product “enterprise-level distributed application service EDAS”. If you are not familiar with Ali Cloud, you will feel strange about a bunch of products and nouns on Ali Cloud, such as EDAS, MSE, ACM, OAM… When I first came into contact with EDAS, I made a joke of the term, but as I got to know it, these cloud products became as familiar as Redis, DB, MQ and so on. This article will focus on the introduction of EDAS, a product of Aliyunyun.

Enterprise Distributed Application Service (EDAS) is a PaaS platform for Application hosting and micro-service management, providing full-stack solutions for Application development, deployment, monitoring, operation and maintenance. At the same time, it supports Spring Cloud, Apache Dubbo (hereinafter referred to as Dubbo), HSF and other micro-service operating environments, helping your various applications easily on the Cloud.

The core capabilities of EDAS can be extracted from the introduction: application development, application deployment, application monitoring, and application operation and maintenance. Of course, I cannot introduce the capabilities of the whole PaaS platform in this article. To be honest, application deployment, application monitoring and other capabilities are also developed by my colleagues, so I really know nothing about them and it is difficult to introduce them. Therefore, WHEN designing details, I will mainly introduce the capabilities related to EDAS and micro-service governance.

Why EDAS

In the figure above, I’ve tied the different deployments of microservices frameworks to cloud computing to facilitate the following.

For example, open source Apache Dubbo is used as the micro-service framework, which is deployed on the machines of self-built machine rooms. Usually, small and medium-sized companies will have special operation and maintenance to build the operating system and design the network topology. This is also the way most companies play before cloud computing.

But as we all know, in real life, “seeds” into “wheat” is generally a farmer uncle’s work, should be very few people will want to eat a steamed bread, and to sow a wave of seeds. For example, many Internet startups cannot accept this kind of gameplay. If they want to launch products as soon as possible, the first step must not be to build a bunch of machines, so IaaS has become their savior. Many cloud computing companies provide cloud servers (ECS) to solve the basic hardware problems, and r&d engineers can handle the rest. So “I have a great idea, all I need is a programmer” became popular. In IaaS stage, ECS can be used to deploy database, Redis and Dubbo nodes. If the machine has problems, work orders can be sent to cloud manufacturers, which greatly reduces operation and maintenance costs and enables r&d personnel to focus more on business development.

A lot of Dubbo users are in the “seed” and “wheat” stages, and someone told me that our company is using Dubbo on Tencent cloud. There’s nothing wrong with the old iron. The open source framework doesn’t mandate binding to any cloud vendor, either Pivotal’s SpringCloud or Alibaba-led Dubbo. However, why would I want to become a user of the “flour” stage? I tried to answer this question from some discussions in Dubbo’s wechat group:

There is a xx problem in the open source Dubbo console. Have you encountered it?

  • Please ask everyone, how do you do the current limiting of Dubbo?
  • Has anyone done full link tracking for Dubbo?
  • Dubbo grayscale release anyone in production practice?
  • How do Dubbo’s distributed transactions work?
  • How does Dubbo’s gateway work? · · · · · ·

In the case of Dubbo, you can see some signs that open source frameworks can have some problems. For example, the open source framework gives priority to the universality of functions, and supports less customized requirements such as grayscale publishing, and the higher-end functions are more difficult to support. Another example is the full link tracking of Dubbo, which is basically the high frequency problems collected after every Dubbo Meetup. Some companies have infrastructure teams that are capable of making changes even though they are using open source Dubbo. For example, Dangdang and Kaola are both iterating on their own branches, but I believe that their own extensions must be adapted to their own scenarios first. Another problem is that open source products also have bugs. Sometimes, if you locate the bugs and submit them to the community, you have to wait for others to review & merge request. Inevitably, there will be time cost, which is also an important reason for many companies to open branches and maintain them by themselves. Having said so much, in fact, it is all about the shortcomings of “wheat”. How does the “flour” phase solve these problems?

I have positioned EDAS, the aliyun product, at the stage of “flour” in the picture, mainly for the following reasons:

The IaaS layer solves all the problems it solves and does them better. EDAS does not even need users to buy machines, and can manage the application life cycle such as elastic scaling, stream limiting degradation, and graceful offline. In the microservice side, it supports Dubbo, SpringCloud, HSF and other mainstream microservice frameworks, and enhances the microservice capability. There are many commercial features, such as: white screen service governance interface, distributed link tracing, gray publishing, outlier removal, service limiting, high availability of registry… And so on, and the subsequent iterations, will continue to support distributed transactions, gateway and other features Back to ali cloud, have special micro service team to ensure the stability of the, let professional people do professional thing I think “flour” is a proper phase, you can cooking as bread, noodles, steamed bread, and would not bind you product form.

The history of EDAS support for microservices

From the perspective of Ali Cloud, how to attract users to use Ali Cloud services? Ali cloud services are too many, or look at the point of micro services. When EDAS was just tested N years ago, the main micro-service Framework of EDAS was HSF (High Speed Framework). Those who are familiar with IT know that HSF is the self-developed micro-service Framework used by Ali Group, which supports the smooth operation of all ali products on Double 11. With a double-11 test and Ali’s endorsement, EDAS ‘support for HSF was a no-brainer. Here’s how it works:

If Dubbo existing users want to use EDAS in the cloud, they have to use HSF framework to rewrite their own business code, which is very expensive. So if it’s a brand new business using HSF, isn’t that a problem? Not really. From a development perspective, the open source Dubbo community is very active, well documented, and the search engine is generally a solution when it comes to problems. But HSF is different, it is a closed source framework, even ali internal users, may be a little understanding of it, encountered problems, can only rely on work orders, q&A group to solve, can not see the source is the original sin. Although HSF is very stable, users have some qualms about hosting their code in a black box.

Many cloud platforms have similar problems, and the business cloud often means migrating technology stacks, which can be a cost you can imagine.

With Ali’s open source reboot of Dubbo, EDAS began supporting open source Dubbo, which solved many of the problems mentioned above at once. For Dubbo users in the “seed”, “wheat” stage, EDAS offers many of the enhancements promised by EDAS without changing a single line of code.

Followed by open source SpringCloud Alibaba, EDAS also offers 100% compatibility. At this point, EDAS can cover both Dubbo and SpringCloud applications.

Open source vs. commercialization vs. cloud native

From the history of development, we can find a game of cloud vendors. Dubbo and SpringCloud Alibaba were first led by Ali to open source, and both received preferential support in commercial cloud products. Not only Ali played this way, but Huawei opened ServiceComb. Ant has opened Sofa Stack and Tencent Tars, both of which have their own cloud platforms and basically allow users to migrate to their own microservice frameworks. On the one hand, open source cultivates user habits and accumulates influence. On the other hand, it also paves the way for commercialization.

Docking open source SDK has gradually become a consensus among cloud vendors, but the open source SDK here is not unified now, each has its own gameplay. But this is a big step forward, because open source doesn’t hold users hostage and the cloud vendor can move on when it gets tired of using it. The idea of using an open source SDK is just as advanced as using an SDK provided by a cloud vendor.

There are so many open source SDKS out there that if only there was one set of specifications everyone would follow, that’s probably what cloud native is doing. As the saying goes, three code farmers write code, second code farmers write framework, first code farmers set standards. But at present, there is no unified “cloud native open source SDK”, but some people have been in accordance with such ideas to promote, interested in ali can go to understand the OAM proposed.

Difficulties in EDAS microservice governance

Earlier we saw that EDAS not only serves as a runtime container for a running microservice framework, but also provides many enhancements to the microservice framework. After the popularization of the history, the details of micro-service enhancement will be introduced below. But before that, in order not to let the readers know how it is and why, I will first sort out the difficulties of EDAS micro-service governance.

Difficulty 1 EDAS supports a variety of microservice frameworks, currently supporting three microservice frameworks: Dubbo, SpringCloud and HSF.

Difficulty 2: Multiple versions of microservice framework:

  • Dubbo supports 2.5.x, 2.6.x, 2.7.x
  • SpringCloud supports versions D and above

Difficulty 3 For example, traditional service query requires access to a registry, but users use multiple types of registries:

  • Zookeeper
  • Nacos
  • Eureka

Four, there are many deployment modes. EDAS supports two deployment modes:

  • ECS Jar package deployment
  • K8s image deployment

The fifth difficulty needs to consider the migration of existing users and transformation cost.

In a word, the implementation of EDAS micro-service enhancement must take into account the above factors. When trade off is necessary, more pain points should be solved as much as possible to avoid users’ excessive transformation.

EDAS microservices enhanced implementation

The code that users deploy in EDAS uses an open source SDK, and EDAS promises that users don’t need to change the code, so how do you achieve this microservice enhancement? Meet this requirement is the Instrument mechanism provided by THE JDK, pinpoint and Skywalking familiar with distributed link tracking framework readers should not be unfamiliar with this technology. I wrote an article about it a long time ago: The JAVA gap-Instrument mechanism.

Implement non-invasive AOP through Instrument with a Demo.

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");
        }
        returnnull; }}Copy the code

In class for assembling the first step is to write a GreetingTransformer class, its inheritance: Java. Lang. Instrument. ClassFileTransformer.

MicroServiceAgent

In addition to the Transformer above, we also need a container to load it.

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

MicroServiceAgent is the agent mounted by the end user’s Jar runtime. For details on how to load the Agent, please refer to the above article link, which has a complete demo and tutorial. The main purpose here is to introduce the assembly mechanism.

Just like AOP, the microservice enhancement logic of EDAS uses non-invasive mount to achieve the enhanced logic. This process requires agent to adapt different versions one by one, so as to realize the capabilities of service query, gray publishing, distributed link tracking, outlier removal and so on.

conclusion

In fact, this paper introduces EDAS from a subjective perspective, focusing on the micro-service capability of EDAS. EDAS itself is a commercial cloud product, but combined with open source, we can see some rules of software architecture evolution from its evolution history, which has certain guiding significance for us to grasp the future technological development trend.


Read more: https://yqh.aliyun.com/detail/6423?utm_content=g_1000105432

On the cloud to see yunqi: more cloud information, on the cloud case, best practices, product introduction, visit: https://yqh.aliyun.com/