Why does micro-service choose Spring Cloud?

Objective
Today's microservices architectures are popular, and microservices-based systems also bring clarity to business segmentation and scalability. At the same time, the technology stack that supports microservices is also diverse, and this series focuses on the leading--spring Cloud in these technologies. This is a preface to the main story of why we chose Spring Cloud and its technology overview.

1. Why the MicroServices architecture requires spring Cloud

To put it simply, the core of service is to split the traditional one-stop application into one service based on the business, while the microservices are more thoroughly decoupled (no longer sharing db, KV, removing the heavyweight ESB) and emphasizing devops and rapid evolution. This requires that we must adopt a technology stack that is different from the one-stop era and the pan-SOA era, and spring Cloud is one of the best.

DevOps is a combination of English development and operations, and he requires the development, testing, and operation of integrated collaboration for smaller, more frequent, more automated application launches, and architecture for building infrastructure around application architectures. This requires the application of adequate cohesion, but also convenient operation and management. This concept coincides with the concept of micro-service.

The next step is to see why spring Cloud adapts to the microservices architecture in terms of the evolution of the service architecture. Click here to view the collection of Spring Series tutorials.

1.1 from the use of Nginx speaking

The initial service solution is to provide a unified domain name for providing the same service, then the Service caller sends an HTTP request to the domain name, and the Nginx is responsible for the requested distribution and jump.

There are many problems with this architecture:

Nginx, as the middle tier, is coupled with the logic of service invocation in the configuration file, which weakens the integrity of the microservices and makes Nginx become a heavyweight ESB to some extent.

Service information is dispersed across systems and cannot be managed and maintained uniformly. Each service call is an attempt, and the service consumer does not know what instances are being served. This is not in line with the DevOps philosophy.

It is not possible to visually see the current health and communication frequency of service providers and service consumers. This is not in line with the DevOps philosophy.

Consumers fail to re-send, load balancing and so there is no unified strategy, which increases the difficulty of the development of each service, not conducive to rapid evolution.

To solve the problem above, we need a ready-made central component to integrate the services, summarizing the information for each service, including the component name, address, quantity, etc. of the service. The caller of the service, when requesting a service, first obtains the information (IP, port, etc.) of the instance that provides the service through the central component, and then accesses it directly through a default or custom policy that selects a provider of the service. So, we introduced the Dubbo.

1.2 Implementation of MicroServices based on Dubbo

Dubbo is Ali Open source SOA service Governance solution, the document is rich in the domestic use is very high.

Using Dubbo to build microservices has been a better solution to the problems mentioned above:

Calling the middle tier becomes an optional component that consumers can access directly to the service provider.

Service information is centralized into registry, which forms the central component of service governance.

The monitor monitoring system provides a visual representation of the service invocation statistics.

The consumer can be used for load balancing and service downgrade options.

But for the microservices architecture, Dubbo is not perfect either:

Registry relies heavily on third-party components (zookeeper or Redis), and service calls are quickly interrupted when there are problems with those components.

Dubbo only supports RPC calls. Makes the service provider and the caller strongly dependent on the code, and the service provider needs to constantly package the jar package containing the common code for consumer use. Once a problem is packaged, a service call error occurs.

Most importantly, Dubbo has now been re-maintained, and new needs for technology development need to be developed by developers themselves. This is obviously quite appropriate for many small and medium-sized software organizations that want to adopt a microservices architecture.

The GitHub community now has an upgraded version of Dubbo called Dubbox, which provides a more efficient way to serialize RPC and rest calls. But the project also basically stopped maintenance.

1.3 New options for--spring Cloud

As a new generation of service frameworks, Spring Cloud's slogan is to develop "cloud-oriented applications" that provide a more comprehensive technical support for the microservices architecture. Click here to view the collection of Spring Series tutorials.

Combining the demands of our first mentioned microservices, we compare Spring Cloud with Dubbo:

Spring Cloud has abandoned Dubbo RPC traffic, using an HTTP-based rest approach. Strictly speaking, both of these methods have their merits and demerits. Although the latter sacrifices the performance of service invocations to a certain extent, it avoids the problem caused by the native RPC mentioned above. And rest is more flexible than RPC, and the dependence of service providers and callers relies on only one paper contract, and there is no code-level strong dependency, which is more appropriate in the context of fast evolving microservices.

Eureka is more suitable for service discovery than zookeeper, and this will unfold in detail in the next article.

It is clear that spring cloud is more powerful than Dubbo and covers a wider range, and as a spring fist project, it is also able to work with the spring Framework, Spring Boot, Spring Data, Spring The integration of other spring projects, such as batch, is critical to micro-services. As mentioned earlier, one of the key concepts behind microservices is continuous integration, rapid delivery, and the use of a unified technical framework within the service is clearly more efficient than combining disparate technologies. More importantly, compared to Dubbo, it is an open source project that is being continuously maintained and the community is more hot, which ensures that the systems it builds will continue to be supported by open source power. Click here to view the collection of Spring Series tutorials.

2. Spring Cloud Technology Overview

Shows the complete technical composition of spring cloud:

Service governance: This is the heart of spring cloud. Spring Cloud is currently focused on this by integrating Netflix's related products (Spring cloud Netflix), including Eureka for service registration and discovery, call Breaker hystrix, call-side load balancing ribbon, Rest client feign, intelligent service routing Zuul, is used to monitor data collection and presentation of Spectator, Servo, and Atlas for configuring read Archaius and providing reactive for controller layer Rxjava encapsulation. In addition, for

Feign and Rxjava are not Netiflix products, but are integrated into spring Cloud Netflix.

The registration and discovery of services, in addition to Eureka,spring Cloud, also incorporates consul and zookeeper as alternatives, but since these two scenarios follow the CP in theory instead of the AP (which is described in detail in the next article), it is not recommended by the authorities.

Distributed Link monitoring: Spring Cloud Sleuth provides fully automated, configurable data burial points to collect performance data on the micro-service invocation link and send it to Zipkin for storage, statistics, and presentation.

Message components: Spring Cloud Stream abstracts the various requirements of distributed messaging, including publishing subscriptions, packet consumption, message fragmentation, and so on, enabling asynchronous communication between microservices. Spring Cloud Stream also integrates third-party RABBITMQ and Apache Kafka as Message Queuing implementations. Spring Cloud bus, based on spring Cloud Stream, provides inter-service event communication (such as refresh configuration).

Configuration Center: Based on Spring cloud Netflix and Spring Cloud bus,spring, the Spring Cloud Config provides a central concept for configuring centralized management and dynamic refresh. The configuration is stored via git or a simple file, supporting encryption and decryption.

Security control: Spring Cloud Security provides a single sign-on, resource authorization, token management, and other functions in a microservices environment based on OAUTH2, an open network safety standard.

Command-line tools: The Spring Cloud CLI provides a way to manage microservices and Spring cloud components in a command-line and script way.

Cluster tool: Spring Cloud cluster provides the technical components needed for a distributed cluster such as cluster selection, distributed locks (pending), one-time tokens (not implemented).

Why does micro-service choose Spring Cloud?