This is the seventh day of my participation in the More text Challenge. For details, see more text Challenge
Let’s start with Nginx and see why microservices are needed. The original servitization solution was to provide a uniform domain name for the same service, and then the service caller would send HTTP requests to this domain, with Nginx responsible for distributing and jumping the requests.
There are many problems with this architecture: Nginx acts as a middle tier, coupling the logic of service invocation in the configuration file, which weakens the integrity of microservices and makes Nginx a heavyweight ESB to some extent. Figure 1 identifies the forwarding information flow of Nginx. Figure 1 Information flow forwarded by Nginx
Service information is distributed in various systems and cannot be managed and maintained in a unified manner. Every service invocation is an attempt, and the service consumer has no idea what instances are offering them services. This creates some problems: the current health and communication frequency of service providers and service consumers cannot be visually seen; Consumers do not have a unified strategy for failure retransmission, load balancing, etc., which makes it difficult to develop each service and prevents rapid evolution.
To solve the above problem, we need a central component in place to integrate the services and summarize the information for each service, including the service component name, address, quantity, and so on.
When the caller of a service requests a certain service, it first obtains the instance information (IP, port, etc.) that provides the service through the central component, and then selects a certain provider of the service for direct access through the default or customized policies, so Dubbo is considered to be introduced.
Dubbo is an open source SOA service governance solution of Alibaba. It is well documented and widely used in China. Figure 2 shows the basic architecture diagram of Dubbo, where the microservices built with Dubbo have been able to better address the above issues. Figure 2 basic architecture diagram of Dubbo
From Figure 2, you can see the following: The invocation middle tier becomes an optional component, giving consumers direct access to the service provider; Service information is centralized in Registry, forming the central component of service governance; By monitoring the system with Monitor, you can visually display the statistics of service invocation. Service consumers can choose between load balancing and service degradation.
However, Dubbo is not perfect for microservices architecture, and there are some drawbacks, such as Registry’s heavy reliance on third-party components (ZooKeeper or Redis), which can interrupt service calls quickly when those components go wrong. Dubbo supports only RPC calls. This creates a strong code dependency between the service provider and the caller, and the service provider needs to continually package jars containing common code for consumption. Any problems with the packaging can result in errors in the service invocation.
In my opinion, Dubbo and Spring Cloud are not fully competitive, and they solve different problem domains.
While Dubbo has always been positioned as an RPC framework, Spring Cloud aims to be a one-stop solution in a microservices architecture. Dubbo can be compared to the Netflix OSS technology stack, and Spring Cloud integrates Netflix OSS as a distributed service governance solution, But beyond that, Spring Cloud provides solutions to distributed issues such as configuration, messaging, security, invocation chain tracing, and more.
At present, due to problems such as RPC protocol and registry metadata mismatch, Dubbo and Spring Cloud can only choose one when facing the selection of microservice infrastructure framework, which is one of the reasons why Dubbo and Spring Cloud are always compared.
Dubbo has been adapted to the Spring Cloud ecosystem, for example as a binary communication solution for Spring Cloud to take advantage of Dubbo’s performance. Dubbo has been adapted to Spring Cloud through modularity and support for HTTP. What’s good about Spring Cloud As a new generation of services framework, Spring Cloud put forward the slogan of developing “cloud-oriented applications”, it provides more comprehensive technical support for microservices architecture. See Table 1 for a comparison between Spring Cloud and Dubbo in the context of the microservice appeal we mentioned at the beginning. Table 1 Comparison between Spring Cloud and Dubbo
| The name of the function | ZooKeeper | Spring Cloud Netflix Eureka |
|---|---|---|
| Service Registry | ZooKeeper | Spring Cloud Netflix Eureka |
| Service invocation mode | RPC | REST API |
| The service gateway | There is no | Spring Cloud Netflix Zuul |
| The circuit breaker | imperfect | Spring Cloud Netflix Hystrix |
| Distributed configuration | There is no | Spring Cloud Config |
| Service tracking | There is no | Spring Cloud Sleuth |
| The message bus | There is no | Spring Cloud Bus |
| The data flow | There is no | Spring Cloud Stream |
| The batch task | There is no | Spring Cloud Task |
Spring Cloud abandons Dubbo’s RPC communication and adopts THE REST method based on HTTP. Strictly speaking, both approaches have their pros and cons. While the latter sacrifices the performance of service invocation to some extent, it avoids the problems of native RPC mentioned above. Moreover, REST is more flexible than RPC in that there is no strong code-level dependency between service providers and callers, which is more appropriate in a microservice environment that emphasizes rapid evolution.
Obviously, Spring Cloud is much more powerful and wide-ranging than Dubbo, and as Spring’s flagship project, It also works well with the Spring Framework, Spring Boot, Spring Data, Spring Batch, and other Spring projects, which are critical for microservices.
As mentioned earlier, one of the key concepts behind microservices is continuous integration and rapid delivery, and using a unified technology framework within a service is clearly more efficient than putting disparate technologies together.
What’s more, it’s a much hotter open source project under ongoing maintenance than Dubbo, which ensures that systems built with it continue to be supported by open source forces.
Here are some of the advantages of Spring Cloud. Spring Cloud comes from Spring, and its quality, stability and persistence can be guaranteed. Spirng Cloud naturally supports Spring Boot, making it easier for services to land. Spring Cloud has grown very quickly, starting with a 1.x version of the related components, and is now releasing the 2.x series. Spring Cloud is the best framework for microservices in the Java space.
Spring Cloud has the most support for the surrounding environment of microservices compared to other frameworks. For small and medium-sized enterprises, the use of low threshold.
What is Spring Cloud? Spring Cloud version introduction
The next article covers the Spring Cloud development environment in more detail