| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Apache Dubbo – Concepts and Architecture</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/</link><description>Recent content in Concepts and Architecture on Apache Dubbo</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Docs3-V2: Overall Architecture</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/overall-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/overall-architecture/</guid><description> |
| <p><img src="https://dubbo.apache.org/imgs/user/dubbo-architecture.jpg" alt="dubbo-architecture"></p> |
| <h5 id="node-role-description">Node role description</h5> |
| <table> |
| <thead> |
| <tr> |
| <th>Node</th> |
| <th>Role Description</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><code>Provider</code></td> |
| <td>The service provider of the exposed service</td> |
| </tr> |
| <tr> |
| <td><code>Consumer</code></td> |
| <td>The service consumer who invokes the remote service</td> |
| </tr> |
| <tr> |
| <td><code>Registry</code></td> |
| <td>Registry for service registration and discovery</td> |
| </tr> |
| <tr> |
| <td><code>Monitor</code></td> |
| <td>A monitoring center that counts service calls and call times</td> |
| </tr> |
| <tr> |
| <td><code>Container</code></td> |
| <td>service running container</td> |
| </tr> |
| </tbody> |
| </table> |
| <h5 id="description-of-calling-relationship">Description of calling relationship</h5> |
| <ol start="0"> |
| <li>The service container is responsible for starting, loading, and running the service provider.</li> |
| <li>When the service provider starts, it registers the services it provides with the registration center.</li> |
| <li>When a service consumer starts, it subscribes to the registration center for the services it needs.</li> |
| <li>The registration center returns the service provider address list to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.</li> |
| <li>The service consumer, from the provider address list, selects a provider to call based on the soft load balancing algorithm, and if the call fails, select another provider to call.</li> |
| <li>Service consumers and providers accumulate the number of invocations and invocation time in memory, and regularly send statistical data to the monitoring center every minute.</li> |
| </ol> |
| <p>The Dubbo architecture has the following characteristics, namely connectivity, robustness, scalability, and upgradeability to future architectures.</p> |
| <h2 id="connectivity">Connectivity</h2> |
| <ul> |
| <li>The registration center is responsible for the registration and search of service addresses, which is equivalent to directory services. Service providers and consumers only interact with the registration center at startup. The registration center does not forward requests, and the pressure is less</li> |
| <li>The monitoring center is responsible for counting the number of service calls, call time, etc., and the statistics are first summarized in the memory and sent to the monitoring center server every minute, and displayed in reports</li> |
| <li>The service provider registers the services it provides with the registration center, and reports the call time to the monitoring center, which does not include network overhead</li> |
| <li>The service consumer obtains the address list of the service provider from the registration center, and directly calls the provider according to the load algorithm, and reports the calling time to the monitoring center, which includes network overhead</li> |
| <li>The registration center, service provider, and service consumer are all long connections, except for the monitoring center</li> |
| <li>The registration center perceives the existence of the service provider through a long connection, and if the service provider goes down, the registration center will immediately push the event to notify the consumer</li> |
| <li>The registration center and monitoring center are all down, and the running providers and consumers are not affected. Consumers cache the list of providers locally</li> |
| <li>Both registration center and monitoring center are optional, and service consumers can directly connect to service providers</li> |
| </ul> |
| <h2 id="robustness">Robustness</h2> |
| <ul> |
| <li>The downtime of the monitoring center does not affect the use, but part of the sampling data is lost</li> |
| <li>After the database is down, the registration center can still provide service list query through the cache, but cannot register new services</li> |
| <li>Registration center peer-to-peer cluster, when any one goes down, it will automatically switch to another</li> |
| <li>After the registration center is completely down, the service provider and the service consumer can still communicate through the local cache</li> |
| <li>The service provider is stateless, and if any one goes down, it will not affect the use</li> |
| <li>After the service provider is all down, the service consumer application will be unavailable and will reconnect infinitely waiting for the service provider to recover</li> |
| </ul> |
| <h2 id="scalability">Scalability</h2> |
| <ul> |
| <li>The registration center is a peer-to-peer cluster, which can dynamically increase machine deployment instances, and all clients will automatically discover the new registration center</li> |
| <li>The service provider is stateless and can dynamically increase machine deployment instances, and the registration center will push new service provider information to consumers</li> |
| </ul> |
| <h2 id="upgradability">Upgradability</h2> |
| <p>When the scale of service clusters is further expanded and the IT governance structure is further upgraded, it is necessary to realize dynamic deployment and perform flow computing, and the existing distributed service architecture will not bring resistance. The following figure is a possible architecture in the future:</p> |
| <p><img src="https://dubbo.apache.org/imgs/user/dubbo-architecture-future.jpg" alt="dubbo-architecture-futures"></p> |
| <h5 id="node-role-description-1">Node role description</h5> |
| <table> |
| <thead> |
| <tr> |
| <th>Node</th> |
| <th>Role Description</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><code>Deployer</code></td> |
| <td>A local proxy for auto-deployment services</td> |
| </tr> |
| <tr> |
| <td><code>Repository</code></td> |
| <td>The warehouse is used to store the service application release package</td> |
| </tr> |
| <tr> |
| <td><code>Scheduler</code></td> |
| <td>The scheduling center automatically increases or decreases service providers based on access pressure</td> |
| </tr> |
| <tr> |
| <td><code>Admin</code></td> |
| <td>Unified Admin Console</td> |
| </tr> |
| <tr> |
| <td><code>Registry</code></td> |
| <td>Registry for service registration and discovery</td> |
| </tr> |
| <tr> |
| <td><code>Monitor</code></td> |
| <td>A monitoring center that counts service calls and call times</td> |
| </tr> |
| </tbody> |
| </table></description></item><item><title>Docs3-V2: Code Architecture</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/code-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/code-architecture/</guid><description> |
| <h2 id="overall-design">overall design</h2> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-framework.jpg" alt="/dev-guide/images/dubbo-framework.jpg"></p> |
| <p>illustration:</p> |
| <ul> |
| <li>The light blue background on the left in the figure is the interface used by the service consumer, the light green background on the right is the interface used by the service provider, and the interface on the central axis is the interface used by both parties.</li> |
| <li>The figure is divided into ten layers from bottom to top. Each layer is one-way dependent. The black arrow on the right represents the dependency relationship between layers. Each layer can be reused by stripping the upper layer. Among them, the Service and Config layers are API , the other layers are SPI.</li> |
| <li>The small green block in the figure is the extension interface, and the small blue block is the implementation class. Only the implementation class used to associate each layer is shown in the figure.</li> |
| <li>The blue dotted line in the figure is the initialization process, that is, the assembly chain at startup, the red solid line is the method call process, that is, the runtime call chain, and the purple triangle arrow is inheritance. You can regard the subclass as the same node of the parent class, and the line The text above is the method to call.</li> |
| </ul> |
| <h2 id="description-of-each-layer">Description of each layer</h2> |
| <ul> |
| <li><strong>Config configuration layer</strong>: external configuration interface, centered on <code>ServiceConfig</code>, <code>ReferenceConfig</code>, can directly initialize configuration classes, or generate configuration classes through spring parsing configuration</li> |
| <li><strong>Proxy service proxy layer</strong>: service interface transparent proxy, generating service client Stub and server Skeleton, with <code>ServiceProxy</code> as the center, the extended interface is <code>ProxyFactory</code></li> |
| <li><strong>Registry registration center layer</strong>: Encapsulates the registration and discovery of service addresses, centered on service URLs, and the extended interfaces are <code>RegistryFactory</code>, <code>Registry</code>, <code>RegistryService</code></li> |
| <li><strong>Cluster routing layer</strong>: Encapsulate the routing and load balancing of multiple providers, and bridge the registration center, with <code>Invoker</code> as the center, and the extended interfaces are <code>Cluster</code>, <code>Directory</code>, <code>Router</code>, <code>LoadBalance</code></li> |
| <li><strong>Monitor monitoring layer</strong>: RPC call times and call time monitoring, centered on <code>Statistics</code>, extended interfaces are <code>MonitorFactory</code>, <code>Monitor</code>, <code>MonitorService</code></li> |
| <li><strong>Protocol remote call layer</strong>: Encapsulates RPC calls, centered on <code>Invocation</code>, <code>Result</code>, extended interfaces are <code>Protocol</code>, <code>Invoker</code>, <code>Exporter</code></li> |
| <li><strong>Exchange information exchange layer</strong>: encapsulation request response mode, synchronous to asynchronous, centered on <code>Request</code>, <code>Response</code>, extended interfaces are <code>Exchanger</code>, <code>ExchangeChannel</code>, <code>ExchangeClient</code>, <code>ExchangeServer</code></li> |
| <li><strong>Transport network transport layer</strong>: Abstract mina and netty as a unified interface, with <code>Message</code> as the center, and extended interfaces as <code>Channel</code>, <code>Transporter</code>, <code>Client</code>, <code>Server</code>, <code>Codec</code></li> |
| <li><strong>Serialize data serialization layer</strong>: some reusable tools, the extended interfaces are <code>Serialization</code>, <code>ObjectInput</code>, <code>ObjectOutput</code>, <code>ThreadPool</code></li> |
| </ul> |
| <h2 id="relationship-description">Relationship description</h2> |
| <ul> |
| <li>In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter, non-transparent RPC calls can be completed, and then Filter interception points on the main process of Invoker.</li> |
| <li>The Consumer and Provider in the picture are abstract concepts, just to let the viewer understand more intuitively which classes belong to the client and server. The reason for not using Client and Server is that Dubbo uses Provider, Consumer, Registry in many scenarios , Monitor divides logical topology nodes and maintains a unified concept.</li> |
| <li>Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple Invokers as one Invoker, so that other people only need to pay attention to the Protocol layer Invoker. Adding Cluster or removing Cluster will not affect other layers, because there is only one Provider, Cluster is not required.</li> |
| <li>The Proxy layer encapsulates the transparent proxy of all interfaces, and the Invoker is the center in other layers. Only when it is exposed to the user, the Proxy is used to convert the Invoker into an interface, or convert the interface implementation into an Invoker, that is, remove Proxy layer RPC can be run, but it is not so transparent, and it does not look like calling remote services like calling local services.</li> |
| <li>The Remoting implementation is the implementation of the Dubbo protocol. If you choose the RMI protocol, the entire Remoting will not be used. The Remoting is divided into the Transport transport layer and the Exchange information exchange layer. The Transport layer is only responsible for one-way message transmission. , Netty, Grizzly&rsquo;s abstraction, it can also extend UDP transmission, and the Exchange layer encapsulates the Request-Response semantics above the transport layer.</li> |
| <li>Registry and Monitor are actually not considered a layer, but an independent node, just for a global overview, drawn together in layers.</li> |
| </ul> |
| <h2 id="module-subpackage">Module Subpackage</h2> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-modules.jpg" alt="/dev-guide/images/dubbo-modules.jpg"></p> |
| <p>Module description:</p> |
| <ul> |
| <li><strong>dubbo-common public logic module</strong>: including Util class and common model.</li> |
| <li><strong>dubbo-remoting remote communication module</strong>: equivalent to the implementation of the Dubbo protocol, if the RPC uses the RMI protocol, this package does not need to be used.</li> |
| <li><strong>dubbo-rpc remote call module</strong>: abstracts various protocols and dynamic proxy, only includes one-to-one calls, and does not care about cluster management.</li> |
| <li><strong>dubbo-cluster cluster module</strong>: Disguise multiple service providers as one provider, including: load balancing, fault tolerance, routing, etc. The address list of the cluster can be statically configured, or it can be configured by the registration center send.</li> |
| <li><strong>dubbo-registry registration center module</strong>: based on the clustering method issued by the registration center, and the abstraction of various registration centers.</li> |
| <li><strong>dubbo-monitor monitoring module</strong>: Statistics of service call times, call time, and call chain tracking services.</li> |
| <li><strong>dubbo-config configuration module</strong>: Dubbo’s external API, users use Dubbo through Config, hiding all details of Dubbo.</li> |
| <li><strong>dubbo-container container module</strong>: It is a Standlone container, loaded with a simple Main to start Spring, because services usually do not require the features of web containers such as Tomcat/JBoss, there is no need to use web containers to load services.</li> |
| </ul> |
| <p>On the whole, subcontracting is carried out according to the hierarchical structure. The difference from the layering is:</p> |
| <ul> |
| <li>Container is a service container, which is used to deploy and run services, and is not drawn in the layer.</li> |
| <li>Both the Protocol layer and the Proxy layer are placed in the rpc module. These two layers are the core of rpc. When there is no need for a cluster, that is, there is only one provider, you can use only these two layers to complete the rpc call.</li> |
| <li>Both the Transport layer and the Exchange layer are placed in the remoting module, which is the communication basis for rpc calls.</li> |
| <li>The Serialize layer is placed in the common module for greater reuse.</li> |
| </ul> |
| <h2 id="dependencies">Dependencies</h2> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-relation.jpg" alt="/dev-guide/images/dubbo-relation.jpg"></p> |
| <p>illustration:</p> |
| <ul> |
| <li>The small squares in the figure Protocol, Cluster, Proxy, Service, Container, Registry, Monitor represent layers or modules, the blue ones indicate that they interact with the business, and the green ones only interact with Dubbo internally.</li> |
| <li>The background squares Consumer, Provider, Registry, Monitor in the figure represent the deployment logic topology nodes.</li> |
| <li>The blue dotted line in the figure is the call at initialization, the red dotted line is the asynchronous call at runtime, and the red solid line is the synchronous call at runtime.</li> |
| <li>Only the RPC layer is included in the figure, and the Remoting layer is not included. Remoting is implicitly included in the Protocol as a whole.</li> |
| </ul> |
| <h2 id="call-chain">call chain</h2> |
| <p>Expand the red call chain of the general design diagram, as follows:</p> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-extension.jpg" alt="/dev-guide/images/dubbo-extension.jpg"></p> |
| <h2 id="expose-service-timing">Expose service timing</h2> |
| <p>Expand the blue initialization chain of the exposed service of the service provider on the right side of the general design diagram, and the sequence diagram is as follows:</p> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-export.jpg" alt="/dev-guide/images/dubbo-export.jpg"></p> |
| <h2 id="reference-service-timing">Reference service timing</h2> |
| <p>Expand the green initialization chain of the service consumer reference service on the left side of the general design diagram, and the sequence diagram is as follows:</p> |
| <p><img src="https://dubbo.apache.org/imgs/dev/dubbo-refer.jpg" alt="/dev-guide/images/dubbo-refer.jpg"></p> |
| <h2 id="domain-model">Domain Model</h2> |
| <p>In Dubbo&rsquo;s core domain model:</p> |
| <ul> |
| <li>Protocol is the service domain, which is the main function entry exposed and referenced by Invoker, and it is responsible for the life cycle management of Invoker.</li> |
| <li>Invoker is an entity domain, it is the core model of Dubbo, other models are close to it, or converted to it, it represents an executable body, can initiate an invoke call to it, it may be a local implementation, or it may be Is a remote implementation, and possibly a cluster implementation.</li> |
| <li>Invocation is a session domain, which holds variables in the calling process, such as method names, parameters, etc.</li> |
| </ul> |
| <h2 id="basic-design-principles">Basic Design Principles</h2> |
| <ul> |
| <li>Adopt Microkernel + Plugin mode, Microkernel is only responsible for assembling Plugin, and Dubbo&rsquo;s own functions are also realized through extension points, that is, all function points of Dubbo can be replaced by user-defined extensions.</li> |
| <li>URL is used as the unified format of configuration information, and all extension points carry configuration information by passing URL.</li> |
| </ul></description></item><item><title>Docs3-V2: Service Discovery</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/</guid><description> |
| <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> |
| <h3 id="method-to-realize">Method to realize</h3> |
| <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 commonly used Nacos, Consul, Zookeeper, etc. Dubbo itself also provides the connection to various registry components, and users can choose flexibly.</p> |
| <h3 id="working-principle">working principle</h3> |
| <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="//imgs/architecture.png"></p> |
| <p>A core component of service discovery is the registry, Provider registers addresses to the registry, and Consumer reads and subscribes to the Provider address list from the registry. |
| Therefore, to enable service discovery, you need to add registry configuration to Dubbo:</p> |
| <p>Take dubbo-spring-boot-starter as an example, add registry configuration</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-properties" data-lang="properties"><span style="display:flex;"><span><span style="color:#586e75"># application.properties</span> |
| </span></span><span style="display:flex;"><span>dubbo |
| </span></span><span style="display:flex;"><span> registry |
| </span></span><span style="display:flex;"><span> address<span style="color:#719e07">:</span> <span style="color:#2aa198">zookeeper://127.0.0.1:2181</span> |
| </span></span></code></pre></div><h3 id="introduction-to-application-level-service-discovery">Introduction to application-level service discovery</h3> |
| <p>In summary, the application-level service discovery introduced by Dubbo3 mainly has the following advantages</p> |
| <ul> |
| <li>Adapt to cloud-native microservice changes. The infrastructure capabilities in the cloud-native era are continuously released upwards. Platforms such as Kubernetes integrate the conceptual abstraction of microservices. Dubbo3&rsquo;s application-level service discovery is a general model for adapting various microservice systems.</li> |
| <li>Improved performance and scalability. The service governance that supports ultra-large-scale clusters has always been Dubbo&rsquo;s advantage. By introducing an application-level service discovery model, it essentially solves the storage and push pressure of the registry address data, and the corresponding address calculation pressure on the consumer side also drops by an order of magnitude. ; The cluster size has also become predictable and assessable (it has nothing to do with the number of RPC interfaces, but only with the instance deployment scale).</li> |
| </ul> |
| <p>The following figure shows the service discovery model of Dubbo2: Provider registers the service address, Consumer coordinates with the registration center and discovers the service address, and then initiates communication with the address. This is the classic service discovery process used by most microservice frameworks. The special feature of Dubbo2 is that it also integrates the information of &ldquo;RPC interface&rdquo; into the address discovery process, and this part of information is often closely related to specific business definitions.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/servicediscovery_old.png" alt="//imgs/v3/concepts/servicediscovery_old.png"></p> |
| <p>After accessing the cloud-native infrastructure, the infrastructure incorporates the abstraction of the concept of microservices, and the process of orchestrating and scheduling containerized microservices completes the registration at the infrastructure level. As shown in the figure below, the infrastructure not only assumes the responsibility of the registration center, but also completes the service registration action, and the information of the &ldquo;RPC interface&rdquo;, because it is related to specific businesses, is impossible and unsuitable to be hosted by the infrastructure.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/servicediscovery_k8s.png" alt="//imgs/v3/concepts/servicediscovery_k8s.png"></p> |
| <p>In such a scenario, there are two requirements for Dubbo3&rsquo;s service registration discovery mechanism: |
| Dubbo3 needs to abstract a common address mapping model that has nothing to do with business logic in the original service discovery process, and ensure that this part of the model is reasonable enough to support entrusting the registration behavior and storage of addresses to the underlying infrastructure |
| Dubbo3&rsquo;s unique business interface synchronization mechanism is an advantage that Dubbo3 needs to retain. It needs to be resolved through its own mechanism within the framework on top of the new address model defined in Dubbo3.</p> |
| <p>The new service discovery model designed in this way brings greater advantages to Dubbo3 in terms of architecture compatibility and scalability.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/servicediscovery_mem.png" alt="//imgs/v3/concepts/servicediscovery_mem.png"></p> |
| <p>In terms of architectural compatibility, as mentioned above, it is possible for Dubbo3 to reuse the service abstraction capabilities of the underlying infrastructure; on the other hand, other microservice solutions in the industry such as Spring Cloud also follow this model. |
| After opening the address discovery, it becomes possible for users to explore using Dubbo to connect heterogeneous microservice systems.</p> |
| <p>The Dubbo3 service discovery model is more suitable for building a scalable service system. How to understand this? |
| Here is a simple example to intuitively compare the data flow changes in the address discovery process between Dubbo2 and Dubbo3: Suppose a microservice application defines 100 interfaces (services in Dubbo), |
| You need to register 100 services in the registry. If this application is deployed on 100 machines, then these 100 services will generate a total of 100 * 100 = 10000 virtual nodes; and the same application, |
| For Dubbo3, the new registration discovery model only needs 1 service (only related to the application and has nothing to do with the interface), and only registers 1 * 100 = 100 virtual nodes equal to the number of machine instances to the registration center. |
| In this simple example, the number of addresses registered by Dubbo has dropped to 1/100 of the original, which greatly relieves the storage pressure on the registration center and subscribers. more importantly, |
| The address discovery capacity is completely decoupled from the business RPC definition, and the capacity evaluation of the entire cluster will become more transparent for operation and maintenance: as many machines are deployed as there are loads, it will not be like Dubbo2. |
| Because business RPC reconstruction will affect the stability of the entire cluster service discovery.</p></description></item><item><title>Docs3-V2: Service Call Extension Point</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/service-invocation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/service-invocation/</guid><description> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/invoke-arch.jpg" alt="dubbo-architecture"></p> |
| <p>As shown in the figure above, from the perspective of service invocation, Dubbo provides a wealth of extension points in the link, covering load balancing methods, interceptors before and after site selection, and server-side processing interceptors. |
| To put it simply, when Dubbo initiates a remote call, the main workflow can be divided into two parts: the consumer side and the server side.</p> |
| <p>The workflow on the consumer side is as follows:</p> |
| <ul> |
| <li>Receive requests from users through Stub and encapsulate them in <code>Invocation</code> object</li> |
| <li>Pass the <code>Invocation</code> object to <code>ClusterFilter</code> (<strong>extension point</strong>) for request preprocessing before site selection, such as conversion of request parameters, request logging, current limiting and other operations are carried out at this stage</li> |
| <li>Pass the <code>Invocation</code> object to <code>Cluster</code> (<strong>extension point</strong>) for decision-making of cluster invocation logic, such as fast failure mode, safe failure mode and other decisions are made at this stage |
| <ul> |
| <li><code>Cluster</code> calls <code>Directory</code> to get all available server address information</li> |
| <li><code>Directory</code> calls <code>StateRouter</code> (<strong>extension point</strong>, recommended) and <code>Router</code> (<strong>extension point</strong>) to filter the address information of the server. This stage is mainly from the full amount of address information Filter out the targets that are allowed to be called in this call, such as marking-based traffic routing is carried out at this stage</li> |
| <li>After <code>Cluster</code> obtains the available server information provided by <code>Directory</code>, it will call <code>LoadBalance</code> (<strong>extension point</strong>) to select a target for this call from multiple addresses, such as random call, polling Strategies such as calling and consistent hashing are carried out at this stage</li> |
| <li><code>Cluster</code> obtains the <code>Invoker</code> of the target, and then passes <code>Invocation</code> to the corresponding <code>Invoker</code>, and waits for the result to be returned, and executes the corresponding decision if an error occurs (such as fast failure, safety failure, etc.)</li> |
| </ul> |
| </li> |
| <li>After the above processing, the <code>Invoker</code> with the target address information is obtained, and <code>Filter</code> (<strong>extension point</strong>) will be called to process the request after the address selection (due to the <code>Filter</code> created on the consumer side The magnitude is the same as that of the server address. If there is no special need, it is recommended to use <code>ClusterFilter</code> for extended interception to improve performance)</li> |
| <li>Finally <code>Invocation</code> will be sent to the server over the network</li> |
| </ul> |
| <p>The workflow of the server is as follows:</p> |
| <ul> |
| <li>After the server communication layer receives the request, it will pass the request to the protocol layer to construct <code>Invocation</code></li> |
| <li>Pass the <code>Invocation</code> object to <code>Filter</code> (<strong>extension point</strong>) to pre-process the server request, such as server authentication, logging, current limiting and other operations are performed at this stage</li> |
| <li>Pass the <code>Invocation</code> object to the dynamic proxy to make the real server call</li> |
| </ul> |
| <h2 id="filter-interceptor">Filter (interceptor)</h2> |
| <p>The interceptor can implement the interception of the call process of the service provider and the service consumer. Most of Dubbo&rsquo;s own functions are implemented based on this extension point. Every time the remote method is executed, the interception will be executed. Please pay attention to the impact on performance. |
| Among them, on the consumer side, <code>ClusterFilter</code> is used for interception before location selection and <code>Filter</code> is used for interception after location selection. If there is no special need, use <code>ClusterFilter</code> for extended interception to improve performance.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/concepts/filter-arch.jpg" alt="filter-architecture"></p> |
| <p>In Dubbo 3, the interface signatures of <code>Filter</code> and <code>ClusterFilter</code> are unified and abstracted into <code>BaseFilter</code>, and developers can implement the interfaces of <code>Filter</code> or <code>ClusterFilter</code> respectively to implement their own interceptors. |
| If you need to intercept the return status, you can directly implement the <code>BaseFilter.Listener</code> interface, and Dubbo will automatically recognize and call it.</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:#719e07">package</span> org.apache.dubbo.rpc; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">BaseFilter</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> Result <span style="color:#268bd2">invoke</span>(Invoker<span style="color:#719e07">&lt;?&gt;</span> invoker, Invocation invocation) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">Listener</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">onResponse</span>(Result appResponse, Invoker<span style="color:#719e07">&lt;?&gt;</span> invoker, Invocation invocation); |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">onError</span>(Throwable t, Invoker<span style="color:#719e07">&lt;?&gt;</span> invoker, Invocation invocation); |
| </span></span><span style="display:flex;"><span> } |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><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:#719e07">package</span> org.apache.dubbo.rpc; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">@SPI</span>(scope <span style="color:#719e07">=</span> ExtensionScope. MODULE) |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">Filter</span> <span style="color:#268bd2">extends</span> BaseFilter { |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><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:#719e07">package</span> org.apache.dubbo.rpc.cluster.filter; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">@SPI</span>(scope <span style="color:#719e07">=</span> ExtensionScope. MODULE) |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">ClusterFilter</span> <span style="color:#268bd2">extends</span> BaseFilter { |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>In particular, if <code>Filter</code> or <code>ClusterFilter</code> needs to be effective on the Consumer side, the <code>@Activate</code> annotation needs to be added, and the value of <code>group</code> needs to be <code>consumer</code>.</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>(group <span style="color:#719e07">=</span> CommonConstants. CONSUMER) |
| </span></span></code></pre></div><p>If <code>Filter</code> or <code>ClusterFilter</code> needs to be effective on the Provider side, the <code>@Activate</code> annotation needs to be added, and the value of <code>group</code> needs to be <code>provider</code>.</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>(group <span style="color:#719e07">=</span> CommonConstants. PROVIDER) |
| </span></span></code></pre></div><p>Please refer to <a href="../../reference-manual/spi/description/filter/">Reference</a> for specific call interception extension methods</p> |
| <h2 id="router-routing-address-selection">Router (routing address selection)</h2> |
| <p>Routing address selection provides the ability to select a batch of target providers that meet the conditions from multiple service providers to call. |
| Dubbo&rsquo;s routing mainly needs to implement 3 interfaces, which are the <code>route</code> method responsible for each call screening, the <code>notify</code> method responsible for caching after the address is pushed, and the <code>stop</code> method for destroying the route. |
| It is recommended to implement the <code>StateRouter</code> interface in Dubbo 3, which can provide high-performance routing address selection.</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:#719e07">package</span> org.apache.dubbo.rpc.cluster.router.state; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">StateRouter</span><span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> BitList<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> <span style="color:#268bd2">route</span>(BitList<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers, URL url, Invocation invocation, |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">boolean</span> needToPrintMessage, Holder<span style="color:#719e07">&lt;</span>RouterSnapshotNode<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> nodeHolder) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">notify</span>(BitList<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers); |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">stop</span>(); |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><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:#719e07">package</span> org.apache.dubbo.rpc.cluster; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">Router</span> <span style="color:#268bd2">extends</span> Comparable<span style="color:#719e07">&lt;</span>Router<span style="color:#719e07">&gt;</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#268bd2">@Deprecated</span> |
| </span></span><span style="display:flex;"><span> List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> <span style="color:#268bd2">route</span>(List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers, URL url, Invocation invocation) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> RouterResult<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> <span style="color:#268bd2">route</span>(List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers, URL url, Invocation invocation, |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">boolean</span> needToPrintMessage) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">notify</span>(List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers); |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">void</span> <span style="color:#268bd2">stop</span>(); |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Please refer to <a href="../../reference-manual/spi/description/router/">Reference</a> for specific routing address selection expansion methods</p> |
| <h2 id="cluster-cluster-rules">Cluster (cluster rules)</h2> |
| <p>Cluster rules provide capabilities such as result aggregation and fault tolerance when there are multiple service providers.</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:#719e07">package</span> org.apache.dubbo.rpc.cluster.support; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">abstract</span> <span style="color:#268bd2">class</span> <span style="color:#268bd2">AbstractClusterInvoker</span><span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> <span style="color:#268bd2">implements</span> ClusterInvoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#268bd2">protected</span> <span style="color:#268bd2">abstract</span> Result <span style="color:#268bd2">doInvoke</span>(Invocation invocation, List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers, |
| </span></span><span style="display:flex;"><span> LoadBalance loadbalance) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Please refer to <a href="../../reference-manual/spi/description/cluster/">Reference</a> for specific cluster rule extension methods</p> |
| <h2 id="loadbalance">LoadBalance</h2> |
| <p>Load balancing provides the ability to select <strong>one</strong> target provider to call from multiple service providers.</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:#719e07">package</span> org.apache.dubbo.rpc.cluster; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">public</span> <span style="color:#268bd2">interface</span> <span style="color:#268bd2">LoadBalance</span> { |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span> <span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;</span> <span style="color:#268bd2">select</span>(List<span style="color:#719e07">&lt;</span>Invoker<span style="color:#719e07">&lt;</span>T<span style="color:#719e07">&gt;&gt;</span> invokers, URL url, Invocation invocation) <span style="color:#268bd2">throws</span> RpcException; |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Please refer to <a href="../../reference-manual/spi/description/load-balance/">Reference</a> for specific call interception extension methods</p></description></item><item><title>Docs3-V2: Dubbo Mesh</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/mesh/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/mesh/</guid><description> |
| <p>From the design concept, Dubbo Mesh emphasizes the unified control, standardization and governance capabilities of the control plane, while giving more choices on the data plane, including deployment modes such as Sidecar Mesh and Proxyless Mesh. Multiple deployment models provide enterprises with more choices. Through the hybrid deployment model, while realizing the sharing of the service governance control plane, it can better respond to the deployment requirements of different scenarios (performance, deployment complexity, etc.), and adapt to complex infrastructure environment and improve the availability of the architecture as a whole.</p> |
| <h2 id="background">background</h2> |
| <p>In the context of cloud native, if we understand Service Mesh as the underlying infrastructure, in the Mesh architecture, some of the capabilities of microservice governance that were previously coupled in the business process are being taken over by Mesh. The traditional microservice framework pays more attention to RPC protocols and programming. Model. The following is an architecture diagram of the popular Mesh product Istio:</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/istio.jpg" alt="istio"></p> |
| <p>Under the Mesh architecture</p> |
| <ul> |
| <li>The unified control plane provides certificate management, observability, traffic governance and other capabilities</li> |
| <li>Sidecar makes the SDK lighter and less intrusive, better implementing transparent upgrades, traffic interception, etc.</li> |
| </ul> |
| <h2 id="dubbo-mesh-overall-architecture">Dubbo Mesh Overall Architecture</h2> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/dubbo-mesh-arc.png" alt="istio"></p> |
| <ul> |
| <li>The data plane performs RPC communication based on the Triple protocol;</li> |
| <li>The address discovery model adopts application-level service discovery to support ultra-large-scale instance clusters while providing richer service governance capabilities;</li> |
| <li>The Dubbo Mesh control plane is based on the industry&rsquo;s mainstream Istio extension, supports Dubbo service discovery customization solutions, and provides richer traffic control capabilities;</li> |
| <li>The data plane supports two modes: ThinSDK + Sidecar (such as Envoy) and Proxyless;</li> |
| </ul> |
| <blockquote> |
| <p>For old Dubbo2 users or users who have upgraded Dubbo3 but have not yet migrated new features, you can consider referring to Dubbo solutions provided by other Mesh open source communities (such as Aeraki). |
| However, some functions may be limited, and there will be certain performance and capacity bottlenecks.</p> |
| </blockquote> |
| <h3 id="dubbo-sidecar-mesh">Dubbo Sidecar Mesh</h3> |
| <p>Dubbo provides a ThinSDK deployment mode. In this mode, Dubbo ThinSDK will only provide business application-oriented programming APIs and RPC transmission and communication capabilities, and the rest of the service management |
| Including address discovery, load balancing, routing addressing, etc., all sink to Sidecar, and Sidecar is responsible for direct communication with the control plane and receiving various traffic control rules. The following is a basic deployment architecture diagram. Dubbo ThinSDK and Sidecar are deployed in the same pod or container. By deploying an independent control plane on the periphery, unified control of traffic and governance is achieved. The control plane and Sicecar are configured and distributed through the xDS protocol shown in the dotted line in the figure, and the communication between Dubbo processes is no longer a direct connection mode, but instead passes through the Sidecar proxy, which intercepts all incoming and outgoing traffic and completes routing and addressing, etc. Service governance tasks.</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/dubbo-sidecar.png" alt="dubbo-sidecar"></p> |
| <p>The community recommends Envoy as a sidecar, and the communication protocol uses Triple for better gateway penetration and performance experience. For users who are still using the Dubbo2 protocol who cannot upgrade Triple temporarily, they can refer to the Dubbo2 protocol support solutions provided by Envoy and Aeraki Mesh.</p> |
| <p>The Mesh architecture of the ThinSDK + Sidecar mode has many advantages, such as smooth upgrade, multi-language, and small business intrusion, but it also brings some additional problems, such as:</p> |
| <ul> |
| <li>Sidecar communication brings additional performance loss, which will become especially obvious in network calls with complex topologies.</li> |
| <li>The existence of Sidecar makes the life cycle management of the application more complicated.</li> |
| <li>The deployment environment is limited, not all environments can meet the requirements of Sidecar deployment and request interception.</li> |
| </ul> |
| <p>For detailed scheme design and examples, please refer to</p> |
| <ul> |
| <li><a href="https://dubbo.apache.org/zh-cn/overview/tasks/mesh">Dubbo ThinSDK Proposal</a></li> |
| <li><a href="https://dubbo.apache.org/zh-cn/overview/tasks/mesh">Example of use</a></li> |
| </ul> |
| <h3 id="dubbo-proxyless-mesh">Dubbo Proxyless Mesh</h3> |
| <p>As a supplement to the ThinSDK + Sidecar model, the Dubbo community has conceived and thought about the direct connection of Dubbo to the control plane since a long time ago, which is currently called the Proxyless Mesh model. The Proxyless mode brings microservices back to the deployment architecture of the 2.x era. As shown in the figure below, it is very similar to the Dubbo classic service governance model we saw above, so this model is not new. Dubbo has been such a design model from the very beginning. However, compared with the Mesh architecture, Dubbo2 does not emphasize the unified management and control of the control plane, which is exactly what Service Mesh emphasizes. It emphasizes the standardized management, control and governance of traffic, observability, certificates, etc., which is also an advanced part of the Mesh concept. .</p> |
| <p><img src="https://dubbo.apache.org/imgs/v3/mesh/dubbo-proxyless.png" alt="dubbo-proxyless"></p> |
| <p>Through the Dubbo3 SDK of different language versions, the xDS protocol analysis can be directly realized, and the Dubbo process can directly communicate with the control plane (Control Plane), so as to realize the unified control of traffic control, service governance, observability, security, etc. of the control plane, avoiding the Sidecar mode The resulting performance loss and complexity of the deployment architecture.</p> |
| <blockquote> |
| <p>Proxyless mode supports both Dubbo2 and Triple protocols, but only supports the address model of application-level service discovery.</p> |
| </blockquote> |
| <p>In the Dubbo3 Proxyless architecture mode, the Dubbo process will directly communicate with the control plane, and the Dubbo process will continue to maintain a direct communication mode. We can see the advantages of the Proxyless architecture:</p> |
| <ul> |
| <li>There is no additional proxy loss, so it is more suitable for performance-sensitive applications</li> |
| <li>More conducive to smooth migration of legacy systems</li> |
| <li>Simple architecture, easy operation and maintenance deployment</li> |
| <li>Suitable for almost all deployment environments</li> |
| </ul> |
| <p>For detailed scheme design and examples, please refer to</p> |
| <ul> |
| <li><a href="https://dubbo.apache.org/zh-cn/overview/tasks/mesh">Dubbo Proxyless Mesh</a></li> |
| <li><a href="https://dubbo.apache.org/zh-cn/overview/tasks/mesh">Example of use</a></li> |
| </ul> |
| <h3 id="dubbo-control-plane-governance-rules">Dubbo Control Plane Governance Rules</h3> |
| <p>TBD</p> |
| <p>Dubbo SDK provides very flexible configurations to control service governance behaviors, such as interface granular service address discovery capabilities, interface granular configuration synchronization, etc. These capabilities make application development and deployment more flexible. However, some advanced functions may be limited under the general Mesh deployment scheme or product, which generally affects the ease of use and flexibility. To this end, Dubbo plans to provide self-developed control surface products to maximize the capabilities of Dubbo3 in the Mesh system.</p></description></item><item><title>Docs3-V2: Triple Protocol</title><link>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/java-sdk/concepts-and-architecture/triple/</guid><description> |
| <h3 id="protocol-description">Protocol Description</h3> |
| <p>Triple is an HTTP2-based open protocol proposed by Dubbo3, which aims to solve the interoperability problems brought about by Dubbo2&rsquo;s private protocol. Compared with the original Dubbo2 protocol, Triple has the following advantages:</p> |
| <ol> |
| <li>Interoperability between native and gRPC protocols. Open up the gRPC ecology and reduce the migration cost from gRPC to Dubbo.</li> |
| <li>Enhance multilingual ecology. Avoid the problem of difficulty in business selection and adaptation due to insufficient capabilities of Dubbo SDK in CPP/C#/RUST and other languages.</li> |
| <li>Gateway friendly. The gateway does not need to participate in serialization, which is convenient for users to upgrade from the traditional HTTP to generalized Dubbo call gateway to the open source or cloud vendor&rsquo;s Ingress solution.</li> |
| <li>Perfect asynchronous and streaming support. It brings performance improvement from the underlying protocol to the upper-layer business, and it is easy to build a full-link asynchronous streaming service that strictly guarantees the order of messages.</li> |
| </ol> |
| <p>**Currently, the Dubbo SDK for Java and Go fully supports the Triple protocol. ** In Alibaba, the Triple protocol is widely used for cross-environment, cross-language, and cross-ecology interoperability, and hundreds of thousands of containers have been used in production.</p> |
| <h3 id="support-methods">Support methods</h3> |
| <p>Java SDK supports <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/quick-start/idl">IDL Generate Stub</a> |
| and <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/quick-start/idl">Java Interface</a>, the IDL method is recommended for multi-language, ecological interoperability, and streaming requirements, and the smooth upgrade of existing services is recommended |
| Interface method.</p> |
| <ul> |
| <li>How old Dubbo2 users can upgrade from existing protocol to Triple(TBD)</li> |
| <li>New user or business reference <a href="https://dubbo.apache.org/en/docs3-v2/java-sdk/quick-start/idl/">Dubbo3 Triple Quick Start</a></li> |
| <li>In-depth understanding of the Triple protocol: <a href="https://github.com/apache/dubbo-awesome/blob/master/proposals/D0-triple.md">Dubbo3 Triple Protocol Design and Principles</a></li> |
| </ul></description></item></channel></rss> |
