Choice of microservices infrastructure: Spring Cloud or Dubbo?

In recent days, whether it is the Internet or the traditional industry, almost all the circles involved in information technology are talking about microservices architecture. Recently, I have also seen salons and forums organized by various technical communities to share their experience in implementing Spring Cloud, which has been very encouraging for me as I have been organizing the content and application examples of Spring Cloud related kits.

At present, Spring Cloud is not well known in China. Some architects, TECHNICAL VP or Ctos of Internet companies did not even know the existence of the project when I communicated with them in the job hunting process a few days ago. This may also be related to Dubbo, alibaba’s open source service governance framework in China. In addition to Dubbo’s relatively complete Chinese documents, architects of many technology companies are from Ali Department. Therefore, in the short term, China is still dominated by Dubbo.

So which infrastructure should we choose when implementing a microservices architecture for the first time?

The following contents are the author’s personal views, knowledge is limited, if there is anything wrong, it is normal, do not like spray.

Round 1: Background

Dubbo is the core framework of Alibaba’s servitization governance and is widely used in all member sites of Alibaba Group. Alibaba’s contribution to the open source community in recent years is eye-catching both at home and abroad. For example, JStorm donated to Apache and joined the Apache Foundation, which won face for Chinese Internet people and upgraded Alibaba from an e-commerce company to a technology company in the eyes of Chinese people.

Spring Cloud, as we know from its name, is the product of Spring Source, the powerful endorsement of the Spring community that is arguably the most influential organization in the Java business world. Pivotal and Netfix are its powerful backing and technical output. The core of Spring Cloud is the full set of open source micro-service architecture suite of Netflix.

Summary: If you compare Dubbo with Netflix suite, Dubbo is more influential in China, while Netflix suite is more influential in foreign countries, I think it’s a draw in context. But if you want to compare it to Spring Cloud, Spring Cloud has a slight edge in endorsements thanks to the addition of Spring Source. However, the hero does not care about the provenance, at this point, background cannot be the main factor in choosing a framework, when you are at your wits end, can be used as a reference.

Round 2: Community activity

We chose an open source framework, and community activity was a key concern for us. The more active the community is, the faster the problem can be solved, and the better the framework will be, otherwise when we have a problem, we have to solve it ourselves. For the team, this means that we have to maintain the source code of the framework ourselves, which is also a great burden for the team.

Here’s a look at the github updates for both projects, from July 30, 2016:

• Dubbo ：github.com/dubbo

Last updated on 6 May 2016

• Spring Cloud: github.com/spring-clou…

Last updated: 12 minutes ago

As you can see, the Dubbo update is a few months old and very infrequent. The Spring Cloud update was 12 minutes ago and is still in the phase of rapid iteration.

Summary: Spring Cloud is unarguably better than Dubbo in terms of community activity, which makes it a better choice for teams that don’t have the energy and financial resources to maintain this part of open source content.

Round 3: Architecture integrity

Many would argue that the comparison between Spring Cloud and Dubbo is unfair. Dubbo only implemented service governance, while Spring Cloud has 17 sub-projects (and more may be added) covering all aspects of microservices architecture. Service governance is just one aspect. Dubbo is just a subset of Spring Cloud’s Netflix. However, in the selection framework, program integrity is exactly a content that needs to be focused on.

According to Martin Fowler’s description of microservice architecture, although this architecture has many advantages, such as module decoupling, independent deployment and technical diversity, compared with single architecture, decoupling in distributed environment also brings about a lot of testing and operation complexity.

Take a look at what Spring Cloud and Dubbo offer in terms of the various elements of microservices architecture.

With some of the core components listed above, you can see why Dubbo is just a subset of Netflix. Of course, it is necessary to clarify that Dubbo does not mean that the components summarized as “none” in the above table cannot be implemented, but that Dubbo framework itself does not provide, and needs to be integrated to achieve corresponding functions, such as:

• Distributed configuration: You can use Diamond of Taobao and Disconf of Baidu to implement distributed configuration management. However, in addition to providing configuration management, the Config component in Spring Cloud can use Git for its storage, so it naturally implements configuration content versioning and can be perfectly integrated with application versioning.
• Service tracking: You can use JD’s open source Hydra
• Batch tasks: You can use Dangdang’s open-source elastice-Job
• …

Although Dubbo itself only realizes the basis of service governance, and other features to ensure cluster security, maintainability and testability are not well implemented, almost most of the key components can be realized by third-party open source, mainly from the open source products of large Domestic Internet enterprises.

RPC vs REST

In addition, since Dubbo is a basic framework, whether the content of its implementation is reasonable for us to implement microservices architecture also needs to be considered according to our own needs. For example, Dubbo’s service invocation is implemented through RPC. However, if you have read Martin Fowler’s article MicroServices carefully, The communication between services it defines is the REST API of the HTTP protocol. So what’s the difference between the two?

Let’s start with some of the pain points of implementing inter-service calls using Dubbo’s RPC:

• The service provider and caller are too dependent on the interface: We define a service abstract interface for each microservice, and publish it to a private warehouse through continuous integration. The caller application has a strong dependency on the abstract interface provided by microservice, so strict version dependency management is required regardless of development, testing and integration environment. In this way, there will not be a series of problems such as application failure to compile due to inconsistency between the server and the caller, and this will directly affect the environmental requirements of local development. Often, an upper-layer application that relies on many services will have to update a lot of code and install every day before subsequent development. Without strict version management or the development of automated tools, such dependencies can be a nightmare for development teams. And REST interface than RPC is more lightweight, dependence on the provider and the caller just rely on a paper contract, there is no code level strong dependence, REST interface, of course, also have pain points, because the interface definition too light, it is easy to cause the definition document do not agree with actual implementation result in service integration problems, but the problem is very good, Just integrate Swagger for each service, integrating code and documentation for each service. Therefore, in distributed environment, REST mode service dependency is more flexible than RPC mode dependency.
• Services are platform-sensitive and difficult to reuse simply: When we provide external services, we usually provide them in the way of REST. In this way, cross-platform features can be realized, and callers of any language can be implemented according to the interface definition. In Dubbo, to provide the REST interface, we had to implement a layer of proxy to convert the RPC interface into a REST interface for external distribution. If each of our services itself exists as a REST interface, when we want to provide services externally, we can realize the reuse of services mainly by configuring the mapping relationship and permission control in the API gateway.

I believe these pain points are one of the reasons why Dangdang has added REST support in DubBox, an open source extension based on Dubbo.

Summary: Dubbo has realized the foundation of service governance, but to complete a complete microservice architecture, it needs to be expanded and improved in every link to ensure the health of the cluster, to reduce the pressure on development, testing and operation and maintenance, so that all link personnel can really focus on business logic. Spring Cloud still carries forward Spring Source’s all-in-one style, integrates some mature products and frameworks of micro-service architecture in a standardized manner, and inherits Spring Boot’s characteristics of simple configuration, rapid development and easy deployment. Making complex architectural work relatively easy to get started with (if you’ve read my previous articles on the use of some of Spring Cloud’s core components, you can appreciate these exciting features, portals). Therefore, if you choose Dubbo, it is important to prepare the whole solution at every stage, otherwise the team will be overwhelmed by the difficulties caused by the lack of architecture as the number of services increases. If you choose Spring Cloud, relatively speaking, each link has the corresponding component support, some may not meet all your needs, but its active community and high-speed iteration schedule will also be a strong backing you can rely on.

Round 4: Document quality

Dubbo’s document can be said to be first-class among domestic open source frameworks, very comprehensive, and very in-depth explanation. Since the version has been stable and no longer updated, there will not be inconsistent situations. In addition, it provides Chinese and English versions, which is easier for domestic developers to read. That’s why Dubbo is more popular in China.

Due to the integration of a large number of components, the volume of Spring Cloud documents is naturally much more than dubbo, and the content of the documents is relatively concise and clear, but more of them tend to be integrated. For more in-depth use methods, you still need to check the detailed documents of its integrated components. In addition, because Spring Cloud is based on Spring Boot, many examples are much simpler than traditional Spring applications (because of automatic configuration, much of the content is the default configuration of the convention), which may be a little uncomfortable for new developers. It is recommended to use Spring Cloud after understanding and learning Spring Boot, otherwise there may be a lot of half-knowledge.

Summary: Although Spring Cloud has a large amount of documentation, if you use Dubbo to integrate other third-party components, you actually have to read a lot of third-party component documentation, so I don’t see much difference in the amount of documentation. For document quality, I think Dubbo is better because Spring Cloud iterates quickly and inconsistencies are inevitable. As for the documentation language, Dubbo naturally has an advantage for domestic development teams.

conclusion

Through the analysis of the above several links, I believe you have a preliminary understanding of Dubbo and Spring Cloud. As far as I am using experience and understanding of the two frameworks, make an inappropriate analogy: use Dubbo building micro service architecture is like a computer, we choose a high degree of freedom of each link, but the end result is likely because of a memory no good quality point not bright, always let people don’t trust, but if you are a player, that these are not problems; Spring Cloud, on the other hand, is like a branded machine. Under the integration of Spring Source, a lot of compatibility tests are done to ensure a higher stability of the machine. However, if you want to use something other than the original components, you need to have a sufficient understanding of its foundation.

Based on the current level of attention and activity, Spring Cloud is likely to become the standard framework for microservices architecture in the future. So I’m going to continue this Spring Cloud series. Welcome friends to communicate and make progress together.

Summary 】 【 some articles and sample: git.oschina.net/didispace/S…