Tag: Microservices DuboSpring architecture
preface
Micro-service architecture is a hot topic on the Internet and an inevitable result of the development of Internet technology. It advocates the partitioning of a single application into a small set of services that coordinate with each other to provide ultimate value to users. Although there is no recognized technical standard, specification or draft for microservice architecture, there are some influential open source microservice architecture frameworks in the industry that provide the key ideas of microservice, such as Dubbo and Spring Cloud. Major Internet companies also have their own microservice frameworks, but their models are not very different from these two. The main advantages of microservices are as follows:
Reduce complexity
Breaking up complex businesses that used to fit together into a single service avoids the never-ending accumulation of complexity. Each microservice focuses on a single function and clearly expresses service boundaries through well-defined interfaces. Each service developer focuses on the service itself, using caching, DAL, and other technologies to improve the performance of the system, while being completely transparent to the consumer.
Independently deployable
Because microservices have independent running processes, each microservice can be deployed independently. When the business is iterated, only the iteration of relevant services need to be released, which reduces the workload of testing and reduces the risk of service release.
Fault tolerance
In the microservices architecture, when a component fails, the failure is isolated in a single service. Reduce the damage caused by errors by limiting current and fusing to ensure the normal operation of core services.
extension
Monolithic applications can also achieve horizontal scaling, where the entire application is replicated to different nodes. Microservices architectures are flexible when different components of an application have different scaling requirements, because each service can scale independently based on actual needs.
In this paper, Dubbo and Spring Cloud development frameworks are compared comprehensively from the aspects of technology selection, communication protocol, service dependency mode, start-up mode and operation mode of microservices. The architect can choose a suitable microservice architecture platform based on the technical strength of the company and the characteristics of the project to implement the microservice transformation or development process in a safe manner.
1 Core Components
The core elements of microservices are service discovery, registration, routing, fusing, degradation, and distributed configuration. Based on these necessary conditions, Dubbo and Spring Cloud are compared.
1.1 Overall Architecture
Dubbo core components, as shown below:
Provider: exposes the Provider of the service. You can start the service through a JAR or container.
Consumer: the service Consumer that invokes the remote service;
Registry: Service Registry and discovery center;
Monitor: Statistics service and call times, call time monitoring center, Dubbo console page can be displayed, currently only a simple version;
Container: The Container in which the service runs.
The overall architecture of Spring Cloud is shown in the following figure:
Service Provider: exposes the Service Provider.
Service Consumer: the Service Consumer that invokes the remote Service;
Eureka Server: Service registry and service discovery center.
Comments: In terms of overall architecture, the two models are similar, requiring service providers, service consumers and registries.
1.2 Core elements of microservice architecture
Dubbo only implements service governance, while the Spring Cloud sub-projects separately cover many parts of the microservices architecture, of which service governance is just one aspect. Dubbo provides a variety of filters, which can be improved by extending the Filter. For example,
Distributed configuration: You can use Diamond of Taobao and Disconf of Baidu to achieve distributed configuration management.
Service tracking: You can use JD open source Hydra, or Zippin extension Filter to do service tracking;
Batch tasks: You can use dangdang’s open-source elastice-job and tbSchedule.
Comments: In terms of core elements, Spring Cloud is superior. In the development process, it can smoothly complete the integration of various components as long as the integration of Spring Cloud sub-projects, while Dubbo needs to implement various filters for customization, which is slightly higher in development cost and technical difficulty.
2 Communication Protocol
The protocol types supported by the two frameworks and their operational efficiency are compared based on the communication protocol level.
2.1 Supported Protocols
Dubbo: Dubbo uses the RPC communication protocol and provides the following serialization modes:
Dubbo: The default Dubbo protocol adopts a single long connection and NIO asynchronous communication, which is suitable for service invocation with small data volume and large concurrency, and the number of service consumer machines is much larger than that of service provider machines.
RMI: RMI protocol uses JDK standard java.rmI.* implementation, using blocking short connection and JDK standard serialization;
Hessian: The Hessian protocol is used to integrate Hessian services. Hessian uses Http communication at the bottom layer and Servlet to expose the service. Dubbo lacks Jetty as the server implementation.
Http: Uses Spring’s HttpInvoker implementation
Webservice: Frontend -simple and Transports – HTTP are implemented based on CXF.
Spring Cloud: Spring Cloud uses the HTTP protocol REST API.
2.2 Performance Comparison
Using a POJO object with 10 attributes and 100,000 requests, Dubbo and Spring Cloud take the following time (ms) per request for different threads:
Note: The ECS server of Ali Cloud is used for client and server configuration, with 4-core 8G configuration, and Dubbo adopts the default Dubbo protocol
Comments: Dubbo supports a variety of communication protocols, and consumers and services interact with each other through long links, which is slightly faster than Spring Cloud in terms of communication speed. If there are strict requirements on system response time, long links are more suitable.
3 Service dependency mode
Dubbo: Service providers and consumers rely on each other through interfaces. The design of service invocation is as follows:
Interface layer: the service Interface layer, which defines all interfaces provided by the service.
Molel layer: DTO object layer of the service;
Business layer: The Business implementation layer, which implements the Interface Interface and interacts with the DB.
Therefore, each microservice needs to define its own Interface Interface and publish it to a private warehouse through continuous integration. The caller application has a strong dependency on the abstract Interface provided by the microservice, and the development, testing and integration environment all need strict management of version dependency.
Service callers only need to rely on the Interface and Model layers to publish them to the repository via Maven’s install & deploy commands. Only the Snapshot version is released during the development and debugging phase, and the Release version is released after the service debugging is completed. The version of each iteration is distinguished by the version number. XML configuration can be used to access Dubbo, no intrusion to the program.
Spring Cloud: Service providers and service consumers interact with each other in JSON mode, so they only need to define relevant JSON fields. There is no interface dependency between the consumer and provider. Implementing service configuration through annotations is intrusive.
Comments: Dubbo service dependency is slightly heavy, needs to have a sound version management mechanism, but the program intrusion is less. However, Spring Cloud eliminates the problem of version management through JSON interaction, but specific field meanings need to be managed in a unified way. The interaction of its OWN Rest API lays a foundation for cross-platform invocation.
4 Component Running process
Each component in the figure below needs to be deployed on a separate server, where the gateWay accepts front-end requests, aggregates services, and invokes back-end atomic services in bulk. Each Service layer interacts with a separate DB.
Dubbo,
GateWay: indicates the front gateWay. Service operations are performed automatically by the gateWay using the load balancing mechanism provided by Dubbo.
Service: provides only the atomic services related to the Service.
Zookeeper: Atomic services are registered with Zookeeper.
A Spring Cloud,
All requests access the internal service uniformly through the API Gateway (Zuul);
After receiving the request, the gateway obtains available services from the Registry center (Eureka).
The Ribbon balances the load and distributes it to specific instances on the backend.
Microservices communicate with each other through Feign.
Comments: The business deployment mode is the same, both need a front gateway to isolate the external direct call atomic service risk. Dubbo needs to develop its own API gateway, while Spring Cloud can customize the gateway through Zuul configuration. Spring Cloud is a step up in usage.
5 Composition and precautions of microservice architecture
It doesn’t really matter whether you’re using Dubbo or Spring Cloud, it’s all about how to use microservices properly. Here is a general architecture of the Internet, each of which is a core part of microservices.
5.1 Architecture Decomposition
Gateway cluster: data aggregation, authentication of access clients, anti-packet replay and anti-data tampering, service authentication of function invocation, desensitization of response data, flow and concurrency control, etc.
Service cluster: Generally, gateways for mobile terminal access and browser access must be isolated to prevent service coupling.
Local Cache: Because clients may need to invoke multiple service aggregations to access services, Local Cache effectively reduces the frequency of service invocation and improves access speed. The local cache generally uses automatic expiration, and certain data delay is allowed in service scenarios.
Service layer: atomic Service layer, to achieve basic add, delete, change and check functions, if need to rely on other services need to actively call in the Service layer;
Remote Cache: A pre-distributed Cache for DB access to reduce DB interaction times and improve TPS of the system.
DAL: Data access layer. If the amount of data in a single table is too large, it needs to be processed by DAL layer.
MQ: Message queues are used to decouple dependencies between services, and asynchronous calls can be performed using MQ.
Database master/slave: A necessary stage in the servitization process to improve the TPS of the system.
5.2 Precautions
You are advised to start the service in JAR mode, which is fast and easy to monitor.
Cache, cache, cache, the system can use the cache as far as possible, through the reasonable use of cache can effectively improve the TPS system;
Service split should be reasonable, avoid service cycle dependence caused by service split as far as possible;
Set the thread pool properly to avoid system exceptions caused by too large or too small Settings.
6 summarizes
Born in Alibaba, Dubbo is the core framework of Alibaba’s servitization governance, which is widely used in Various Internet companies in China. You only need to complete servitization through Spring configuration, no intrusion for applications. The purpose of the design is still to serve their own business. Although Ali internal reasons Dubbo once suspended the maintenance of the version, but the maturity of the framework itself and the perfect degree of documentation, fully meet the business needs of major Internet companies. If we need to use a configuration center, distributed tracking, these things need to be integrated, which makes using Dubbo more difficult.
Spring Cloud is the product of the well-known Spring family, which focuses on the development of enterprise open source frameworks. Since the development of Spring Cloud, it is still developing at a high speed. Almost every aspect of service governance is taken into account. It is very convenient and simple to develop.
Dubbo started maintenance again in 2017 with an updated version 2.5.6, while Spring Cloud has been updated very quickly and has been updated to Finchley.m2. Therefore, enterprises need to choose the appropriate architecture to solve their business problems according to their level of research and development and stage. Both Dubbo and Spring Cloud are effective tools to implement microservices.