| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Apache Dubbo – Concept</title><link>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/</link><description>Recent content in Concept on Apache Dubbo</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/index.xml" rel="self" type="application/rss+xml"/><item><title>Docs3-V2: generalization call</title><link>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/generic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/generic/</guid><description> |
| <p>Generalized call is a special call method of Dubbo-Go, which allows intermediate nodes to pass call information without interface information, and is often used in test and gateway scenarios. Generalized calls support Dubbo and Triple protocols, but the current serialization scheme only supports Hessian.</p> |
| <h2 id="background">background</h2> |
| <p>For ease of understanding, this document uses gateway usage scenarios to introduce generalized calls. Let&rsquo;s consider ordinary calls first (non-generic calls). The figure below contains two key roles of consumer and provider (endpoint is used to represent a consumer or a provider in the following), and each has a definition of the org.apache.dubbo.sample.User interface. Assume that the org.apache.dubbo.sample.User interface needs to be used in the calling behavior.</p> |
| <p><img src="https://dubbo.apache.org/imgs/docs3-v2/golang-sdk/concept/rpc/generic/1631941941270-86ce9845-5a88-4cb5-8c8a-da8ae7eeb4d5.png" alt="img"></p> |
| <p>RPC needs to be transmitted through network media, so data cannot be transmitted in go struct form, but must be transmitted in binary form. This requires the consumer side to serialize the structure that implements the org.apache.dubbo.sample.User interface into a binary format before transmission. Similarly, for the provider side, binary data needs to be deserialized into structure information. <strong>In short, common calls require that the interface information must have the same definition at each endpoint, so as to ensure that the results of data serialization and deserialization are consistent with expectations</strong>.</p> |
| <p>In the gateway scenario, it is impossible for the gateway to store all interface definitions. For example, a gateway needs to forward 100 service calls, and the number of interfaces required for each service is 10. Common calls require all 1000 (100 * 10) interface definitions to be stored in the gateway in advance, which is obviously difficult to achieve. So is there a way to forward calls correctly without storing interface definitions in advance? The answer is yes, which is why generic calls are used.</p> |
| <h2 id="principle">principle</h2> |
| <p>The essence of generalized calls is to transform complex structures into general structures. The general structures mentioned here refer to maps, strings, etc., and the gateway can smoothly parse and transfer these general structures.</p> |
| <p><img src="https://dubbo.apache.org/imgs/docs3-v2/golang-sdk/concept/rpc/generic/1632207075184-25939db4-f384-452e-a0b8-e1deff7971de.png" alt="img"></p> |
| <p>Currently, Dubbo-go v3 only supports Map generalization (default). Let&rsquo;s take the User interface as an example, and its definition is as follows.</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-go" data-lang="go"><span style="display:flex;"><span><span style="color:#586e75">// definition |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span><span style="color:#268bd2">type</span> User <span style="color:#268bd2">struct</span> { |
| </span></span><span style="display:flex;"><span>ID <span style="color:#dc322f">string</span> |
| </span></span><span style="display:flex;"><span>name <span style="color:#dc322f">string</span> |
| </span></span><span style="display:flex;"><span>Age <span style="color:#dc322f">int32</span> |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">func</span> (u <span style="color:#719e07">*</span>User) <span style="color:#268bd2">JavaClassName</span>() <span style="color:#dc322f">string</span> { |
| </span></span><span style="display:flex;"><span><span style="color:#719e07">return</span> <span style="color:#2aa198">&#34;org.apache.dubbo.sample.User&#34;</span> |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Assume that calling a service requires a user as an input parameter, and its definition is as follows.</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-go" data-lang="go"><span style="display:flex;"><span><span style="color:#586e75">// an instance of the User |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span>user <span style="color:#719e07">:=</span> <span style="color:#719e07">&amp;</span>User{ |
| </span></span><span style="display:flex;"><span> ID: <span style="color:#2aa198">&#34;1&#34;</span>, |
| </span></span><span style="display:flex;"><span> Name: <span style="color:#2aa198">&#34;Zhangsan&#34;</span>, |
| </span></span><span style="display:flex;"><span> Age: <span style="color:#2aa198">20</span>, |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>Then, when using Map generalization, user will be automatically converted to Map format, as shown below.</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-go" data-lang="go"><span style="display:flex;"><span>usermap <span style="color:#719e07">:=</span> <span style="color:#268bd2">map</span>[<span style="color:#268bd2">interface</span>{}]<span style="color:#268bd2">interface</span>{} { |
| </span></span><span style="display:flex;"><span> <span style="color:#2aa198">&#34;iD&#34;</span>: <span style="color:#2aa198">&#34;1&#34;</span>, |
| </span></span><span style="display:flex;"><span> <span style="color:#2aa198">&#34;name&#34;</span>: <span style="color:#2aa198">&#34;zhangsan&#34;</span>, |
| </span></span><span style="display:flex;"><span> <span style="color:#2aa198">&#34;age&#34;</span>: <span style="color:#2aa198">20</span>, |
| </span></span><span style="display:flex;"><span> <span style="color:#2aa198">&#34;class&#34;</span>: <span style="color:#2aa198">&#34;org.apache.dubbo.sample.User&#34;</span>, |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>have to be aware of is:</p> |
| <ul> |
| <li>Map generalization will automatically lowercase the first letter, that is, ID will be converted to iD. If you need to align Dubbo-Java, please consider changing ID to Id;</li> |
| <li>A class field is automatically inserted in the Map to identify the original interface class.</li> |
| </ul> |
| <h2 id="use">use</h2> |
| <p>The generalization call is transparent to the provider side, that is, the provider side can correctly handle the generalization request without any explicit configuration.</p> |
| <h3 id="generalized-call-based-on-dubbo-url">Generalized call based on Dubbo URL</h3> |
| <p>The call based on Filter generalization is transparent to the consumer, and the typical application scenario is a gateway. This method needs to require the Dubbo URL to include a generic call identifier, as shown below.</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-plain" data-lang="plain"><span style="display:flex;"><span>dubbo://127.0.0.1:20000/org.apache.dubbo.sample.UserProvider?generic=true&amp;... |
| </span></span></code></pre></div><p>The meaning expressed by this Dubbo URL is:</p> |
| <ul> |
| <li>The RPC protocol is dubbo;</li> |
| <li>org.apache.dubbo.sample.UserProvider interface at 127.0.0.1:20000;</li> |
| <li>Use generic calls (generic=true).</li> |
| </ul> |
| <p>The Filter on the Consumer side will automatically convert ordinary calls into generalized calls according to the configuration carried by the Dubbo URL, but it should be noted that in this way, the response result is returned in a generalized format and will not be automatically converted into the corresponding object. For example, in the map generalization mode, if the User class needs to be returned, then the consumer will get a map corresponding to the User class.</p> |
| <h3 id="manual-generalization-call">Manual generalization call</h3> |
| <p>The request initiated by the manual generalization call does not pass through the filter, so the consumer side needs to initiate the generalization call explicitly. The typical application scenario is testing. In <a href="https://github.com/apache/dubbo-go-samples/tree/master/generic">dubbo-go-samples</a>, manual calls are used for the convenience of testing.</p> |
| <p>The generalized call does not need to create a configuration file (dubbogo.yaml), but it needs to manually configure the registration center, reference and other information in the code. The initialization method is encapsulated into the newRefConf method, as shown below.</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-go" data-lang="go"><span style="display:flex;"><span><span style="color:#268bd2">func</span> <span style="color:#268bd2">newRefConf</span>(appName, iface, protocol <span style="color:#dc322f">string</span>) config.ReferenceConfig { |
| </span></span><span style="display:flex;"><span>registryConfig <span style="color:#719e07">:=</span> <span style="color:#719e07">&amp;</span>config.RegistryConfig{ |
| </span></span><span style="display:flex;"><span>Protocol: <span style="color:#2aa198">&#34;zookeeper&#34;</span>, |
| </span></span><span style="display:flex;"><span>Address: <span style="color:#2aa198">&#34;127.0.0.1:2181&#34;</span>, |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span>refConf <span style="color:#719e07">:=</span> config.ReferenceConfig{ |
| </span></span><span style="display:flex;"><span>InterfaceName: iface, |
| </span></span><span style="display:flex;"><span>Cluster: <span style="color:#2aa198">&#34;failover&#34;</span>, |
| </span></span><span style="display:flex;"><span>Registry: []<span style="color:#dc322f">string</span>{<span style="color:#2aa198">&#34;zk&#34;</span>}, |
| </span></span><span style="display:flex;"><span>Protocol: protocol, |
| </span></span><span style="display:flex;"><span>Generic: <span style="color:#2aa198">&#34;true&#34;</span>, |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span>rootConfig <span style="color:#719e07">:=</span> config.<span style="color:#268bd2">NewRootConfig</span>(config.<span style="color:#268bd2">WithRootRegistryConfig</span>(<span style="color:#2aa198">&#34;zk&#34;</span>, registryConfig)) |
| </span></span><span style="display:flex;"><span>_ = rootConfig.<span style="color:#268bd2">Init</span>() |
| </span></span><span style="display:flex;"><span>_ = refConf.<span style="color:#268bd2">Init</span>(rootConfig) |
| </span></span><span style="display:flex;"><span>refConf. <span style="color:#268bd2">GenericLoad</span>(appName) |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#719e07">return</span> refConf |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>The newRefConf method receives three parameters, which are:</p> |
| <ul> |
| <li>appName: application name;</li> |
| <li>iface: service interface name;</li> |
| <li>protocol: RPC protocol, currently only supports dubbo and tri (triple protocol).</li> |
| </ul> |
| <p>In the above method, in order to keep the function simple, the registration center is set to a fixed value, that is, ZooKeeper at 127.0.0.1:2181 is used as the registration center, which can be freely customized according to the actual situation in practice.</p> |
| <p>We can easily get a ReferenceConfig instance, temporarily named refConf.</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-go" data-lang="go"><span style="display:flex;"><span>refConf <span style="color:#719e07">:=</span> <span style="color:#268bd2">newRefConf</span>(<span style="color:#2aa198">&#34;example.dubbo.io&#34;</span>, <span style="color:#2aa198">&#34;org.apache.dubbo.sample.UserProvider&#34;</span>, <span style="color:#2aa198">&#34;tri&#34;</span>) |
| </span></span></code></pre></div><p>Then we can initiate a generic call to the GetUser method of the org.apache.dubbo.sample.UserProvider service.</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-go" data-lang="go"><span style="display:flex;"><span>resp, err <span style="color:#719e07">:=</span> refConf. |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">GetRPCService</span>().(<span style="color:#719e07">*</span>generic.GenericService). |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">Invoke</span>( |
| </span></span><span style="display:flex;"><span>context. <span style="color:#268bd2">TODO</span>(), |
| </span></span><span style="display:flex;"><span><span style="color:#2aa198">&#34;GetUser&#34;</span>, |
| </span></span><span style="display:flex;"><span>[]<span style="color:#dc322f">string</span>{<span style="color:#2aa198">&#34;java. lang. String&#34;</span>}, |
| </span></span><span style="display:flex;"><span>[]hessian. Object{<span style="color:#2aa198">&#34;A003&#34;</span>}, |
| </span></span><span style="display:flex;"><span> ) |
| </span></span></code></pre></div><p>The Invoke method of GenericService receives four parameters, which are:</p> |
| <ul> |
| <li>context;</li> |
| <li>Method name: In this example, it means calling the GetUser method;</li> |
| <li>Parameter type: GetUser method accepts a parameter of string type. If the target method accepts multiple parameters, it can be written as <code>[]string{&quot;type1&quot;, &quot;type2&quot;, ...}</code>, if the current method has no parameters , you need to fill in an empty array <code>[]string{}</code>;</li> |
| <li>Actual parameter: The writing method is the same as the parameter type. If it is a parameterless function, an empty array <code>[]hessian.Object{}</code> should still be filled in.</li> |
| </ul> |
| <p>Note: In the current version, there will be a crash problem when calling without parameters.</p> |
| <p>Related reading: <a href="https://blog.csdn.net/weixin_39860915/article/details/122738548">[Dubbo-go service proxy model]</a></p></description></item><item><title>Docs3-V2: Multilingual RPC</title><link>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/multi_language/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/multi_language/</guid><description> |
| <p><img src="https://dubbo.apache.org/imgs/docs3-v2/golang-sdk/concept/rpc/multi_language/dubbogo-3.0-invocation.png" alt="img"></p> |
| <h3 id="cross-language-call">Cross-language call</h3> |
| <p>With the wide-scale application of microservice scenarios, multi-language scenarios are becoming more and more common, and developers are more willing to use more suitable languages to implement different modules of a complex system. For example, use C to write gateways, use Go to write K8S resource operators, and use Java to write business applications. Languages and scenarios are not bound. Enterprises can often choose the appropriate language by combining their own technology stack and the expertise of developers.</p> |
| <p>In multilingual scenarios, the ability to call across languages is very important.</p> |
| <p>Cross-language capability is essentially the capability provided by <a href="../protocol/">[Network Protocol]</a>. How to conveniently allow users to use the required network protocols, develop for appropriate cross-language scenarios, and enjoy the service governance capabilities of the Dubbo ecosystem are the concerns of the Dubbo-go service framework.</p> |
| <h3 id="cross-ecology">Cross Ecology</h3> |
| <p>The Dubbo-go service framework provides cross-ecology capabilities. Developers can use Dubbo-go and its <a href="../../../refer/ecology/">ecology project</a> to build HTTP/front-end services, Dubbo/Spring applications , The connection between gRPC ecological applications.</p></description></item><item><title>Docs3-V2: Network Protocol</title><link>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/protocol/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/protocol/</guid><description> |
| <h2 id="1-rpc-service-framework-and-network-protocol">1. RPC service framework and network protocol</h2> |
| <p>The network protocol is very important in the RPC scenario. In the microservice scenario, the communication between service processes depends on the network that can be connected, and the network protocol that is consistent between the client and the server. Network protocol is an abstract concept. From the perspective of Dubbo-go application development, we might as well divide the protocols we care about into three dimensions for discussion.</p> |
| <h3 id="11-unpacking-protocol">1.1 unpacking protocol</h3> |
| <p>The built-in packaging and unpacking protocols of the Dubbo-go service framework are all based on the TCP/IP protocol stack. On this basis, various protocols are encapsulated/introduced, such as Triple (dubbo3), Dubbo, and gRPC.</p> |
| <p>This type of protocol focuses on the encapsulation and disassembly process of TCP packets to ensure reliable point-to-point communication.</p> |
| <p>In the dubbo-go ecosystem, supporting multiple networks is often worth this type of protocol.</p> |
| <h3 id="12-serialization-protocol">1.2 Serialization protocol</h3> |
| <p>The serialization protocol is responsible for serializing objects in memory into a binary stream in a specific format. Some mainstream serialization libraries include: the json serialization method with good readability and wide application; the protobuf serialization method with high compression efficiency and better performance; the hessian2 serialization method adapted to the Java language, etc. Dubbo-go has these three built-in serialization methods</p> |
| <p>The serialization protocol needs to be paid attention to by developers during the business development process. The serialization protocol often requires specific object annotations:</p> |
| <p>An example of a protobuf sequence object generated by protoc-gen-go:</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-protobuf" data-lang="protobuf"><span style="display:flex;"><span>type HelloRequest struct { |
| </span></span><span style="display:flex;"><span>state protoimpl.MessageState |
| </span></span><span style="display:flex;"><span>sizeCache protoimpl.SizeCache |
| </span></span><span style="display:flex;"><span>unknownFields protoimpl.UnknownFields |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span>Name <span style="color:#dc322f">string</span> `protobuf<span style="color:#719e07">:</span><span style="color:#2aa198">&#34;bytes,1,opt,name=name,proto3&#34;</span> json<span style="color:#719e07">:</span><span style="color:#2aa198">&#34;name,omitempty&#34;</span>` |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>A hessian2 serialized object that can communicate with java services</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-go" data-lang="go"><span style="display:flex;"><span><span style="color:#268bd2">type</span> HelloRequest <span style="color:#268bd2">struct</span> { |
| </span></span><span style="display:flex;"><span>Name <span style="color:#dc322f">string</span> <span style="color:#2aa198">`hessian:&#34;name&#34;`</span> |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#268bd2">func</span> (u <span style="color:#719e07">*</span>HelloRequest) <span style="color:#268bd2">JavaClassName</span>() <span style="color:#dc322f">string</span> { |
| </span></span><span style="display:flex;"><span><span style="color:#719e07">return</span> <span style="color:#2aa198">&#34;org.apache.dubbo.sample.User&#34;</span> |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>The relationship between the serialization protocol and the unpacking protocol</p> |
| <ul> |
| <li>A packaging and unpacking protocol can be adapted to support multiple serialization protocols: for example, you can use dubbogo&rsquo;s triple protocol to pass hessian serialization parameters to communicate with the Dubbo-java service framework; pass pb serialization parameters to communicate with native gRPC services Interoperability; by implementing the interface to customize your desired serialization method, such as json, so as to pass parameters with strong readability.</li> |
| </ul> |
| <h3 id="13-interface-protocol">1.3 Interface protocol</h3> |
| <p>The interface protocol is a protocol developed and maintained by business developers, which is used to describe the information of the service interface. Such as interface name, method, parameter type.</p> |
| <p>Taking Triple/gRPC as an example, developers can use plug-ins to generate a stub (.pb.go file) from the interface defined in the proto file. The stub file contains all the information of the interface and the interface protocol.</p> |
| <p>When writing a service, the client and the server introduce the same interface at the same time, which can ensure that the client initiates a call for a specific interface and method, which can be correctly identified and responded by the server.</p> |
| <p>An interface description file written by proto:</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-protobuf" data-lang="protobuf"><span style="display:flex;"><span>syntax <span style="color:#719e07">=</span> <span style="color:#2aa198">&#34;proto3&#34;</span>; |
| </span></span><span style="display:flex;"><span><span style="color:#719e07">package</span> api; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#719e07">option</span> go_package <span style="color:#719e07">=</span> <span style="color:#2aa198">&#34;./;api&#34;</span>; |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#586e75">// The greeting service definition. |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span><span style="color:#268bd2">service</span> Greeter { |
| </span></span><span style="display:flex;"><span> <span style="color:#586e75">// Sends a greeting |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span> <span style="color:#719e07">rpc</span> SayHello (HelloRequest) <span style="color:#719e07">returns</span> (User) {} |
| </span></span><span style="display:flex;"><span> <span style="color:#586e75">// Sends a greeting via stream |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span> <span style="color:#719e07">rpc</span> SayHelloStream (stream HelloRequest) <span style="color:#719e07">returns</span> (stream User) {} |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#586e75">// The request message containing the user&#39;s name. |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span><span style="color:#268bd2">message</span> <span style="color:#268bd2">HelloRequest</span> { |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">string</span> name <span style="color:#719e07">=</span> <span style="color:#2aa198">1</span>; |
| </span></span><span style="display:flex;"><span>} |
| </span></span><span style="display:flex;"><span> |
| </span></span><span style="display:flex;"><span><span style="color:#586e75">// The response message containing the greetings |
| </span></span></span><span style="display:flex;"><span><span style="color:#586e75"></span><span style="color:#268bd2">message</span> <span style="color:#268bd2">User</span> { |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">string</span> name <span style="color:#719e07">=</span> <span style="color:#2aa198">1</span>; |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">string</span> id <span style="color:#719e07">=</span> <span style="color:#2aa198">2</span>; |
| </span></span><span style="display:flex;"><span> <span style="color:#dc322f">int32</span> age <span style="color:#719e07">=</span> <span style="color:#2aa198">3</span>; |
| </span></span><span style="display:flex;"><span>} |
| </span></span></code></pre></div><p>The relationship between interface protocol and serialization protocol</p> |
| <ul> |
| <li>Interface protocol is an abstract concept. An interface protocol can be written in multiple interface description languages, and can be converted into multiple serialized protocol objects.</li> |
| </ul> |
| <h2 id="2-network-protocols-supported-by-dubbo-go">2. Network protocols supported by Dubbo-go</h2> |
| <p>The network protocols and serialization methods supported by Dubbo-go are as follows:</p> |
| <p>| protocol | protocol name (for configuration) | serialization method | default serialization method | |
| | &mdash;&mdash;&mdash;&mdash;&mdash; | &mdash;&mdash;&mdash;&mdash;&mdash;&ndash; | :&mdash;&mdash;&mdash;&mdash;- &mdash;&mdash;&mdash;-: | &mdash;&mdash;&mdash;&mdash;&ndash; | |
| | Triple 【Recommend】 | tri | pb/hessian2/msgpack/custom | pb | |
| | Dubbo | dubbo | hessian2 | hessian2 | |
| | gRPC | grpc | pb | pb | |
| | jsonRPC | jsonrpc | json | json |</p> |
| <p>Related reading: <a href="https://developer.aliyun.com/article/878252">[Dubbo-go Service Proxy Model]</a></p></description></item><item><title>Docs3-V2: Service Registration Discovery</title><link>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/registry/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://dubbo.apache.org/en/docs3-v2/golang-sdk/preface/concept/registry/</guid><description> |
| <h2 id="1-dubbos-registration-center">1. Dubbo&rsquo;s registration center</h2> |
| <p>The registration center is responsible for saving the information of the server application in the RPC scenario.</p> |
| <p>The server registers the interface information and sends its own address to the registration center, and the client reads and subscribes to the list of addresses that need to be called from the registration center. The entire structure is shown in the figure:</p> |
| <p><img src="https://dubbo.apache.org/imgs/architecture.png" alt="img"></p> |
| <p>For details about Dubbo service discovery, please refer to <a href="https://dubbo.apache.org/zh-cn/docs/concepts/service-discovery/">Dubbo Official Website Concept Introduction</a></p> |
| <h2 id="2-service-discovery-concept">2. Service discovery concept</h2> |
| <p>In the Dubbo ecosystem, service discovery has the following main concepts:</p> |
| <ul> |
| <li> |
| <p>Application Application</p> |
| <p>The application is a dubbo service process, corresponding to an application name.</p> |
| </li> |
| <li> |
| <p>interface (service)</p> |
| <p>An interface is an RPC interface class, such as a Service defined by proto, or a Java Interface class. A dubbo process can contain multiple services/interfaces.</p> |
| </li> |
| <li> |
| <p>method</p> |
| <p>Methods are defined in interfaces, and an interface can contain multiple methods.</p> |
| </li> |
| <li> |
| <p>parameter list</p> |
| <p>The parameter list is defined in the method. Since Java supports overloading, a method can contain multiple parameter lists. For Go it is a one-to-one relationship.</p> |
| </li> |
| <li> |
| <p>registration message</p> |
| <p>In the &ldquo;interface-level service discovery&rdquo; scenario, the registration information mainly includes the application name, interface list, metadata information, and the IP address of the server. It is stored in the registration center in the form of URL for the client to query before initiating a call.</p> |
| <p>In the &ldquo;application-level service discovery&rdquo; scenario, the registration information only includes a small amount of application-level information such as the application name and the mapping from the application name to the interface, and the interface-level information is stored as metadata in the metadata center.</p> |
| </li> |
| <li> |
| <p>metadata</p> |
| <p>Metadata refers to interface information, such as interface name, contained methods, parameters corresponding to methods, serialization methods, protocols, and other information.</p> |
| </li> |
| <li> |
| <p>Registry</p> |
| <p>The registration center is used to save the information of the server.</p> |
| </li> |
| <li> |
| <p>Metadata center</p> |
| <p>The metadata center is used to save the metadata information of the server, and in the &ldquo;application-level service discovery&rdquo; scenario, it serves as the dependency of the &ldquo;service introspection&rdquo; stage.</p> |
| </li> |
| </ul> |
| <p>Dubbo-go&rsquo;s most advanced service grid capability introduces the following concepts</p> |
| <ul> |
| <li> |
| <p>CPU name</p> |
| <p>The host name currently applies to the Service name registered on k8s. Other applications can access this application instance through the hostname.</p> |
| </li> |
| <li> |
| <p>endpoint</p> |
| <p>Endpoints include the instance&rsquo;s IP address, port.</p> |
| </li> |
| <li> |
| <p>cluster</p> |
| <p>The cluster ID holds the data from {hostname, cluster_subset_name, port}</p> |
| <p>A cluster maintains a mapping of cluster IDs to all of its contained endpoints.</p> |
| </li> |
| <li> |
| <p>Service Mesh Metadata</p> |
| <p>The service mesh metadata is an interface name-to-hostname-to-map, which is used by clients to query the hostname information of the desired interface.</p> |
| </li> |
| </ul> |
| <h2 id="3-dubbo-go-registration-center">3. Dubbo-go Registration Center</h2> |
| <p>The registry types supported by Dubbo-go are as follows:</p> |
| <table> |
| <thead> |
| <tr> |
| <th>registry</th> |
| <th>registry name (for configuration)</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td>Zookeeper</td> |
| <td>zookeeper</td> |
| </tr> |
| <tr> |
| <td>Nacos</td> |
| <td>nacos</td> |
| </tr> |
| <tr> |
| <td>Etcd</td> |
| <td>etcd</td> |
| </tr> |
| <tr> |
| <td>Consul</td> |
| <td>consul</td> |
| </tr> |
| </tbody> |
| </table> |
| <p>Related reading: <a href="https://developer.aliyun.com/article/764173">[Analysis of application-level service discovery]</a></p></description></item></channel></rss> |
