Introduction to The integration of HSF and Dubbo is the general trend. In order to better serve internal and external users, and for the better development of the two frameworks, Dubbo 3.0 and HSF 3, which use Dubbo 3.0 as the core to adapt to the group's infrastructure ecology, came into being.
Author | Guo Hao
Dubbo and HSF are both microservice RPC frameworks currently used by Alibaba. HSF is used more in Alibaba, undertaking the internal architecture evolution from monolithic applications to microservices, and supporting the smooth operation of Alibaba's Double Eleven over the years; Dubbo has quickly become a popular microservice in the industry after being open sourced in 2011 Frame products are widely used at home and abroad.
Since the release of the first version 1.1 in May 2008, after several years of iteration, HSF has gradually evolved from a basic RPC framework to an easy-to-scalable microservice framework that supports 10 trillion calls per day. In internal scenarios, users can select a small number of configurations to easily access the microservice system and obtain high-performance and stable service calls. You can also expand the HSF according to your own business needs to enhance the ability to obtain the entire link.
The Dubbo project was born in 2008 and was initially only used in an Alibaba internal system; in 2011, Alibaba B2B decided to open source the entire project, and it took only one year to harvest a large number of users from different industries; in 2014, due to the internal team Due to adjustments, Dubbo suspended updates; in September 2017, Dubbo 3 restarted open source, and was incubated and graduated by Apache in May 2019, becoming the second project donated by Alibaba to Apache graduated.
Practice of Dubbo and HSF in Alibaba
In 2008, the main service framework used by the group's internal Taobao department was HSF, while B2B used Dubbo. The two are independent, each goes its own way, and they are not connected to each other. With the rapid development of business, the need for cross-language, cross-platform, and cross-framework has become increasingly obvious. The call for interconnection between different businesses has become increasingly high, and it has quickly evolved into the needs of almost the entire group. That is, Amoy Department can call B2B services, and vice versa.
The service framework is just like the railroad tracks. It is the foundation of intercommunication. Only when the intercommunication of the service framework is solved can higher-level business intercommunication be completed. Therefore, it is an inevitable trend to use the same standard to build a new generation of service framework. That is, the final framework needs to be compatible with HSF1.x and Dubbo (including 1.x and 2.x) protocols. For the needs of the group, stability and performance are the core. Therefore, the HSF, which has been tested in e-commerce high-concurrency scenarios, was selected as the core of the new generation service framework. Subsequently, HSF launched the 2.0 version, and reconstructed and transformed the main problems of the previous version of HSF, which reduced maintenance costs and further improved stability and performance. HSF 2.0 solves the problem of frame extensibility such as opaque communication protocol support and opaque serialization protocol support. Based on the Java version of HSF 2.0, the group has also evolved CPP/NodeJs/PHP and other multi-language clients.
Due to the compatibility with Dubbo’s protocol, the original Dubbo users can smoothly migrate to the new version. Therefore, HSF was launched in the group soon after the launch. The number of deployed servers reached hundreds of thousands, which basically completed the Alibaba internal micro The unified service framework has been verified by the zero-point traffic peak on Double Eleven for many years.
Challenges and opportunities of next-generation microservices
However, the development of the business and the iteration of the framework itself make the simple compatibility of the two frameworks from the protocol layer unable to meet the needs. With the continuous development of cloud computing and the widespread dissemination of cloud native concepts, the development of microservices has the following trends:
1. K8s has become the de facto standard for resource scheduling. Service Mesh has been gradually accepted by more and more users from its proposal to its development. Shielding the underlying infrastructure has become a core evolution goal of the software architecture. Whether it is Alibaba or other enterprise users, the problems facing them have changed from whether to go to the cloud or not to how to smoothly and steadily migrate to the cloud at low cost.
2. Due to the diversified path to the cloud and the transition from the existing architecture to the cloud-native architecture, the facilities for deploying applications are flexible and changeable, and the microservices on the cloud are also showing a diversified trend. Cross-language, cross-vendor, and cross-environment calls will inevitably give birth to unified protocols and frameworks based on open standards to meet interoperability requirements.
3. The access to back-end services on the end is increasing explosively, and the scale of applications and the scale of the entire microservice system are increasing accordingly.
These trends have also brought new challenges to HSF and Dubbo.
First, going to the cloud has had an impact on internal closed-source components. The microservice framework is a basic component, and most companies need to decide to use a certain framework in the early selection or business development to a certain scale. A stable and efficient self-developed framework usually requires a long period of iteration to polish and optimize. Therefore, most companies tend to use open source components in the early stages. For Alibaba Cloud, this brings about a problem: the HSF framework is used internally, while most users on the cloud use the open source Dubbo framework. The two frameworks are in terms of protocol, internal module abstraction, programming interface and function. There are differences in support. How to make the best practices and cutting-edge technologies of the internal components of the Alibaba Group that use HSF be output to the cloud more simply and directly, this is a problem that every student who does technology commercialization will encounter and must solve.
Second, how to integrate the technology stack of the original department or company into the existing technology system faster is an inevitable problem. A typical example is Koala who joined Alibaba in 2019. Koala has always used Dubbo as a microservice framework before, and built a large-scale microservice application based on Dubbo. The cost of migration is high and the risk is also high. The infrastructure departments of the Group and Koala need to spend a long time on pre-migration research and program design to ensure that they are basically feasible before starting to make changes. From batch gray scale launch to the final full launch. This type of exchange-style change not only requires a lot of manpower, but also has a long time span, which will affect the development and stability of the business.
Third, due to historical reasons, there has always been a certain number of Dubbo users within the group. In order to better serve these users, the HSF framework is compatible with Dubbo's protocol layer and API layer. However, this compatibility is limited to interoperability. With the development of the Dubbo open source community for many years, this basic compatibility has major disadvantages in terms of disaster tolerance, performance, and iterability. At the same time, it is difficult to align with Dubbo's service governance system. There are also risks in terms of stability, not to mention the inability 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 used for the majority of cloud users and other external users, and the challenge of open-source products to closed-source products will intensify with the continuous development of open source and cloud. The sooner this problem is resolved, the lower the cost of cloud native migration between Alibaba and external enterprise users, and the greater the value generated.
The easiest and most direct way is to open source HSF. But this will face two new problems. First, Dubbo is Ali’s earlier open source star product. If HSF is also open source, how to divide the relationship and application scenarios of these two similar frameworks will not only cause confusion for external users, but repeated open source will also be detrimental to brand building. Second, if existing Dubbo users at home and abroad want to access Alibaba Cloud, they need to use existing solutions based on HSF, and it takes a lot of effort to migrate all applications that use Dubbo to HSF, and cost and stability are compelling. Questions to consider. The above two reasons show that it is not the best time to open source HSF.
Since HSF can't go out, the remaining solution is to let Dubbo in. The core integration method is adopted internally, and the HSF framework is rebuilt based on the Dubbo kernel.
In terms of brand building, integration can enable Dubbo's existing extensive influence to continue to develop. After Dubbo's large-scale implementation in the group, it will have a good original brand demonstration effect, and external users will also have more confidence in microservices. Choose Dubbo when selecting the frame. At the same time, users who have already used Dubbo have more reasons to follow the evolution of the version and enjoy the technological dividends brought by Alibaba's open source.
In engineering practice, using Dubbo to rebuild HSF is more feasible from internal reunification, the complexity of the migration is controllable, and it can be implemented gradually and orderly. The complete internal testing process and rich scenarios are the best functional regression testing for Dubbo. Internal and external unification is also the best way to balance commercialization and internal support. In the process of refactoring, constantly improving functions, improving performance, and embracing a newer and more cloud-native technology stack are also the best way to enhance the user experience within the group.
Therefore, the integration of HSF and Dubbo is the general trend. In order to better serve internal and external users, and for the better development of the two frameworks, Dubbo 3.0 and HSF 3, which use Dubbo 3.0 as the core to adapt to the group's infrastructure ecology, came into being.
Next-generation cloud-native microservices
First of all introduce Dubbo 3.0 in general.
- Dubbo 3.0 supports a new service discovery model. Dubbo 3.0 tries to start with the application model, optimize the storage structure, align with the cloud native mainstream design model, and avoid interoperability problems caused by the model. The new model is highly compressed in data organization, which can effectively improve performance and cluster scalability.
- Dubbo 3.0 proposes the next-generation RPC protocol-Triple. This is an open new protocol designed based on HTTP/2 that is fully compatible with the gRPC protocol. Because it is designed based on HTTP/2, it is highly gateway-friendly and penetrating; it is fully compatible with the gRPC protocol and is naturally multilingual It has advantages in interoperability.
- Dubbo 3.0 is geared towards cloud-native traffic governance, and proposes a set of unified governance rules that can cover scenarios such as traditional SDK deployment, Service Mesh deployment, VM virtual machine deployment, and Container container deployment. It supports one rule to govern most scenarios and greatly reduces traffic. Governance costs make it possible to govern global traffic under a heterogeneous system.
- Dubbo 3.0 will provide a solution for accessing Service Mesh. For Mesh scenarios, Dubbo 3.0 proposes two access methods. One is Thin SDK mode. The deployment model is exactly the same as the current mainstream deployment scenario of Service Mesh, while Dubbo will slim down. , Shielding the same governance functions as Mesh, and only retaining the core RPC capabilities; the second is the Proxyless mode, Dubbo will take over the duties of Sidecar, actively communicate with the control plane, and apply cloud-native traffic based on the unified governance rules of Dubbo 3.0 Governance function.
1. Application-level registration discovery model
The prototype of the application-level registration discovery model was first proposed in Dubbo 2.7.6. After several iterations, the stable model in Dubbo 3.0 was finally formed. In Dubbo 2.7 and previous versions, when applications register and discover services, they use interfaces as the granularity. Each interface corresponds to a piece of data in the registry. Different machines will be registered with metadata information belonging to the current machine or Interface-level configuration information, such as serialization, computer room, unit, timeout configuration, etc. All servers that provide this service will independently change the interface granularity when restarting or publishing.
For example, a gateway application relies on 30 interfaces of the upstream application. When the upstream application is released, there are 30 corresponding address lists that are going online and offline. The first citizen discovery model with the interface as the registration is the earliest SOA or microservice splitting method, which provides a flexible ability to independently and dynamically change according to a single service and a single node. With the development of business, the number of services that a single application depends on is increasing, and the number of machines of each service provider is also increasing due to business or capacity reasons. The total number of service addresses that clients rely on has risen rapidly, and the pressure on related dependent components such as registry centers has doubled.
We have noticed two trends in the development of the microservice model: First, as the splitting of single applications into multi-microservice applications is basically completed, large-scale service splitting and reorganization are no longer pain points, and most of the interfaces are only Provided by one application or fixed by several applications. Secondly, a large number of URLs used to mark address information are extremely redundant, such as timeouts, serialization, and these configuration changes are extremely infrequent, but they appear in every URL. So application-level registration discovery came into being.
Application-level service discovery takes application as the basic dimension of registration discovery. The main difference from the interface level is that an application provides 100 interfaces. According to the granularity of the interface level, 100 nodes need to be registered in the registry. If the application has 100 machines, each time it is released, it will be the same for its clients. Changes of 10,000 virtual nodes. However, application-level registration discovery only requires 1 node, and only 100 virtual nodes are changed for each release. For applications that rely on a large number of services and many machines, the scale is reduced by tens to one percent. The memory footprint will also be reduced by at least half.
Finally, because this new service discovery is consistent with the service discovery model under Spring Cloud, Service Mesh and other systems, Dubbo can realize mutual discovery from the registry level with nodes under other systems, and realize the interconnection of heterogeneous microservice systems. Intercommunication.
2. The next generation RPC protocol-Triple
As the most basic ability of the RPC framework, it is to complete the service invocation across business processes, to form a chain of services, and to form a network. The core carrier of this is the protocol. Dubbo 2.0 provides the core semantics of RPC, including protocol headers, flag bits, request ID, and request/response data, which are combined in binary data in a certain order.
In the cloud-native era, the Dubbo 2.0 protocol faces two main challenges. One is that the ecology is not interoperable, and it is difficult for users to directly understand the binary protocol. The second is that it is not friendly to gateway components such as Mesh, and requires a complete parsing protocol to obtain the required call metadata, such as some RPC contexts, which will face challenges from performance to ease of use. At the same time, the design and implementation of the old version of the Dubbo 2.0 RPC protocol has been proven in practice to limit the development of the business architecture in some aspects, such as the interaction from the terminal device to the back-end service, and the multilingualism in the microservice architecture. Adoption, data transmission model between services, etc. So, on the premise of supporting existing functions and solving existing problems, what features do the next-generation protocols need?
First of all, the new protocol should be easy to extend, including but not limited to Tracing/Monitoring and other support, and should also be recognized by all layers of equipment to reduce the difficulty of user understanding.
Secondly, the protocol needs to solve the problem of cross-language intercommunication. The traditional multi-language and multi-SDK mode and the Mesh-based cross-language mode both require a more versatile and extensible data transmission format.
Finally, the protocol should provide a more complete request model. In addition to the Request/Response model, it should also support Streaming and Bidirectional models.
Based on these requirements, the combination of HTTP2/protobuf is the most suitable. Mentioning these two, you may easily think of the gRPC protocol. What is the relationship between the new generation protocol and gRPC?
First of all, the new Dubbo protocol is an extended protocol based on GRPC, which also ensures that the new protocol and GRPC can communicate and share in the ecosystem. Secondly, on this basis, the new Dubbo protocol will more natively support Dubbo's service governance and provide greater flexibility. In terms of serialization, since most applications have not yet used Protobuf, the new protocol will provide sufficient support for serialization, smoothly adapt to existing serialization, and facilitate migration to Protobuf. In the request model, the new protocol will natively support end-to-end full-link Reactive, which is also not available in the gRPC protocol.
3. Native access to Service Mesh
How to get Dubbo to land in the Service Mesh system, the community development team investigated many solutions and finally determined the two forms of Mesh solutions that are most suitable for Dubbo 3.0.
One is the classic Sidecar-based Service Mesh, and the other is the Proxyless Mesh without Sidecar. For the Sidecar Mesh solution, its deployment method is the same as the current mainstream Service Mesh deployment solution. The focus of Dubbo 3.0 is to provide a completely transparent upgrade experience for business applications as much as possible. This is not only a non-sense upgrade from a programming perspective, but also includes lightweighting through Dubbo 3.0 , Triple protocol, etc., so that the loss and operation and maintenance costs on the entire call link are also reduced to a minimum. This solution is also called the Thin SDK solution, and Thin's place is to remove all unnecessary components. The Proxyless Mesh deployment plan is another Mesh form planned by Dubbo 3.0. The goal is to directly interact with the control plane without starting the Sidecar.
We envision that this Proxyless Mesh deployment scheme will be very suitable for the following scenarios:
First, the business side expects to upgrade the Mesh solution, but cannot accept the performance loss caused by Sidecar's traffic hijacking. This situation is common in core business scenarios;
The second is to reduce the O&M costs and system complexity caused by the deployment of Sidecar; the third is the slow upgrade of the legacy system, the long migration process, and the coexistence of multiple deployment architectures.
Finally, there are multiple deployment environments. The multiple deployment environments here include multiple deployment methods such as VM virtual machines, Container containers, etc., as well as multiple types of mixed deployment of applications, such as the mixed deployment of Thin SDK and Proxyless solutions. Sensitive applications are deployed in the Proxyless mode, and the Thin SDK deployment solution is adopted for peripheral applications, and multiple data planes are jointly scheduled by a unified control plane.
Looking at these two forms as a whole, in different business scenarios, different migration stages, and different infrastructure guarantees, Dubbo will have Mesh plans to choose from.
4. Flexible service enhancement
Cloud native has brought about a major change in technology standardization. How to make applications easier to create and run on the cloud, and have the ability to elastically expand, is the core goal of all cloud native basic components. With the elasticity brought by cloud native technology, applications can expand a large number of machines in a very short time to support business needs. For example, in order to deal with zero-point spike scenarios or emergencies, the application itself often requires thousands or even tens of thousands of nodes to meet the needs of users, but the expansion also brings many large-scale cluster deployments in cloud-native scenarios. problem. For example, due to the extremely large number of cluster nodes, the node abnormalities occur frequently, and the service capacity is affected by a variety of objective factors, resulting in uneven node service capabilities.
Dubbo expects to solve these problems based on a flexible cluster scheduling mechanism. This mechanism mainly solves two problems: first, in the case of abnormal nodes, distributed services can remain stable without avalanches and other issues; second, for large-scale applications, it can run in the best state and provide Higher throughput and performance. From a single service perspective, Dubbo's desired goal is to provide an unbreakable service to the outside world, that is, when the number of requests is particularly high, it can selectively reject some requests to ensure the correctness and timeliness of the overall business sex.
From a distributed perspective, it is necessary to minimize the overall performance degradation due to complex topologies and different node performance. The flexible scheduling mechanism can dynamically allocate traffic in an optimal way, so that heterogeneous systems can accurately serve according to runtime Reasonable allocation of capacity requests to achieve optimal performance.
5. Business income
For the business, it may be more concerned about the benefits of upgrading to Dubbo 3.0. The two key words are summarized and refined, namely the improvement of the application's own performance and stability and the native access of the cloud.
- In terms of performance and stability, Dubbo 3.0 will focus on large-scale cluster deployment scenarios, reduce single-machine resource consumption by optimizing data storage methods, and ensure the stability of the entire cluster when dealing with the horizontal expansion of ultra-large-scale clusters. In addition, Dubbo 3.0 puts forward the concept of flexible service, which can effectively guarantee and improve the overall reliability of the entire link and the utilization of resources to a certain extent.
- The second is about cloud native. Dubbo 3.0 is a milestone version of Dubbo fully embracing cloud native. At present, Dubbo has a huge base of users at home and abroad. With the advent of the cloud native era, the demand for these users to go to the cloud is becoming stronger and stronger. , Dubbo 3.0 will provide complete and reliable solutions, migration paths and best practices to help enterprises achieve cloud-native transformation and enjoy the dividends brought by cloud-native.
Judging from the results that have been implemented, Dubbo 3.0 can greatly reduce the additional resource consumption brought by the framework and improve the utilization of system resources. From a stand-alone perspective, Dubbo 3.0 can save about 50% of memory usage; from a cluster perspective, Dubbo3 can support large-scale clusters with millions of instances, laying the foundation for future larger-scale business expansion; Dubbo3's support for Reactive Stream, etc. The support of the communication model can greatly increase the overall throughput in business scenarios such as large file transmission and streaming.
In terms of architecture, Dubbo 3.0 brings more possibilities for business architecture upgrades. Dubbo’s original protocol restricts microservice access to a certain extent. For example, if mobile and front-end services are connected to Dubbo’s back-end services, they need to go through the gateway layer protocol conversion. For example, Dubbo only has The request-response mode of communication is supported, which makes some scenarios that require streaming or reverse communication unsupported.
In the process of cloud-native transformation, the business is most concerned about changes and stability. Whether it can be upgraded to a cloud-native environment without or with less code changes is crucial in the selection of the cloud-native business process. Dubbo 3.0 brings an overall solution to the original upgrade of the cloud on the business side. Whether it is the upgrade of the underlying infrastructure to drive business upgrades or the active upgrade to solve business pain points, the cloud native solutions provided by Dubbo 3.0 can help products quickly upgrade and enter the cloud native era.
6. Current status and Roadmap
For internal use, Dubbo 3.0 has been fully implemented in the tens of thousands of nodes of hundreds of applications in the koala business, and a large number of applications use Dubbo 3.0 to easily complete the application to the cloud. It is currently being piloted and gradually implemented in large-scale e-commerce core applications. Application-level registration discovery, triple protocol and other new features. Open source users and commercial applications are currently migrating from the original HSF2 or Dubbo 2.0 to Dubbo 3.0. The service framework team and the community are collating and writing related migration best practices. These documents will be available to you in a while.
Dubbo 3.0 was officially released in June this year as a milestone version donated to Apache, which also represents a node that Apache Dubbo fully embraces cloud native. In November 2021, we will release Dubbo 3.1 version, which will bring Dubbo's best practices for deployment in Mesh scenarios.
Dubbo 3.2 version will be released in March 2022. This version will bring full support for service flexibility, realize intelligent traffic scheduling under large-scale application deployment, and improve system stability and resource utilization.
Looking back, Dubbo and HSF have played a vital role in different stages of the development of Alibaba and the microservice framework. Based on the present and looking to the future, Dubbo 3.0 and HSF based on the Dubbo 3.0 kernel are going hand in hand externally and internally to build the most stable and high-performance microservice framework, giving users the best experience, and continuing to lead the development of microservices in the cloud-native era.
Author introduction: __Guo Hao, head of Alibaba service framework, Dubbo 3.0 architect, focusing on distributed system architecture
﹀
﹀
﹀
[Submit review and draw Tmall Wizard]
The 2021 Cloud Native Programming Challenge officially starts the evaluation, and the contestants submit the evaluation after registration. The background will draw 10 every week . 1614c421ad1c89 winning teams will be given 1 Tmall wizard. Click the link to register now!
https://tianchi.aliyun.com/competition/entrance/531923/introduction
Copyright Notice: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and the copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。