To compare the similarities and differences between the two micro-service frameworks, we first understand the implementation of micro-service based on Dubbo.
Dubbo is an open source SOA service governance solution in Ali. It has abundant documents and is widely used in China.
Microservices built with Dubbo can solve the problems mentioned above.
- The call middle layer becomes an optional component, and consumers have direct access to the service provider.
- Service information is centralized in Registry, forming the central component of service governance.
- Through Monitor monitoring system, the statistical information of service invocation can be displayed intuitively.
- The can choose load balancing and service degradation.
But Dubbo is not perfect for micro-service architecture either:
- Registry relies heavily on third-party components (zookeeper or redis), and when these components fail, service invocations quickly interrupt.
- DUBBO only supports RPC calls, as a result, service providers and callers have a strong code dependency, and service providers need to constantly package jar packages containing common code for consumers to use. Once there is a problem with packaging, service invocation errors will occur.
- Most importantly, DUBBO is now out of maintenance, and the new demand for technological development needs to be expanded and upgraded by developers themselves. This is obviously inappropriate for many small and medium-sized software organizations that want to adopt micro-service architecture.
New Choice – Spring Cloud
As a new generation of service framework, Spring Cloud’s slogan is to develop “cloud-oriented applications”, which provides more comprehensive technical support for micro-service architecture.
Spring Cloud abandoned Dubbo’s RPC communications and adopted an HTTP-based REST approach. Strictly speaking, these two ways have their own advantages and disadvantages. Although to some extent, the latter sacrifices the performance of service invocation, it also avoids the problems caused by the native RPC mentioned above. Moreover, REST is more flexible than RPC. The dependencies of service providers and invokers depend on only one contract, and there is no strong dependency at the code level. This is more appropriate in a microservice environment that emphasizes rapid evolution.