Brief introduction:A new milestone!
The background,
Since Apache Dubbo was open source in 2011, IT has accumulated a lot of experience in the practice of a number of large-scale Internet and IT companies. Dubbo has achieved great success in the past by virtue of its advantages of Java user-friendly, rich features and strong governance. It has become one of the popular mainstream RPC frameworks at home and abroad.
However, with the arrival of the Cloud native era, the Java micro-service governance system represented by Apache Dubbo and Spring Cloud is faced with many new requirements, including the expectation that the application can be started faster, the protocol penetration of application communication can be higher, and the multi-language support can be more friendly. Spring, for example, also launched its GraalVM-based Spring Native Beta solution this year, with optimized improvements such as millisecond startup capability and higher processing performance.
This background puts forward two major requirements for the next generation of Apache Dubbo: one is to retain the advantages of existing out-of-the-box and off-the-shelf practices, which is also expected by many developers; The second is to follow the idea of cloud native as much as possible, which can better reuse the underlying cloud native infrastructure and better fit the micro-service architecture of cloud native.
Second, embrace the cloud native
In today’s context, Apache Dubbo 3 chose to fully embrace cloud nativity, upgrade the Dubbo architecture, and put forward a new service discovery model, the next generation RPC protocol, cloud native infrastructure adaptation and other optimization schemes.
1. New service discovery model (application-level service discovery)
Application level registration model
In Dubbo’s original design, the data stored in the registry was largely duplicates, which actually wasted some of the storage. When the size of the entire cluster is large enough, the amount of data in the registry will grow explosively due to the discovery of the service registry in the service dimension.
Spring Cloud and GRPC, which are also microservice governance tools, are application-level service discovery tools. If the interface level registration is still used, it is difficult for Dubbo to communicate with them. But if Dubbo could be registered at the service level like the Spring Cloud, it would work easily in a heterogeneous environment.
Deploy the scheme under heterogeneity
The application-level service discovery mechanism is an important step for Apache Dubbo towards the cloud. It helps Apache Dubbo to bridge the gap in address discovery between Apache Dubbo and other microservices. It also becomes the basis for Apache Dubbo to adapt to infrastructure such as Kubernetes Native Service.
Based on application-level service discovery, registry data will be reorganized, greatly reducing the pressure on the registry. At the same time, the memory consumption of the application itself can be greatly reduced due to the reduced number of addresses.
Performance improvement
In a typical case, the number of addresses stored in an application can be reduced by about half, and even more than 95% for a large-scale upstream application deployment (e.g., 1000 nodes deployed and 50 services provided), which can be a huge optimization for a memory stressed environment in a core application.
The next generation RPC protocol, Triple
In the cloud native era, the Dubbo RPC protocol faces two major challenges:
1. No ecological interconnection. Dubbo protocol customizes the core semantics strongly bound with RPC based on binary stream, including protocol header, flag bit, request ID and request/response data, etc. For the growing number of cloud-native governance facilities, it’s not easy to get all of them to “read” the binary “semantics” of Dubbo.
2. Due to the problem of protocol design, the protocol header of DUBBO can no longer carry more metadata information. Gateway components, such as Mesh, need to parse the entire packet to obtain the necessary metadata information (such as RPC context) in order to manage the data, which will face challenges from performance to ease of use.
DUBBO protocol communication mode
Under the premise of supporting the existing functions and solving the existing problems, Apache Dubbo 3 proposes the next generation RPC protocol — Triple.
Based on the TRIPE protocol, we expect to solve these problems:
1. Cross-language communication. Both the traditional multi-language multi-SDK pattern and the Mesh cross-language pattern need a more general and easily extensible data transmission format.
2. Provide a more complete request model. Streaming and Bidirectional should be supported in addition to the Request/Response model;
Request Model Diagram
3, easy to expand, high penetration. Support, including but not limited to Tracing/Monitoring, should also be recognized by devices at all layers. Gateway facilities, etc., can recognize data packets and make Service Mesh deployment friendly and easy for users to understand.
4. Support non-awareness upgrade for Java users. You can easily upgrade to the Triple protocol by simply changing the protocol name without having to define a cumbersome IDL file.
Based on these expectations, we feel that it is most reasonable to use ProtoBuf as a combination of the serialization protocol and HTTP/2 as the underlying communication protocol, which is also used by the GRPC protocol. So for the Triple protocol, we can evolve the GRPC protocol to meet the existing features of Apache Dubbo, while ensuring that the new protocol and GRPC are interoperable and shared across the ecosystem.
Triple protocol communication mode
3. Access to cloud native facilities
For the Kubernetes scenario, Apache Dubbo 3 does two things for this:
First, native support is aligned with the Kubernetes POD life cycle. Based on the Dubbo QoS mechanism, Kubernetes can sense the current state of the Dubbo application running in the POD container. And thanks to the Dubbo SPI mechanism, users can customize the dimensions of probe detection, so the framework and business life cycle are unified.
Second, Dubbo will also support access to Kubernetes Native Service system, and Native support for the Service discovery system based on Kubernetes API Server and DNS, so as to realize the alignment of the Service concepts under the deployment architecture with those in Dubbo.
Deployment scheme under Kubernetes architecture
For the Service Mesh system, if the application uses Apache Dubbo 2 and wants to deploy in the Mesh mode, it needs to use Sidecar to intercept the Dubbo traffic. At the same time, because Dubbo itself has certain governance ability, From the application point of view, it will do a lot of unnecessary things, and from the cluster point of view, it will cause the call clutter.
Based on this, Apache Dubbo 3 proposed two deployment modes, one is the Thin SDK mode with the deployment of Sidecar, the other is the Proxyless Mesh mode with direct access to the control surface.
Dubbo 3 deploys the architecture in a Mesh scenario
In addition to the deployment architecture access, Apache Dubbo 3 also defines a set of cloud-oriented native traffic governance, supporting the traditional SDK, Mesh scenario unified governance rules.
Apache Dubbo 3 expects to use this set of rules to achieve rich routing semantics such as Canary publishing, A/B testing, and so on. Just need to configure A set of rules, written into A unified control surface, can control all clusters uniformly. In this way, direct deployment with Kubernetes, mixed deployment with Thin SDK or Proxyless for Mesh scenarios, or even manual cluster deployment by users can all be controlled by the same set of rules, achieving the goal of defining once and using everywhere.
Third, the future outlook
Apache Dubbo 3.0.0 is a milestone release after being donated to Apache and represents an important node in Apache Dubbo’s full embrace of cloud nativeness.
In November 2021 we will release version 3.1 of Apache Dubbo, when we will bring you the implementation and practice of Apache Dubbo deployment in Mesh scenarios.
In March 2022, we will release version 3.2 of Apache Dubbo, where we will bring a new intelligent traffic scheduling mechanism for large-scale deployments that will improve system stability and resource utilization.
Apache Dubbo 3 has been integrated with Alibaba Group’s internal RPC framework, and is expected to use it to solve the internal landing problems and achieve the unity of the technology stack. In the future, Apache Dubbo 3 will be placed in Ali Group on a large scale, bearing the complex business scenes of 618 and Singles’ Day.
The community sincerely hopes that everyone is welcome to submit the issue and PR to the community, and the students of the community will review and reply as soon as possible. In addition, the community will try to ensure a short release cycle, timely repair of existing issues.
At the same time, starting with Apache Dubbo 3, the community will also be more open to customization requirements for production environments. We welcome you to contribute your custom implementations to the open source community, and the Dubbo-SPi-Extensions repository will support these customizations in the future.
Copyright Notice:The content of this article is contributed by Aliyun real-name registered users, and the copyright belongs to the original author. Aliyun developer community does not own the copyright and does not bear the corresponding legal liability. For specific rules, please refer to User Service Agreement of Alibaba Cloud Developer Community and Guidance on Intellectual Property Protection of Alibaba Cloud Developer Community. If you find any suspected plagiarism in the community, fill in the infringement complaint form to report, once verified, the community will immediately delete the suspected infringing content.