Introduction: The service framework is just like the rails of the railway, which is the foundation of interworking. Only when the interworking of the service framework is solved, can the higher level business interworking be completed. Therefore, it is an inevitable trend to unify the same standard, merge into one and build a new generation of service framework. Dubbo3.0 is the fusion of Dubbo2.0 and HSF. It is the only standard service framework of ali economy for internal business, commercialization and open source.
The service framework, like the rails of the railway, is the foundation of interworking. Only when the interworking of the service framework is solved, can the higher level business interworking be completed. Therefore, it is an inevitable trend to unify the same standard, merge into one and build a new generation of service framework.
Dubbo3.0 is the fusion of Dubbo2.0 and HSF. It is the only standard service framework of ali economy for internal business, commercialization and open source.
The choice and practice of Alibaba service framework
Dubbo and HSF’s practice in Alibaba
Dubbo and HSF are both microservices RPC frameworks currently in use by Alibaba.
Dubbo, on the other hand, has rapidly become a popular microservices framework in the industry since it was opened in 2011 and has been widely used both at home and abroad. The Dubbo project was born in 2008 and was initially used only on an internal Alibaba system; In 2011, Ali B2B decided to open source the whole project, and in only one year, it gained a large number of users from different industries. In 2014, Dubbo stopped updating due to internal team changes; In September 2017, Dubbo 3.0 restarted open source and was incubated and graduated by Apache in May 2019, becoming the second project donated by Alibaba to Apache graduation.
HSF is more widely used in Alibaba, which has carried on the internal architecture evolution from single application to micro-service and supported the smooth operation of Alibaba’s Singles’ Day. Since the first version 1.1 was released in May 2008, HSF has evolved over several years from a basic RPC framework to an easily extensible microservices framework that supports ten trillion calls per day. In the internal scenario, users can easily access the micro-service system with a small number of configurations to obtain stable service invocation with high performance. You can also expand the HSF based on service requirements to enhance the capability of obtaining the entire link.
For the needs of the group, stability and performance are the core. Therefore, HSF, which has been tested in high concurrency scenarios like e-commerce, was selected as the core of the new generation of service framework. Subsequently, HSF 2.0 was released and reconfigured to address major issues of previous versions of HSF, reducing maintenance costs and further improving stability and performance. HSF2.0 solves the framework scalability problems such as communication protocol support opacity and serialization protocol support opacity. Based on the Java version of HSF2.0, the group has also evolved multi-language clients such as CPP/NodeJs/PHP. As HSF is also compatible with the Dubbo protocol, the original Dubbo users can smoothly migrate to the new version, so HSF was fully rolled out in the group soon after its launch. The number of deployed servers reached hundreds of thousands, which basically completed the unification of alibaba’s internal micro-service framework. And experienced for many years double eleven zero flow peak verification.
Challenges and opportunities for the next generation of microservices
However, the development of business and the iteration of the framework itself make the simple compatibility of the two frameworks from the protocol layer no longer meet the needs. With the continuous development of cloud computing and the widespread spread of the concept of cloud native, the development of micro-services has the following trends:
- K8s has become the de facto standard for resource scheduling, and Service Mesh has been gradually accepted by more and more users since it was proposed and developed. Shielding underlying infrastructure has become a core evolution goal of software architecture, and the problem faced by Both Alibaba and other enterprise users has changed from whether to go to the cloud to how to smoothly and stably migrate to the cloud at low cost.
- Due to the diversity of paths to the cloud and the transition from the existing architecture to the cloud native architecture, the facilities for deploying applications are flexible and the micro-services on the cloud also show a trend of diversification. Invocation across languages, vendors, and environments will inevitably lead to unified protocols and frameworks based on open standards to meet interoperability requirements.
- Access to back-end services on the end is exploding, and the scale of applications and the entire microservice system is growing along with it.
These trends also present new challenges for HSF and Dubbo.
Challenges for HSF and Dubbo
Microservices frameworks are fundamental components, and most companies need to decide which one to use early in the selection process or as their business grows to a certain size. A stable and efficient self-developed framework usually needs a long time of iteration to polish and optimize. So most companies tend to use open source components initially. For AliYun, this presents a problem: the HSF framework is used internally, while the majority of users on the cloud are using the open source Dubbo framework. The two frameworks have differences in protocol, internal module abstraction, programming interface and functional support.
How to make the best practices and cutting-edge technologies of alibaba Group internal components using HSF more easily and directly exported to the cloud is a problem that every student who is engaged in technology commercialization will encounter and must solve. In fact, we have also made some explorations. The HSF framework was first promoted as a micro-service on the cloud. When the closed-source components are output on the cloud, for many users, there is no way to check when they encounter problems, and the whole service framework is a black box component for them. We found that this was not a good transition direction, and we had to embrace the open source approach when it came to exporting to the Cloud, focusing on Dubbo and the Spring Cloud framework.
At the same time, there are also many problems caused by the existence of HSF and Dubbo frameworks in the group. How to integrate the technology stack of the original department or company into the existing technology system is an unavoidable problem. A case in point is Koala, which joined Alibaba in 2019. Koala has been using Dubbo as a micro-service framework before, and built large-scale micro-service applications based on Dubbo, which has high cost and great risk of migration. It will take a long time for the group and kaola’s infrastructure department to conduct pre-migration research and plan design, and then make changes after ensuring basic feasibility. From batch gray on-line, and then to the final full on-line. This kind of change not only requires a lot of manpower, but also takes a long time, which will affect the development and stability of the business. At the same time, due to historical reasons, there has always been a certain number of Dubbo users within the group. In order to better serve this part of users, HSF framework for Dubbo protocol layer and API layer compatibility. However, such compatibility is limited to interoperability. With the development of Dubbo open source community for many years, such basic compatibility has great disadvantages in terms of disaster recovery, performance and iterability, and it is difficult to align with Dubbo’s service governance system. There are also risks in terms of stability and not being able to enjoy the technological dividends of the group’s technological development and the evolution of the Dubbo community.
The root cause of these problems is that closed source HSF cannot be directly applied to the majority of cloud users and other external users, and the challenge of open source products to closed source products will become more and more severe with the continuous development of open source and cloud. The sooner this is resolved, the lower the cost of cloud native migration for Alibaba and external enterprise users, and the greater the value generated.
Therefore, the integration of HSF and Dubbo is an inevitable trend. In order to better serve internal and external users, as well as for the better development of the two frameworks, Dubbo3.0 and HSF3.0, which ADAPTS to the infrastructure ecology within the group with Dubbo3.0 as the kernel, came into being.
Dubbo3.0 is the final choice of the service framework under the trinity strategy
While fully compatible with the original feature set and API, Dubbo3.0 also has the following new features to face the challenges of cloud native
- Dubbo 3.0 supports a new service discovery model. Dubbo 3.0 tries to start from the application model, optimize the storage structure, and design the original mainstream model of Qiyun to avoid the interoperability problems in the model. The new model is highly compressed in data organization, which can significantly improve performance and cluster scalability.
- Dubbo 3.0 proposed the next generation RPC protocol, Triple. This is a new open protocol that is fully compatible with gRPC protocol based on HTTP/2 design. Because it is designed based on HTTP/2, it has high gateway friendliness and penetration. Fully compatible with THE gRPC protocol is naturally advantageous in multi-language interoperability.
- For cloud native traffic governance, Dubbo 3.0 provides a set of unified governance rules covering traditional SDK deployment, Service Mesh deployment, VM deployment, and Container deployment. It supports most of the scenarios using one rule, greatly reducing the cost of traffic governance. It makes global traffic governance possible under heterogeneous system.
- Dubbo 3.0 provides a solution to access the Service Mesh. For Mesh scenarios, Dubbo 3.0 provides two access modes. One is the Thin SDK mode, and the deployment model is exactly the same as the current mainstream Service Mesh deployment scenarios. Dubbo will be slimmed-down, shielding the same governance functions as Mesh and retaining only the core RPC capability. The second is Proxyless mode. Dubbo will take over the responsibilities of Sidecar, communicate with the control plane actively, and apply the cloud native traffic governance function based on the unified governance rules of Dubbo 3.0.
Evolution of service framework in the direction of Ali Cloud commercialization
For microservice frameworks, commercialization is a challenge due to the business code associated with the customer.
First of all, in terms of the migration cost, we hope to reduce the migration cost to zero. At the beginning, we sold HSF + EDAS Container architecture on the cloud, so customers had to modify their business code when they went on the cloud. In addition, because the code was not open source, troubleshooting was also a headache. Later, we found that most of the clients’ microservice frameworks would choose the open source Dubbo/Spring Cloud, but the clients have their own registries. If they want to go to the Cloud, they also need to migrate their registries to the MSE registry. This process requires users to make changes to the code. On the cloud we found push the client to do code transformation, including the upgrading of the SDK is a very difficult thing, many clients of Dubbo version also stay on version of four to five years, not only need to focus on research and development, testing, ops, also need to support scheduling, this movement will cost a lot of human resources, the stability of the many challenges at the same time. This step alone will hold many clients, in order to solve the problem of the client SDK upgrades, we thought, can not transfer the registry, it is best to code one line also need not change, the deployment to the cloud, but we also need to provide the same service governance ability, therefore, we put forward based on Java Agent bytecode enhancement technology, Help users do not change a line of code to use cloud products, customers can be up and down at any time, no binding, so that customers are more assured of the cloud products, at the same time we also provide a more capable surface operation and maintenance of the hosted registry.
When it comes to choosing a microservice framework for commercialization, our attitude has always been to embrace open source.
We also need to provide differentiated service governance capabilities on the basis of open source micro-service frameworks. The problems of traditional open source micro-service frameworks in K8s are gradually exposed in the process of cloud. Through a series of communication with customers, and we’ve come to the conclusion that the customers under the cloud native of the major pain points in micro service governance, mainly including nondestructive up and down the line, in the process of micro service release label routing, service authentication, instance was removed from the group, gray and so on, all link in us through the Java Agent technology to achieve the user do not change the situation of the code, The above problems have been solved. Through customer communication, demand collection, product implementation and demo verification for customers, this mode has gone through a positive cycle and its functions have been continuously enriched. In addition to Java Agent, for multi-language scenarios, we use Service Mesh, WASM and other technologies to support customers to have consistent Service governance ability and experience in Java without modifying a line of code.
At the same time, we also made some attempts and choices on the selection of Java Agent. At the beginning, we used Java Agent developed from closed source, and each cloud product has a corresponding Java Agent, which will lead to problems such as too many Java Agents and Agent conflicts. At the same time, the Java Agent maintained by ourselves is closed source. After some stumbles, we decided to use Arthas One Agent to reconstruct the Agent of the service governance system, combining all the agents related to governance into One, while our base Java Agent also adopted an open source strategy. We used Arthas One Agent, which is open source.
Dubbo3.0 follows in this direction, delivering the benefits of the group’s technology development and Dubbo community evolution, as well as commercialization practices, to customers on the cloud through Dubbo3.0 + Java Agent.
Service governance seamlessly supports Dubbo3.0
There are three solutions related to micro-service governance on Ali Cloud: MSE(micro-service engine, providing micro-service governance capability), EDAS(application platform hosted in full life cycle), and SAE(Serverless application platform with flexible scalability). Both EDAS and SAE have deeply integrated MSE service governance capability. All of MSE’s service governance capabilities are out-of-the-box, supporting all open source Dubbo and Spring Cloud frameworks on the market in the past five years, including Dubbo 3.0. You don’t need to modify a line of code and configuration. You just need to connect your Dubbo 3.0 application to EDAS/MSE/SAE. Including lossless on-off and off-line capabilities during microservice delivery, which aligns the lifecycle of microservices with that of K8S POD; Label routing capabilities weaken binding dependence on IP, service authentication, outlier instance removal, whole-link gray scale, service Mock, service monitoring, service contract, and more.
How to seamlessly upgrade an HSF application to a Dubbo 3.0 application
Trinity is alibaba’s unified technology system for “self-research”, “open source” and “commercialization”. Under this technical direction, the design and implementation of Dubbo3.0 have realized the technical unification of HSF/Dubbo, which is also being rapidly promoted and implemented in the group. EDAS Container 4.x is one of the commercial export forms of Dubbo3.0.
If your application on EDAS or SAE uses HSF + EDAS Container, users can easily upgrade HSF application to Dubbo 3.0 application by upgrading the Container version to 4.x. After the upgrade, HSF applications will continue to be developed in the same way, and will be able to use the improved service governance capabilities provided by EDAS/SAE for Dubbo applications. Your HSF application will also feature new Dubbo 3.0 features, application-level service discovery, Triple protocol, and more.
Java Microservices Proxyless Mesh architecture
In the heterogeneous microservice scenario, with the popularization of ServiceMesh scheme, how to communicate with other Mesh nodes in the ServiceMesh microservice architecture and how to align governance capabilities has become a problem that puzzles users. The open source Spring Cloud/Dubbo framework can interact with the Mesh architecture without Envoy additions on the MSE microservices engine and without modifying a single line of code.
Dubbo3.0 mass production practice case
Dubbo3.0 in the landing process, we have many large-scale practice, koala, nail, etc.
The following uses Nailing as an example
background
In order to embrace containerization and enjoy the benefits of the cloud, Nail Documents launched the Upper cloud campaign in 2020. Currently 50% of the traffic is running in public clusters.
Business challenges
The upcloud of documents is divided into two phases.
In the first stage, dani (namely alibaba group’s internal network) and cloud each have a document cluster: Dani cluster to undertake the existing business; Clusters on the cloud to undertake incremental services. Intra – bomb cluster also acts as a proxy: for the upstream service of intra – bomb, intra – bomb cluster acts as a proxy for the call to the cluster on the document cloud; For an on-cloud cluster, in-bomb services represent downstream dependencies within the group.
In the second phase, the existing data is migrated to the cloud and only the cluster is retained on the cloud. Upstream services, downstream dependencies, are directly invoked through triple protocol.
Right now we’re in phase one.
In the first stage, we have several appeals:
1. I hope to use a set of code to run in two clusters in the bomb and on the cloud;
2. Hope that the cluster within the missile will continue to use HSF protocol;
3. Hope to use open source RPC protocol on cloud;
4. Hope that the cluster on the cloud and within the bomb can communicate with each other.
Dubbo 3.0 is a perfect fit for our needs.
The ground plan
1. Dual cluster
Documents currently have two clusters. In the cluster, triple and HSF protocols are exposed, while in the cluster on the cloud, only Triple protocol is exposed.
The version number inside the ammunition will remain 1.0.0, while the version number on the cloud will be 1.0.0.zjk.
For upstream services, there is only one cluster within the bomb and all traffic is directed to the cluster within the bomb. In this way, the upstream business does not need to do any transformation.
2. Unitized routing
In-bomb service that intercepts incoming HSF requests. If it is resolved that the request needs to be routed to the cloud, a Triple call is made to the cloud service. Otherwise, continue to pass the request to the service inside the shell.
3. Downstream dependence
The document has some dependency on the in-bomb service and cannot be removed. The current approach is that the document itself encapsulates the downstream services, exposing the Triple protocol for invocation in the cloud.
4. Service governance
With service interworking complete, it’s time to look at service governance. The service includes service query, service test, service pressure test, service traffic limiting, and service monitoring.
4.1 MSE
Service queries, service tests, service routing, and so on are all done by accessing the MSE. Special mention should be made here of MSE’s service testing. Curl HSF: HTTP: HTTP: HTTP: MSE: HTTP: HTTP: MSE: HTTP: HTTP Service test is to provide users with a private network Postman on the cloud, so that users can easily call their own services. Users do not need to be aware of the complex network topology on the cloud, do not need to relational services protocol, do not need to build their own testing tools, only through the console to achieve service invocation. Supports the Dubbo 3.0 framework and the Triple protocol of Dubbo 3.0.
4.2 other
As the standard Dubbo protocol is used on the cloud, middleware such as Ahas and Arms can be seamlessly accessed.
conclusion
Dingdingdocument realizes fast access to the cloud within three months with the help of the trinity bonus, and solves the problems encountered in the process of access to the cloud through the standardization of cloud products. With the help of the cloud native features of Dubbo3.0 and the fast access and support of MSE service governance ability, the service framework is quickly completed from communication to governance.
The tail
The “trinity” of self-research, commercial use and open source enables the core technologies deposited in The “Double 11” to be directly used by customers, bypassing the process of precipitation and output on the cloud, reducing the threshold and cost for customers to obtain the “double 11” technology engine, and helping customers to quickly step into the digital native era. Dubbo3.0 is the choice under this strategy. Dubbo3.0 and HSF based on Dubbo3.0 kernel are going forward both externally and internally to provide the best user experience for aliyun, group and open source users. Together, Dubbo3.0 will create the most stable service framework. Lead the development of micro services in the cloud native era.
The original link
This article is the original content of Aliyun and shall not be reproduced without permission.