Today’s sharing started, please give us more advice ~
For now, the Dubbo framework is an EXCELLENT RPC framework in its current position and a must learn framework. Maybe it will be better, maybe it will be lonely. But its design ideas are worth learning from.
If you have two services in a project. UserService and orderService. We want one service to call the other.
We might write something like this:
As the business becomes more complex, there is bound to be business unbundling in development. The initial module is split through Maven.
In this scenario, the orderService side is called the service provider, and the side calling The orderService is called the service consumer. This thought also foreshadows the emergence of Dubbo.
How does the userService of the JVM call orderService?
After years of precipitation in Java remote calls, one framework after another has emerged to optimize the process of this call bit by bit.
The first is the socket call. Open the socket service in orderService and make remote calls in userService.
- Advantages: Solve the problem of single – machine call.
- Disadvantages: Complex code, not easy to expand.
This is probably the first remote call solution, and I have never encountered a framework for pure socket calls.
How to call across languages?
We found that objects in Java cannot be transferred directly through sockets, requiring a serialization process. And Java’s default serialization cannot be parsed by other languages. As a result, services provided by other languages cannot be called through Java. Therefore, the socket is upgraded to transmit information through HTTP + XML. This is where the webservice comes in.
Web Services technology enables different applications running on different machines to exchange data or integrate with each other without the need for additional, specialized third-party software or hardware. Applications implemented according to the Web Service specification can exchange data with each other, regardless of the language, platform, or internal protocol they use.
Web Services, while widely used in their early days, are still an outdated framework. Because the same data is much less likely to pass through JSON than through XML. Using JSON will consume less bandwidth. As the following data.
Internal call protocol
HTTP is an application-layer protocol, which is a good choice for external systems to implement cross-language invocation. Using HTTP for internal invocation of your own Java service is a waste of resources.
As shown in the figure above, HTTP requires a TCP three-way handshake before interaction, and data is transferred after a successful handshake. An HTTP interaction has a request header, request body, response header, and response body. This data, when internally called, a lot of data that doesn’t matter. Perhaps custom protocols can be used to simplify data transfer. This leads to the Dubbo protocol, which is an internally invoked protocol.
Dubbo protocol pursues small amount of data, small is fast, the design of the protocol is also in line with the concept of Dubbo frame, suitable for data interaction with internal services. Security is not as good as HTTPS, but it doesn’t need to be, since the Dubbo protocol is designed for internal use.
Spring Cloud’s Feign component uses HTTP internally. Internal calls can be a bit wasteful, but HTTP allows cross-language calls.
RPC framework
It’s not perfect for an RPC framework just to make remote calls.
Developing a service typically requires multiple machines to be deployed to prevent a single point of failure. With a more sophisticated RPC framework, you need to make automatic choices when multiple machines provide the same service. As shown in the figure above, userServuce needs to automatically recognize the cluster information when calling orderService and automatically select the machine to call.
Currently, orderService has only one service and three machines. Maybe you can configure three IP addresses in userServuce and write your own routing rules. However, with the complexity of business and the change of machines, we may not be able to know the IP information of machines at first.
To implement dynamic machine addition and removal. Finally, a coordinator of machines is added, to which all open service machines add information about their open services, and which machines in this coordinator open which services. In this way, the coordinator acts like an “address book”. We call this directory the registry.
Such a relatively complete RPC framework has a prototype.
- Service providers submit information about their services to the registry after they start.
- Service consumers, when consuming, go to the registry to check whether there is a machine to provide the corresponding service. For example, when you call orderService, you can see that there are 192.168.1.1 and 192.168.1.2 machines that provide the corresponding services. Consumers can choose which service to invoke based on random, rotational and other rules.
- When a service goes online or offline, the registry can notify you of changes.
Such a set of processes, on the perfect implementation of the dynamic deployment of services, can be arbitrarily deployed services.
Registry selection
The registry, as the coordinator, occupies an important position. In this way, the registry functions primarily as a temporary data store. You can choose from a variety of databases, Redis, ZooKeeper, Eureka, NACOS, or implement your own.
At the beginning, the Dubbo framework officially recommended using ZooKeeper as the registry, and gradually changed from ZooKeeper to NACOS after the emergence of NACOS.
Why did ZooKeeper switch to NacOS?
Conclusion: ZooKeeper is a good choice to act as a registry for big data calculation, but in service invocation, data may not need to be super consistent. Nacos is currently a friendly registry that offers CP+AP. There is a visual interface, there is a configuration center and so on. It’s quite functional.
History of SpringCloud and Dubbo
It was in ’17 that those two words came to my attention. There was also a super popular Springboot. At that time, almost every job required springboot. All of a sudden, it became a necessary foundation for Java development.
Because SpringBoot is developing at a much faster speed, and springCloud components are more complete, feign, gateway, configuration center, fuse, and so on. Spring, SpringCloud, and SpringBoot are clearly family. This made it a bit difficult for dubbo to stand alone, and some companies moved from the Dubbo framework to the SpringCloud bucket.
In July 2018, Eureka stopped updating. For now, Eureka’s function as a registry is good enough. But for such a fast pace of the Internet era, stop updating, it means that it will slowly disappear.
On the evening of July 24, 2019, Spring Cloud officially announced that Spring Cloud Alibaba is about to graduate. Many components are provided, and nacos, Dubbo, and Seata should be common ones for most developers.
- Nacos: Registry.
- Dubbo: A high-performance open source RPC framework based on Java.
- Seata: A high-performance and easy-to-use distributed transaction solution for microservices architectures.
Nacos is a new registry that features a visual interface and a configuration center. Dubbo found his family in an instant. These components have given Dubbo a rise again. And Dubbo is inherently scalable. You can do protocol extension, call interception extension, reference listening extension, cluster extension, and so on
In addition, dubbo3.0 mainly uses Triple protocol. Fully compatible with gRPC over HTTP/2. Using Protobuf as the default serialization is recommended for better performance and cross-language results.
conclusion
No matter how maven is split, it always runs within a JVM, just to make it easier to develop code. However, there is no way to adjust a service when it is under a lot of stress. Ultimately, we want userService and orderService to run in different JVMS. If orderService has more access, we can just scale it up.
Today’s share has ended, please forgive and give advice!