Last time we talked about the history of Dubbo, introduced, understood the call management between cosumber, Proivder, Registry. The source code provided is cosumber and Proivder in one project, and in actual enterprise development they are both under different projects. This time mainly talk about distributed development and joint adjustment, in fact, this pit is very big, bigger than the pit of technology, to deep! Each time the production and consumer directly such oral or document form is not very low, in fact, you can build dubbo console, for the registry last time used in the form of small broadcast, for the actual production environment should choose which registry here will also say.

Source: github.com/limingios/n…

(I) Distributed project development and joint investigation

  • Interface exposure and references

In an RPC scenario, the caller calls the server through an interface, passing in parameters and getting the result back. So the server-side interface and model must be exposed to the caller project. How is the server exposed? How does the client reference it?

1. Interface information 2. Model information 3

The usual way to expose an interface is to separate the interface from the implementation, with the server putting the interface, model, exception, and so on in one module and the implementation in another. The caller makes the reference through Maven.

I remember when I first started using RPC framework dubbo, the server opened a JAR package, threw it to the client through QQ, and then put it into Maven’s repository. Each update needs to send qq JAR package repeatedly, which persisted for a week. It was too laborious. In the project of development, we bickered with each other, saying that jar package mailing was a problem, but he said that there was no problem but to decompile and look at jar package. It is also possible to copy and send jar packages directly, one or two items is still ok, if the items reach a certain number, you send back and forth like this is a little SB, old friend.

  • Automated builds and collaborations

As projects grow and service dependencies become more complex, automation tools must be used to complete the entire process from authoring, building into jars, and finally referencing interfaces in order to improve collaboration efficiency.

Process Description:

1. Service provider project deploys staff to write Client interface 2. Push to remote warehouse 3. Service consumer project developers download from private service repositories based on Maven

  • Interface Smooth Upgrade

In the process of project iteration, multiple projects often use the same interface. Both PROJECT B and PROJECT C use interface 1 in project A. At this time, project B needs to add one more parameter to interface 1. Project B was built online correctly, but Project C was not.

The previous project had this problem, if the interface changed, all the dependent projects would have to change, and the project was trying to solve this problem.

Solutions and principles

Why there is an emergency version, why there is overtime, a lot of times these details are not well controlled.

1. Interfaces should be backward compatible: Interface parameters should be encapsulated as objects. The Model attribute is only added, but not deleted. If it needs to be Deprecated, the @deprecated flag can be added. 2. Interface parameters should not be used in Map format, which is not easy to read and difficult to parse. It is a bit harmful to each other, including producers and consumers. 3. If an incompatible change occurs, the caller must be notified of the rectification and a plan to go live. 4. Do not try version numbers. Project B is upgraded to the new version, while project C is still the old version.

  • The development of alignment

During project development, it is likely that the registry of a development or test environment will host multiple services at the same time. If two sets of services are being coordinated, how can you ensure that the target service is being invoked?

1. Based on temporary group joint survey

Group ={value} group={value} group={value}

2. Directly connected provider:

Direct connections can be made by specifying the provider’S URL in reference

<dubbo:reference url="Dubbo: / / 127.0.0.1:20880" id="demoService"
timeout="2000"
interface="com.tuling.teach.service.DemoService" check="false"/>
Copy the code

3. Registration only: It is possible for a project to be both a service provider and a consumer and need to invoke a service during testing without affecting other subscribers with the service being developed. How to achieve this? Register =false

<dubbo:registry address=Multicast: / / 224.5.6.7: "1234" register="false"/>
Copy the code

PS: this time say so much, the source code or reference my connection, a lot of technical learning are directly look at the official API more clearly, most want to say some of the skills of attention. Next time, dubbo Ali’s background management tool dubbo-admin.