| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Apache Dubbo – What is Dubbo</title><link>https://dubbo.apache.org/en/overview/what/</link><description>Recent content in What is Dubbo on Apache Dubbo</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://dubbo.apache.org/en/overview/what/index.xml" rel="self" type="application/rss+xml"/><item><title>Overview: Introduction to Dubbo</title><link>https://dubbo.apache.org/en/overview/what/overview/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/overview/what/overview/</guid><description> |
| <p>Apache Dubbo is an RPC service development framework, which is used to solve service governance and communication problems under the microservice architecture. It officially provides multi-language SDK implementations such as Java and Golang. Microservices developed using Dubbo are natively capable of remote address discovery and communication with each other. |
| Using the rich service governance features provided by Dubbo, service governance demands such as service discovery, load balancing, and traffic scheduling can be realized. Dubbo is designed to be highly scalable, and users can easily implement various custom logics for traffic interception and location selection.</p> |
| <p>Dubbo3 is defined as a cloud-native-oriented next-generation RPC service framework. 3.0 has evolved based on Dubbo 2.x. While maintaining the original core features, Dubbo3 has improved in ease of use, ultra-large-scale microservice practice, cloud-native infrastructure adaptation, and security. Comprehensive upgrades have been made in several major directions, including ease of use, hyperscale microservice practices, cloud-native infrastructure adaptation, and security.</p> |
| <h3 id="what-is-dubbo">What is Dubbo</h3> |
| <p>Apache Dubbo was originally donated by Alibaba as an open source in 2008, and soon became the de facto standard framework for the selection of open source service frameworks in China, and has been widely used in various industries. In 2017, Dubbo officially donated to the Apache Software Foundation and became a top-level project of Apache. Currently, Dubbo3 is already a one-stop microservice solution providing:</p> |
| <ul> |
| <li>HTTP/2-based <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/">Triple protocol</a> and programming experience for proxy API.</li> |
| <li>Powerful [traffic management capability] (../../tasks/traffic-management), such as address discovery, load balancing, routing address selection, dynamic configuration, etc.</li> |
| <li><a href="../../mannual/">Multi-language SDK implementation</a>, covering Java, Golang, Javascript, etc. More language implementations will be released in succession.</li> |
| <li>Flexible adaptation and expansion capabilities, which can be easily adapted to other components of the microservice system such as Tracing and Transaction.</li> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/mesh/">Dubbo Mesh Solution</a>, while supporting flexible Mesh deployment solutions such as Sidecar and Proxyless.</li> |
| </ul> |
| <p>The overall architecture of Apache Dubbo can well meet the large-scale microservice practice of enterprises, because it is designed to solve the practical problems of ultra-large-scale microservice clusters from the beginning, whether it is Alibaba, ICBC, China Ping An, Ctrip and other community users, They have fully verified the stability and performance of Dubbo through years of large-scale production environment traffic. Therefore, Dubbo has unparalleled advantages in solving business landing and large-scale practice:</p> |
| <ul> |
| <li>out of the box |
| <ul> |
| <li>High ease of use, such as the interface-oriented proxy feature of the Java version can realize local transparent calls</li> |
| <li>Rich in functions, most of the microservice governance capabilities can be realized based on native libraries or lightweight extensions</li> |
| </ul> |
| </li> |
| <li>Designed for ultra-large-scale microservice clusters |
| <ul> |
| <li>Extreme performance, high-performance RPC communication protocol design and implementation</li> |
| <li>Horizontally scalable, easily supporting address discovery and traffic management of millions of cluster instances</li> |
| </ul> |
| </li> |
| <li><a href="../extensibility">highly extensible</a> |
| <ul> |
| <li>Interception and extension of traffic and protocols during calling, such as Filter, Router, LB, etc.</li> |
| <li>Extension of microservice governance components, such as Registry, Config Center, Metadata Center, etc.</li> |
| </ul> |
| </li> |
| <li>Enterprise-level microservice governance capabilities |
| <ul> |
| <li>The de facto standard service framework supported by domestic public cloud vendors</li> |
| <li>Years of enterprise practical experience test</li> |
| </ul> |
| </li> |
| </ul> |
| <h3 id="dubbo-basic-workflow">Dubbo basic workflow</h3> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/rpc.png" alt="dubbo-rpc"></p> |
| <p>First of all, Dubbo is an RPC framework, which defines its own RPC communication protocol and programming method. As shown in the figure above, when using Dubbo, users first need to define the Dubbo service; secondly, after deploying the Dubbo service online, rely on Dubbo&rsquo;s application layer communication protocol to realize data exchange, and the data transmitted by Dubbo must be serialized. And here the serialization protocol is fully extensible. |
| The first step in using Dubbo is to define Dubbo services. The definition of services in Dubbo is a set of methods to complete business functions. You can choose to define them in a way that is bound to a certain language. For example, in Java, Dubbo services have a set of The Interface interface of the method can also use the language-neutral Protobuf Buffers <a href="../../tasks/triple/idl/">IDL definition service</a>. After the service is defined, the server (Provider) needs to provide a specific implementation of the service and declare it as a Dubbo service. From the perspective of the service consumer (Consumer), a service proxy can be obtained by calling the API provided by the Dubbo framework ( stub) object, and then you can call the service method like a local service. |
| After the consumer initiates a call to the service method, the Dubbo framework is responsible for sending the request to the service provider deployed on the remote machine. After receiving the request, the provider will call the implementation class of the service, and then return the processing result to the consumer. This completes a complete service call. The data flow of Request and Response in the figure is shown.</p> |
| <blockquote> |
| <p>It should be noted that in Dubbo, when we refer to services, we usually refer to RPC-grained interfaces or methods that provide the function of adding, deleting, and modifying a specific business, which is not the same as the services generally referred to in some microservice concept books concept.</p> |
| </blockquote> |
| <p>In a distributed system, especially with the development of the microservice architecture, the deployment, release, and scaling of applications become extremely frequent. As an RPC consumer, how to dynamically discover the address of the service provider becomes a precondition for RPC communication . Dubbo provides an automatic address discovery mechanism to deal with the dynamic migration of machine instances in distributed scenarios. As shown in the figure below, the address of the provider and the consumer is coordinated by introducing the registration center. After the provider starts, it registers its own address with the registration center, and the consumer dynamically perceives the address list of the provider by pulling or subscribing to a specific node in the registration center. Variety.</p> |
| <p><img src="https://dubbo.apache.org/imgs/architecture.png" alt="arch-service-discovery"></p> |
| <h3 id="dubbo-core-features">Dubbo core features</h3> |
| <h4 id="high-performance-rpc-communication-protocol">High performance RPC communication protocol</h4> |
| <p>Service communication across processes or hosts is a basic capability of Dubbo. Dubbo RPC sends the request data (Request) to the backend service in a predefined protocol encoding method, and receives the calculation result (Response) returned by the server. RPC communication is completely transparent to the user, and the user does not need to care about how and where the request is sent, and only needs to get the correct call result for each call. In addition to the Request-Response communication model in synchronous mode, Dubbo3 also provides a richer selection of communication models:</p> |
| <ul> |
| <li>Consumer side asynchronous request (Client Side Asynchronous Request-Response)</li> |
| <li>Provider side asynchronous execution (Server Side Asynchronous Request-Response)</li> |
| <li>Consumer request stream (Request Streaming)</li> |
| <li>Provider response stream (Response Streaming)</li> |
| <li>Bidirectional Streaming</li> |
| </ul> |
| <p>For details, please refer to the list of optional protocols implemented by each language SDK or <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/">Triple Protocol</a></p> |
| <h4 id="automatic-service-address-discovery">Automatic service (address) discovery</h4> |
| <p>Dubbo&rsquo;s service discovery mechanism allows microservice components to evolve independently and be deployed arbitrarily, and the consumer can complete communication without knowing the deployment location and IP address of the peer. Dubbo provides a Client-Based service discovery mechanism, and users can enable service discovery in various ways:</p> |
| <ul> |
| <li>Use independent registry components, such as <a href="https://nacos.io/">Nacos</a>, Zookeeper, Consul, Etcd, etc.</li> |
| <li>Leave the organization and registration of services to the underlying container platform, such as Kubernetes, which is understood to be a more cloud-native usage</li> |
| </ul> |
| <h4 id="run-state-traffic-control">Run state traffic control</h4> |
| <p>Transparent address discovery allows Dubbo requests to be sent to any IP instance, and traffic is randomly allocated during this process. When richer and finer-grained control of traffic is required, Dubbo&rsquo;s traffic control strategy can be used. Dubbo provides strategies including load balancing, traffic routing, request timeout, traffic degradation, retry, etc., based on these basic capabilities You can easily implement more scenario-based routing solutions, including canary release, A/B testing, weight routing, same-region priority, etc. What&rsquo;s even cooler is that Dubbo supports traffic control policies to take effect dynamically in the running state without redeployment . For details, please refer to:</p> |
| <ul> |
| <li><a href="../../tasks/traffic-management">Traffic management example</a></li> |
| </ul> |
| <h4 id="rich-extension-components-and-ecology">Rich extension components and ecology</h4> |
| <p>Dubbo&rsquo;s powerful service governance capabilities are not only reflected in the core framework, but also include its excellent expansion capabilities and the support of surrounding supporting facilities. Through the definition of extension points that exist in almost every key process, such as Filter, Router, and Protocol, we can enrich Dubbo&rsquo;s functions or realize the connection with other microservice supporting systems, including Transaction and Tracing. Currently, there are implementations that extend through SPI For details, please refer to the details of Dubbo extensibility, and you can also find more extension implementations in the <a href="https://github.com/apache/dubbo-spi-extensions">apache/dubbo-spi-extensions</a> project. For details, please refer to:</p> |
| <ul> |
| <li><a href="../../what/ecosystem">Dubbo Ecosystem</a></li> |
| <li><a href="../../what/extensibility">Dubbo Extensibility Design</a></li> |
| </ul> |
| <h4 id="cloud-native-design">Cloud Native Design</h4> |
| <p>Dubbo is designed to fully follow the development concept of cloud-native microservices, which is reflected in many aspects. First, it supports cloud-native infrastructure and deployment architecture, including containers, Kubernetes, etc. The overall solution of Dubbo Mesh is also in version 3.1 Official release; on the other hand, many core components of Dubbo have been upgraded for cloud native, including Triple protocol, unified routing rules, and support for multiple languages.</p> |
| <p>It is worth mentioning that how to use Dubbo to support elastic scaling services such as Serverless is also planned in the future, including using Native Image to improve Dubbo&rsquo;s startup speed and resource consumption.</p> |
| <p>Combined with the current version, this section mainly expands Dubbo&rsquo;s cloud-native features from the following two points</p> |
| <ul> |
| <li><a href="../../tasks/kubernetes/deploy-on-k8s">Container Scheduling Platform (Kubernetes)</a></li> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/mesh/">Dubbo Mesh</a></li> |
| </ul> |
| <h5 id="kubernetes">Kubernetes</h5> |
| <p>For Dubbo microservices to support Kubernetes platform scheduling, the most basic thing is to realize the alignment of the dubbo service life cycle and the container life cycle, which includes life cycle events such as Dubbo startup, destruction, and service registration. Compared with the past where Dubbo defined life cycle events by itself and required developers to abide by the agreement during operation and maintenance practice, the underlying infrastructure of Kubernetes defines strict component life cycle events (probes), and instead requires Dubbo to adapt according to the agreement.</p> |
| <p>Kubernetes Service is another level of adaptation, which reflects the trend of service definition and registration sinking to the cloud-native underlying infrastructure. In this mode, users no longer need to build additional registry components, Dubbo consumer end nodes can automatically connect to Kubernetes (API-Server or DNS), and query the instance list (Kubernetes endpoints) according to the service name (Kubernetes Service Name) . At this point, the service is defined through the standard Kubernetes Service API and dispatched to each node.</p> |
| <h5 id="dubbo-mesh">Dubbo Mesh</h5> |
| <p>Service Mesh has been widely disseminated and recognized in the industry, and is considered to be the next-generation microservice architecture, mainly because it solves many difficult problems, including transparent upgrades, multilingualism, dependency conflicts, and traffic management. The typical architecture of Service Mesh is to intercept all egress and ingress traffic by deploying independent Sidecar components, and integrate rich traffic management strategies such as load balancing and routing in Sidecar. In addition, Service Mesh also requires a control plane (Control Panel) to realize the control of Sidecar traffic, that is, to issue various policies. We call this architecture here Classic Mesh.</p> |
| <p>However, no technical architecture is perfect, and classic Mesh also faces the problem of high cost at the implementation level</p> |
| <ol> |
| <li>Operation and maintenance control panel (Control Panel) is required</li> |
| <li>Need to operate and maintain Sidecar</li> |
| <li>Need to consider how to migrate from the original SDK to Sidecar</li> |
| <li>It is necessary to consider the performance loss of the entire link after introducing Sidecar</li> |
| </ol> |
| <p>In order to solve the related cost problems introduced by Sidecar, Dubbo introduced and implemented a new Proxyless Mesh architecture. As the name suggests, Proxyless Mesh refers to the deployment without Sidecar, and the Dubbo SDK directly interacts with the control plane. The architecture diagram is as follows</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/dubbo-proxyless.png" alt="dubbo-proxyless"></p> |
| <p>It can be imagined that in different organizations and different development stages, microservices built with Dubbo will allow three deployment architectures in the future: traditional SDK, Sidecar-based Service Mesh, and Proxyless Mesh without Sidecar. Based on Sidecar&rsquo;s Service Mesh, that is, the classic Mesh architecture, the independent sidecar runtime takes over all the traffic, separate from the Sidecar&rsquo;s Proxyless Mesh, and the secondary SDK directly communicates with the control plane through xDS. Dubbo microservices allow deployment on physical machines, containers, and Kubernetes platforms, and can use Admin as the control plane and manage them with unified traffic governance rules.</p></description></item><item><title>Overview: Dubbo 3 Quick Facts</title><link>https://dubbo.apache.org/en/overview/what/dubbo3/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/overview/what/dubbo3/</guid><description> |
| <p>This article will take you to quickly understand the design background, overall architecture and core features of Dubbo3, and its relationship with typical users such as Alibaba HSF2, etc. You can also learn more in the following sections:</p> |
| <ul> |
| <li><strong>New users, take a quick look at the core features of Dubbo3:</strong> |
| <ul> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/">Next Generation Communication Protocol - Triple</a></li> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/">Secrets of a million-instance cluster - application-level service discovery</a></li> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/mesh/">Dubbo Mesh</a></li> |
| </ul> |
| </li> |
| <li><strong>Dubbo3 compatibility and migration cost?</strong> |
| <ul> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/upgrades-and-compatibility">Java - Migration Guide</a></li> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/golang-sdk/">Golang - Migration Guide</a></li> |
| </ul> |
| </li> |
| <li><strong>Dubbo3 related resources:</strong> |
| <ul> |
| <li>For more information, such as performance indicators, advanced feature descriptions, etc., please refer to <a href="https://dubbo.apache.org/en/overview/mannual/">Multilingual SDK Implementation</a></li> |
| <li>Speeches and offline activities</li> |
| </ul> |
| </li> |
| </ul> |
| <h3 id="background">background</h3> |
| <p>The design and development of Dubbo3 has two major backgrounds.</p> |
| <p>**First, how to better meet the demands of corporate practice. ** Since Dubbo was donated by Alibaba in 2011, it has been the preferred open source service framework for many large-scale enterprise microservice practices. During this period, the enterprise architecture has undergone changes from the SOA architecture to the microservice architecture, and the Dubbo community itself is constantly updating and iterating to better meet the demands of the enterprise. However, the limitations of Dubbo2 architecture are gradually highlighted in practice:</p> |
| <ul> |
| <li><strong>Protocol</strong>, the Dubbo2 protocol is famous for its performance and simplicity, but it encounters more and more problems of versatility and penetration in the cloud-native era;</li> |
| <li><strong>Scalability</strong>, Dubbo2 is still far superior to many other frameworks in terms of scalability, but as microservices bring more applications and instances, we have to think about how to deal with the actual combat of larger-scale clusters;</li> |
| <li><strong>Service Governance Ease of Use</strong>, such as richer traffic governance, observability, intelligent load balancing, etc.</li> |
| </ul> |
| <p>**Secondly, adapt to the development of cloud native technology stack. ** While microservices make the evolution of business development more flexible and fast, it also brings some unique features and requirements: such as the number of components after microservices is increasing, how to solve the stability of each component, how to quickly Horizontal expansion, etc., cloud-native infrastructure represented by Docker, Kubernetes, and Service Mesh has brought some new options to solve these problems. As more microservice components and capabilities are sinking to the infrastructure layer represented by Kubernetes, the traditional microservice development framework should eliminate some redundant mechanisms and actively adapt to the infrastructure layer to achieve capability reuse. Capabilities such as the life cycle and service governance of the microservice framework should be better integrated with the Kubernetes service orchestration mechanism; the microservice architecture represented by Service Mesh brings new options to microservice development, and Sidecar brings multilingual, transparent upgrades, and traffic control However, it also brings disadvantages such as operation and maintenance complexity and performance loss. Therefore, the traditional microservice system based on the service framework will still be the mainstream, and will still occupy half of the country in the long run, and will maintain mixed deployment for a long time state.</p> |
| <h3 id="overall-objective">Overall objective</h3> |
| <p>Dubbo3 still maintains the classic architecture of 2.x. Its main responsibility is to solve the communication between microservice processes, and to better manage and control microservice clusters through rich service governance (such as address discovery, traffic management, etc.); The upgrade of the framework is comprehensive, reflected in almost every aspect of the core Dubbo features, through the upgrade to achieve a comprehensive improvement in stability, performance, scalability, and ease of use.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/architecture-1.png" alt="architecture-1"></p> |
| <ul> |
| <li><strong>Common communication protocol.</strong> The new RPC protocol should abandon the private protocol stack, use the more general HTTP/2 protocol as the transport layer carrier, and use the standardized features of the HTTP protocol to solve the problems of traffic versatility and penetration, so that the protocol can better respond Scenarios such as front-end and back-end docking, gateway proxy, etc.; supports the Stream communication mode, which meets the demands of different business communication models and brings greater throughput to the cluster.</li> |
| <li><strong>For millions of cluster instances, the cluster is highly scalable.</strong> With the promotion of micro-service practices, the scale of micro-service cluster instances is also constantly expanding, which benefits from the characteristics of light-weight micro-services and easy horizontal expansion, but also brings a burden to the entire cluster capacity, especially It is some centralized service governance components; Dubbo3 needs to solve various resource bottlenecks caused by the expansion of instance scale, and realize truly unlimited horizontal expansion.</li> |
| <li><strong>Richer programming model, less business intrusion.</strong> In the development state, the business application is programmed for Dubbo SDK. In the running state, the SDK and the business application run in the same process. The ease of use, stability and resource consumption of the SDK will greatly affect the business application; therefore, 3.0 should have More abstract API, more friendly configuration mode, less encroachment on business application resources, and higher availability.</li> |
| <li><strong>Easier to use and richer service governance capabilities.</strong> The dynamic nature of microservices has brought high complexity to the governance work, and Dubbo has been doing a good job in this regard. It is the earliest batch of governance capability definers and practitioners; 3.0 needs to be oriented to richer scenarios. Provides capabilities such as observability, security, grayscale release, error injection, external configuration, and unified governance rules.</li> |
| <li><strong>Fully embrace cloud native.</strong></li> |
| </ul> |
| <h3 id="facing-the-pain-points-of-enterprise-production-practice">Facing the pain points of enterprise production practice</h3> |
| <p>Dubbo2 is still the preferred open source service framework in China. It is widely used in almost all digital transformation enterprises such as the Internet, financial insurance, software companies, and traditional enterprises, and has been tested in a large-scale production environment. Take Alibaba, a contributor and typical user of Dubbo2, as an example. The HSF2 framework maintained internally by Alibaba based on Dubbo2 has experienced previous double-eleven peak tests. Billions of RPC calls are made every day, and more than ten million service instances are managed. In the long-term optimization and practical accumulation, Alibaba has a vision and plan for the next-generation service framework, and began to evolve rapidly internally, and was quickly contributed to the Apache community. Just like Alibaba, the practical demands of other users are related to Pain points are also rapidly accumulating in the open source community, forming a consistent direction and technical solutions. It can be said that the birth of Dubbo3 comes from the accumulation of a large base of enterprise users, in order to better meet their practical demands.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/dubbo-hsf.png" alt="dubbo3-hsf"></p> |
| <p>Dubbo3 integrates a large amount of service management experience of Alibaba HSF2 and other community enterprises. Currently, Dubbo3 has been fully applied to the production practice environment. Banks, Fenghuodi, Ping An Health, etc. The virtuous circle formed by the cooperation between the community and users has greatly promoted the development of Dubbo3. Alibaba has completely replaced the internally maintained HSF2 framework with the community version of Dubbo3. Their practical experience has promoted the stability of Dubbo3 on the one hand, and is positively It is enough to continuously export the practical experience of service governance to the open source community.</p> |
| <h3 id="for-millions-of-cluster-instances-horizontal-scalability">For millions of cluster instances, horizontal scalability</h3> |
| <p>With the accumulation of practical experience in microservices, microservices are split into finer grains and deployed to more and more machine instances to support the growing business scale. Among many Dubbo2 enterprise users, especially large-scale enterprises represented by finance, insurance and the Internet, they began to encounter cluster capacity bottlenecks (for typical cases, please refer to Industrial and Commercial Bank of China Practice Cases:</p> |
| <ul> |
| <li><strong>Service discovery process</strong> |
| <ul> |
| <li>The data storage scale of the registration center reaches the capacity bottleneck</li> |
| <li>Data registration &amp; push efficiency is seriously reduced</li> |
| </ul> |
| </li> |
| <li><strong>Dubbo Process</strong> |
| <ul> |
| <li>Occupy more machine resources, resulting in lower utilization of business resources</li> |
| <li>Frequent GC affects business stability</li> |
| </ul> |
| </li> |
| </ul> |
| <p>Dubbo3 solves these problems very well in design. The service governance (service discovery) model implemented through the new design can realize the data transmission and data storage on the service discovery link to reduce by about 90% on average; at the same time, Dubbo3 itself is in the business In the process, it becomes lighter and more stable, achieving a 50% increase in resource utilization.</p> |
| <p>A greater advantage of Dubbo3 lies in its improvement of the stability of the overall architecture. The new service discovery architecture makes it easier and more accurate to evaluate the capacity and scalability of the entire cluster.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/capacity.png" alt="capacity"></p> |
| <p>If application development is roughly divided into two levels: business development and operation and maintenance deployment, factors that change frequently include services (interfaces), applications, and machine instances. In the 2.x era, the growth of all these three factors will affect the overall capacity of the microservice cluster, especially the fluctuation caused by the increase or decrease of interfaces, which is very opaque to the overall capacity assessment. In 3.0, the change of cluster capacity is only related to the two factors of application name and machine instance, and the objects of capacity evaluation are often applications and instances, so the entire cluster becomes more stable and transparent.</p> |
| <h3 id="cloud-native">Cloud Native</h3> |
| <p>In the cloud-native era, changes in the underlying infrastructure are profoundly affecting application deployment, operation and maintenance, and even the development process. It also affects the selection and deployment mode of Dubbo3 microservice technology solutions.</p> |
| <h4 id="next-generation-rpc-protocol">Next Generation RPC Protocol</h4> |
| <p>The new-generation Triple protocol is based on HTTP/2 as the transport layer, has better gateway and proxy penetration, natively supports Stream communication semantics, and is compatible with the gRPC protocol.</p> |
| <h4 id="multilingual-friendly">Multilingual Friendly</h4> |
| <p>Dubbo3 has taken multilingual friendliness as a key consideration in terms of service definition, RPC protocol, serialization, and service governance. Currently, it provides stable multilingual versions of Java and Golang, and 3.0 implementations of more language versions such as Rust , Javascript, C/C++, C#, etc. are under development and construction.</p> |
| <h4 id="kubernetes">Kubernetes</h4> |
| <p>Applications developed by Dubbo3 can be natively deployed on the Kubernetes platform. Dubbo3 has been designed to be aligned with container scheduling platforms such as Kubernetes in terms of address and life cycle; for users who want to further reuse the underlying infrastructure capabilities of Kubernetes, Dubbo3 has also been connected to the native The Kubernetes Service system.</p> |
| <h4 id="service-mesh">Service Mesh</h4> |
| <p>Service Mesh emphasizes the role of the control plane in microservice governance, which to a certain extent promotes the expansion and standardization of the control plane communication protocol and scope of responsibility; the Sidecar model under the traditional Mesh architecture emphasizes the unified control of traffic by bypass agents to achieve Features such as transparent upgrade, multilingual non-sense, and no business intrusion.</p> |
| <p>Dubbo3 provides a Dubbo Mesh solution based on its own thinking, emphasizing the unified management and control of microservice clusters. In terms of deployment architecture, it supports both sicecar and proxyless deployment architecture without sidecar. Users who use Dubbo Mesh are based on their own business Features will have more options for deployment architectures.</p> |
| <h4 id="heterogeneous-system-interoperability">Heterogeneous System Interoperability</h4> |
| <p>We are seeing more and more requests for interoperability of heterogeneous microservice systems, such as Dubbo, Spring Cloud, gRPC, etc. Some are due to the migration of the technology stack, and some are due to the need to achieve business intermodulation after the merger of the organization. With the help of the new service discovery model and the flexible and scalable RPC protocol, Dubbo3 can become the future development goal of Dubbo3.</p></description></item><item><title>Overview: Architecture</title><link>https://dubbo.apache.org/en/overview/what/architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/overview/what/architecture/</guid><description> |
| <h2 id="rpc-communication">RPC communication</h2> |
| <p>Dubbo3&rsquo;s Triple protocol is built on the HTTP/2 protocol, so it has better penetration and versatility. The Triple protocol is compatible with gRPC and provides communication models such as Request Response, Request Streaming, Response Streaming, and Bi-directional Streaming; from Triple Starting from the agreement, Dubbo also supports IDL-based service definition.</p> |
| <p>In addition, Dubbo also integrates most of the industry&rsquo;s mainstream protocols, allowing users to use these communication protocols within the Dubbo framework, providing users with a unified programming model and service governance model, these protocols include rest, hessian2, jsonrpc, thrift, etc. , note that there will be some differences in the range supported by different language SDK implementations.</p> |
| <p>Details can be viewed</p> |
| <ul> |
| <li><a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/">Triple Quick Facts</a></li> |
| <li><a href="https://github.com/apache/dubbo-awesome/blob/master/proposals/D0-triple.md">Specification</a></li> |
| </ul> |
| <h2 id="service-discovery">Service Discovery</h2> |
| <p>Service discovery, that is, the ability of the consumer to automatically discover the list of service addresses, is a key capability that the microservice framework needs to have. With the help of automated service discovery, microservices can be implemented without knowing the deployment location and IP address of the peer. communication.</p> |
| <p>There are many ways to realize service discovery. Dubbo provides a Client-Based service discovery mechanism. Usually, additional third-party registry components need to be deployed to coordinate the service discovery process, such as the commonly used [Nacos](https:/ /nacos.io/), Consul, Zookeeper, etc. Dubbo itself also provides the connection to various registry components, and users can choose flexibly.</p> |
| <p>Dubbo is based on the automatic service discovery capability of the consumer, and its basic working principle is as follows:</p> |
| <p><img src="https://dubbo.apache.org/imgs/architecture.png" alt="architecture"></p> |
| <p>Under the traditional deployment architecture, service discovery involves three participating roles: provider, consumer, and registration center. Among them, the provider registers the URL address to the registration center, the registration center is responsible for aggregating data, and the consumer subscribes to the URL address from the registration center. renew. |
| In the context of cloud native, for example, when the application is deployed on a platform such as Kubernetes, since the platform itself maintains the mapping relationship between the application/service and the instance, the registration center and the registration action are sinked to the infrastructure layer to a certain extent, so the framework Own registration action is sometimes not necessary.</p> |
| <p>Dubbo3 provides a new application-level service discovery model, which is different from Dubbo2&rsquo;s interface-level service discovery model in terms of design and implementation. It can be viewed here:</p> |
| <ul> |
| <li>[Application-level service discovery](/en/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/#Introduction to application-level service discovery)</li> |
| </ul> |
| <h2 id="traffic-management">Traffic management</h2> |
| <p>Since Dubbo2, Dubbo has provided rich service governance rules, including routing rules, dynamic configuration, etc.</p> |
| <p>On the one hand, Dubbo3 is connecting to the governance rules represented by VirtualService and DestinationRule used in popular Mesh products such as Istio by docking xDS; on the other hand, Dubbo is seeking to design a set of its own rules to achieve Traffic governance, and flexible governance capabilities.</p> |
| <ul> |
| <li><a href="../../tasks/traffic-management">Dubbo2 Service Governance Rules</a></li> |
| <li>Dubbo3 service governance rules</li> |
| </ul> |
| <h2 id="dubbo-mesh">Dubbo Mesh</h2> |
| <p>The goal of Dubbo Mesh is to provide a complete Mesh solution adapted to the Dubbo system, including customized control plane (Control Plane) and customized data plane solutions. The Dubbo control plane is based on the industry&rsquo;s mainstream Istio extension, and supports richer traffic governance rules, Dubbo application-level service discovery models, etc. The Dubbo data plane can use Envoy Sidecar, which implements the deployment solution of Dubbo SDK + Envoy, or Dubbo Proxyless mode. Directly realize the communication between Dubbo and the control plane. Dubbo Mesh is undergoing rapid evolution, we will try our best to keep the content of the document updated.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/mix-mesh.png" alt="mix-mesh"></p> |
| <p>View Dubbo Mesh design details here</p> |
| <ul> |
| <li><a href="https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.1-thinsdk-sidecar-mesh.md">Dubbo Proxy Mesh</a></li> |
| <li><a href="https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md">Dubbo Proxyless Mesh</a></li> |
| <li><a href="https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md">Dubbo Control Plane</a></li> |
| </ul> |
| <h2 id="deployment-architecture">Deployment Architecture</h2> |
| <blockquote> |
| <p>This section focuses on describing the Dubbo deployment architecture in the traditional mode. The deployment architecture in the cloud-native background will change, mainly reflected in the fact that the infrastructure (Kubernetes, Service Mesh, etc.) will take on more responsibilities. |
| The responsibilities of centralized components such as registration center, metadata center, configuration center, etc. are integrated, and operation and maintenance become simpler, but by emphasizing these centralized components, it is easier for us to understand the working principle of Dubbo.</p> |
| </blockquote> |
| <p>As a micro-service framework, Dubbo sdk is deployed in each location of the distributed cluster along with the micro-service components. In order to realize the cooperation between various micro-service components in a distributed environment, |
| Dubbo defines some centralized components, including:</p> |
| <ul> |
| <li>Registry. Coordinate address registration and discovery between Consumer and Provider</li> |
| <li>Configuration center. |
| <ul> |
| <li>Store the global configuration of the Dubbo startup phase to ensure cross-environment sharing and global consistency of the configuration</li> |
| <li>Responsible for the storage and push of service governance rules (routing rules, dynamic configuration, etc.).</li> |
| </ul> |
| </li> |
| <li>Metadata Center. |
| <ul> |
| <li>Receive the service interface metadata reported by the Provider, and provide operation and maintenance capabilities for Admin and other consoles (such as service testing, interface documents, etc.)</li> |
| <li>As a supplement to the service discovery mechanism, it provides the synchronization capability of additional interface/method level configuration information, which is equivalent to the additional extension of the registration center</li> |
| </ul> |
| </li> |
| </ul> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/threecenters.png" alt="threecenters"></p> |
| <p>The above figure completely describes the interaction process between Dubbo microservice components and each center.</p> |
| <p>The above three centers are not a necessary condition for running Dubbo. Users can decide to enable only one or more of them according to their own business conditions to simplify deployment. Typically, all users will be registered with an independent |
| Start Dubbo service development, and the configuration center and metadata center will be gradually introduced on demand during the evolution of microservices.</p> |
| <h3 id="registry">Registry</h3> |
| <p>The registration center plays a very important role, and it carries the responsibilities of service registration and service discovery. Currently Dubbo supports service discovery and service registration at the following two granularities, namely interface level and application level, and the registration center can be deployed on demand:</p> |
| <ul> |
| <li> |
| <p>In the traditional Dubbo SDK usage posture, if you only provide RPC services in direct connection mode, you do not need to deploy a registration center.</p> |
| </li> |
| <li> |
| <p>Regardless of the interface level or the application level, if Dubbo SDK itself is required for service registration and service discovery, you can choose to deploy a registration center and integrate the corresponding registration center in Dubbo.</p> |
| </li> |
| <li> |
| <p>In the Dubbo + Mesh scenario, with the weakening of Dubbo service registration capabilities, the registration center in Dubbo is no longer a must, and its responsibilities are beginning to be replaced by the control plane. If the Dubbo + Mesh deployment method is adopted, whether it is The mesh method of ThinSDK or the mesh method of Proxyless no longer requires independent deployment of the registration center.</p> |
| </li> |
| </ul> |
| <p>The registration center does not depend on the configuration center and metadata center, as shown in the following figure:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/centers-registry.png" alt="centers-registry"></p> |
| <p>The configuration center and metadata center are not deployed in the figure. In Dubbo, the instance of the registration center will be used as the configuration center and metadata center at the same time by default. This is the default behavior of Dubbo. If you really do not need the capabilities of the configuration center or metadata center , which can be turned off in the configuration. There are two configurations in the configuration of the registration center, namely use-as-config-center and use-as-metadata-center. Just set the configuration to false.</p> |
| <h3 id="metadata-center">Metadata Center</h3> |
| <p>The metadata center is supported in version 2.7.x. As application-level service registration and service discovery are implemented in Dubbo, the metadata center becomes more and more important. The metadata center will need to be deployed in the following situations:</p> |
| <ol> |
| <li>For an application service originally built with the old version of Dubbo, when migrating to Dubbo 3, Dubbo 3 will need a metadata center to maintain the mapping relationship between RPC services and applications (that is, the mapping relationship between interfaces and applications), because if Application-level service discovery and service registration are adopted, and the data organization form of the &ldquo;application-instance list&rdquo; structure will be adopted in the registration center, which is no longer the data organization form of the previous &ldquo;interface-instance list&rdquo; structure. When the application services that use interface-level service registration and service discovery are migrated to the application level, the corresponding relationship between the interface and the application cannot be obtained, so that the instance list information cannot be obtained from the registration center. Therefore, in order to be compatible with this scenario, Dubbo is in When the Provider side starts, it will store the mapping relationship between the interface and the application in the metadata center.</li> |
| <li>In order to allow the registration center to focus more on address discovery and push capabilities and reduce the burden on the registration center, the metadata center carries all service metadata, a large number of interface/method level configuration information, etc., regardless of interface granularity or application granularity Service discovery and registration, and the metadata center all play an important role.</li> |
| </ol> |
| <p>If you have the above two requirements, you can choose to deploy the metadata center and integrate the metadata center through Dubbo configuration.</p> |
| <p>The metadata center does not depend on the registration center and configuration center, and users can freely choose whether to integrate and deploy the metadata center, as shown in the following figure:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/centers-metadata.png" alt="centers-metadata"></p> |
| <p>There is no configuration center in this figure, which means that the ability to manage configuration globally may not be required. There is no registration center in the figure, which means that the Dubbo mesh solution may be adopted, or service registration may not be required, and only receive service calls in direct connection mode.</p> |
| <h3 id="configuration-center">Configuration Center</h3> |
| <p>The configuration center is different from the other two centers. It has nothing to do with the interface level or the application level. It has no corresponding relationship with the interface. It is only related to the configuration data. Even if the registration center and metadata center are not deployed, the configuration center can be directly accessed. into the Dubbo application service. In the entire deployment architecture, instances in the entire cluster (whether they are Providers or Consumers) will share the configuration in the configuration center cluster, as shown in the following figure:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/centers-config.png" alt="centers-config"></p> |
| <p>There is no registration center in the figure, which means that the Dubbo mesh solution may be adopted, or service registration may not be required, and only receive service calls in direct connection mode.</p> |
| <p>There is no metadata center in this figure, which means that Consumer can obtain service metadata from the MetadataService exposed by Provider, so as to realize RPC call</p> |
| <h3 id="guarantee-the-high-availability-deployment-architecture-of-the-three-centers">Guarantee the high-availability deployment architecture of the three centers</h3> |
| <p>Although the three major centers are no longer necessary for Dubbo application services, in a real production environment, once the three major centers have been integrated and deployed, the three major centers will still face availability issues. Dubbo needs to support the three major centers High availability solution. Dubbo supports multiple registration centers, multiple data centers, and multiple configuration centers to meet the needs of deployment architecture models such as multi-active in the same city, three centers in two places, and multi-active in different places.</p> |
| <p>Dubbo SDK supports Multiple mode for all three centers.</p> |
| <ul> |
| <li> |
| <p>Multiple registries: Dubbo supports multiple registries, that is, an interface or an application can be registered in multiple registries, such as ZK clusters and Nacos clusters, and consumers can also subscribe from multiple registries Service address information for service discovery. By supporting multiple registration centers, it is ensured that one of the registration center clusters can be switched to another registration center cluster when it is unavailable, so that services can be provided normally and service calls can be initiated. This can also satisfy the registration center to adapt to various high-availability deployment architecture modes in deployment.</p> |
| </li> |
| <li> |
| <p>Multiple configuration centers: Dubbo supports multiple configuration centers to ensure that when a configuration center cluster becomes unavailable, it can switch to another configuration center cluster to ensure that the global configuration, routing rules, and other information can be obtained from the configuration center normally. This can also satisfy the configuration center to adapt to various high-availability deployment architecture modes in deployment.</p> |
| </li> |
| <li> |
| <p>Multiple data centers: Dubbo supports multiple data centers: it is used to deal with disaster recovery and other situations where a metadata center cluster is unavailable. At this time, you can switch to another metadata center cluster to ensure that the metadata center can normally provide relevant service elements. Data management capabilities.</p> |
| </li> |
| </ul> |
| <p>Taking the registration center as an example, the following is a schematic diagram of the deployment architecture of a multi-active scenario:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/multiple-registry-deployment-architecture.png" alt="multiple-registry-deployment-architecture"></p></description></item><item><title>Overview: Extensibility</title><link>https://dubbo.apache.org/en/overview/what/extensibility/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/overview/what/extensibility/</guid><description> |
| <h2 id="extended-design-ideas">Extended Design Ideas</h2> |
| <p>Scalability is what any system pursues, and it is equally applicable to Dubbo.</p> |
| <h3 id="what-is-scalability">What is scalability</h3> |
| <p>Scalability is a design concept that represents our vision for the future. We hope that based on the existing architecture or design, when some aspects change in the future, we can adapt to this with minimal changes. kind of change.</p> |
| <h3 id="advantages-of-scalability">Advantages of Scalability</h3> |
| <p>The advantage of scalability is mainly manifested in the decoupling between modules, which conforms to the principle of opening and closing, which is open to expansion and closed to modification. When a new function is added to the system, there is no need to modify the structure and code of the existing system, just add an extension.</p> |
| <h3 id="extended-implementation">Extended implementation</h3> |
| <p>Generally speaking, the system will use Factory, IoC, OSGI, etc. to manage the extension (plug-in) life cycle. Considering the applicability of Dubbo, I don&rsquo;t want to strongly rely on IoC containers such as Spring. |
| And building a small IoC container by myself feels a bit over-designed, so choose the simplest Factory way to manage extensions (plug-ins). In Dubbo, all internal and third-party implementations are equal.</p> |
| <h3 id="scalability-in-dubbo">Scalability in Dubbo</h3> |
| <ul> |
| <li>Treat third-party implementations equally. In Dubbo, all internal implementations and third-party implementations are equal, and users can replace the native implementations provided by Dubbo based on their own business needs.</li> |
| <li>Each extension point only encapsulates one change factor to maximize reuse. The implementers of each extension point often only care about one thing. If users need to expand, they only need to expand the extension points they care about, which greatly reduces the workload of users.</li> |
| </ul> |
| <h2 id="features-of-dubbo-extension">Features of Dubbo extension</h2> |
| <p>The extension capability in Dubbo is enhanced from the JDK standard SPI extension point discovery mechanism, which improves the following problems of the JDK standard SPI:</p> |
| <ul> |
| <li>The JDK standard SPI will instantiate all the implementations of the extension point at one time. If there is an extension implementation, it will take time to initialize, but if it is not used, it will be loaded, which will waste resources.</li> |
| <li>If the extension point fails to load, even the name of the extension point cannot be obtained. For example: JDK standard ScriptEngine, get the name of the script type through getName(), but if RubyScriptEngine fails to load the RubyScriptEngine class because the jruby. When the user executes the ruby script, it will report that ruby is not supported, not the real reason for the failure.</li> |
| </ul> |
| <p>Based on the expansion capabilities provided by Dubbo, users can easily expand other protocols, filters, routes, etc. based on their own needs. The following introduces the characteristics of Dubbo&rsquo;s extension capabilities.</p> |
| <ul> |
| <li>Load on demand. Dubbo&rsquo;s extension capability does not instantiate all implementations at once, but instantiates which extension class is used to reduce resource waste.</li> |
| <li>Increase the IOC capability of the extended class. Dubbo&rsquo;s extension capability is not just to discover the extension service implementation class, but to go further on this basis. If the attributes of the extension class depend on other objects, Dubbo will automatically complete the injection function of the dependent object.</li> |
| <li>Increase the AOP capability of extended classes. Dubbo&rsquo;s extension capability will automatically discover the wrapper class of the extension class, complete the construction of the wrapper class, and enhance the function of the extension class.</li> |
| <li>Possess the ability to dynamically select the extension implementation. The Dubbo extension will dynamically select the corresponding extension class at runtime based on parameters, which improves Dubbo&rsquo;s scalability.</li> |
| <li>The extension implementation can be sorted. The execution order of the extension implementation can be specified based on user requirements.</li> |
| <li>Provides the Adaptive capability of the extension point. This capability enables some extension classes to take effect on the consumer side, and some extension classes to take effect on the provider side.</li> |
| </ul> |
| <p>From the design goal of Dubbo extension, it can be seen that some features implemented by Dubbo, such as dynamic selection of extension implementation, IOC, AOP, etc., can provide users with very flexible expansion capabilities.</p> |
| <h2 id="dubbo-extension-loading-process">Dubbo extension loading process</h2> |
| <p>The whole process of Dubbo loading extension is as follows:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/extension-load.png" alt="//imgs/v3/concepts/extension-load.png"></p> |
| <p>There are 4 main steps:</p> |
| <ul> |
| <li>Read and parse configuration files</li> |
| <li>Cache all extension implementations</li> |
| <li>Based on the extension name executed by the user, instantiate the corresponding extension implementation</li> |
| <li>Perform IOC injection of extended instance attributes and instantiate extended wrapper classes to realize AOP features</li> |
| </ul> |
| <h2 id="how-to-use-dubbos-extension-capability-to-expand">How to use Dubbo&rsquo;s extension capability to expand</h2> |
| <p>The following takes the extension protocol as an example to illustrate how to use the extension capabilities provided by Dubbo to extend the Triple protocol.</p> |
| <p>(1) Place a text file in the protocol implementation jar package: META-INF/dubbo/org.apache.dubbo.remoting.api.WireProtocol</p> |
| <div class="highlight"><pre tabindex="0" style="color:#93a1a1;background-color:#002b36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>tri=org.apache.dubbo.rpc.protocol.tri.TripleHttp2Protocol |
| </span></span></code></pre></div><p>(2) Implementation class content</p> |
| <div class="highlight"><pre tabindex="0" style="color:#93a1a1;background-color:#002b36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-java" data-lang="java"><span style="display:flex;"><span><span style="color:#268bd2">@Activate</span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">class</span> <span style="color:#268bd2">TripleHttp2Protocol</span> <span style="color:#268bd2">extends</span> Http2WireProtocol { |
| </span></span><span style="display:flex;"><span> <span style="color:#586e75">//...</span> |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Instructions: Http2WireProtocol implements the WireProtocol interface</p> |
| <p>(3) In the Dubbo configuration module, each extension point has a corresponding configuration attribute or label, and the configuration specifies which extension to use. for example:</p> |
| <div class="highlight"><pre tabindex="0" style="color:#93a1a1;background-color:#002b36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>&lt;dubbo:protocol name=&#34;tri&#34; /&gt; |
| </span></span></code></pre></div><p>As can be seen from the above expansion steps, the user basically completes the expansion under the black box.</p> |
| <h2 id="dubbo-extended-application">Dubbo extended application</h2> |
| <p>Dubbo&rsquo;s expansion capability is very flexible, and it is ubiquitous in the realization of its own functions.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/extension-use.png" alt="//imgs/v3/concepts/extension-use.png"></p> |
| <p>Dubbo&rsquo;s extensibility makes it easy to divide the Dubbo project into sub-modules one by one to realize the hot-swappable feature. Users can completely replace Dubbo&rsquo;s native implementation based on their own needs to meet their own business needs.</p> |
| <h2 id="scenes-to-be-used">scenes to be used</h2> |
| <ul> |
| <li>If you need to customize the load balancing strategy, you can use Dubbo&rsquo;s scalability.</li> |
| <li>If you need to implement a custom registry, you can use Dubbo&rsquo;s extension capabilities.</li> |
| <li>If you need to implement custom filters, you can use Dubbo&rsquo;s extension capabilities.</li> |
| </ul> |
| <p>Dubbo extensions treat internal implementations and third-party implementations equally. For more usage scenarios, see <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/reference-manual/spi/description/">SPI extension implementation</a></p></description></item><item><title>Overview: Ecosystem</title><link>https://dubbo.apache.org/en/overview/what/ecosystem/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/overview/what/ecosystem/</guid><description> |
| <h3 id="dashboard">Dashboard</h3> |
| <ul> |
| <li><a href="https://github.com/apache/dubbo-admin">Dubbo-admin</a></li> |
| </ul> |
| <h3 id="supported-components-and-deployment-architectures">Supported Components and Deployment Architectures</h3> |
| <p>Dubbo implementations generally support the following products or deployment architectures, and specific multilingual SDK implementations may vary.</p> |
| <ul> |
| <li>Registry |
| <ul> |
| <li>Zookeeper</li> |
| <li><a href="https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html">Nacos</a></li> |
| <li>Kubernetes</li> |
| </ul> |
| </li> |
| <li>Metadata center |
| <ul> |
| <li>Zookeeper</li> |
| <li><a href="https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html">Nacos</a></li> |
| <li>Redis</li> |
| </ul> |
| </li> |
| <li>Configuration center |
| <ul> |
| <li>Zookeeper</li> |
| <li><a href="https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html">Nacos</a></li> |
| <li>Redis</li> |
| <li>Apollo</li> |
| </ul> |
| </li> |
| <li>Mesh |
| <ul> |
| <li>Data plane Envoy</li> |
| <li>Control plane Istio</li> |
| </ul> |
| </li> |
| </ul> |
| <h3 id="protocols-and-interoperability">Protocols and Interoperability</h3> |
| <ul> |
| <li>Interoperability with the gRPC system can be realized based on the Triple protocol</li> |
| <li>Based on the REST protocol and application-level service discovery, the interoperability of the Spring Cloud system at the protocol and address discovery levels can be realized</li> |
| </ul> |
| <h3 id="spi-integration">SPI Integration</h3> |
| <p>There are many Dubbo extension implementations here, including protocols, serialization, registration centers, etc.</p> |
| <ul> |
| <li>[dubbo-spi-extensions]</li> |
| </ul> |
| <h3 id="gateway-component">Gateway component</h3> |
| <ul> |
| <li>[Apache Shenyu]</li> |
| <li>[Apache APISIX]</li> |
| <li>[Apache Dubbo-pixiu]</li> |
| <li>[Tengine]</li> |
| </ul> |
| <h3 id="link-tracking">Link Tracking</h3> |
| <ul> |
| <li>[Zipkin]</li> |
| <li>[Apache Skywalking]</li> |
| </ul> |
| <h3 id="other-microservice-components">Other microservice components</h3> |
| <ul> |
| <li>Current Limiting [Sentinel]</li> |
| <li>Affairs [Seata]</li> |
| </ul> |
| <h3 id="multilingual-implementation">Multilingual implementation</h3> |
| <ul> |
| <li>Golang</li> |
| <li>Java</li> |
| <li>Rust</li> |
| <li>Node</li> |
| <li>Python</li> |
| <li>PHP</li> |
| </ul></description></item></channel></rss> |
