Hello everyone, I am Piaomiao Jam, a third-rate programmer from a third-rate company in a third-rate city. This is our 158th original article. If you like my article, please like it and forward it to support it.
What are microservices
When it comes to microservices, I have to mention the article Microservices published by Martin Fowler on March 25, 2014, which gives the definition of microservices. All subsequent domestic introductions about microservices are based on the translation of this article, or with your own understanding. One of the most important paragraphs is as follows:
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
The translation is: the architectural style of microservices is a way to evolve a set of small services into a single application. Each application runs in its own process and communicates through lightweight mechanisms, such as APIs such as HTTP. These services are based on business scenarios and released independently using automated deployment tools. There can be a very lightweight centralized management to coordinate these services, services can be written in different languages, and different data stores can be used.
How to Implement Microservices
Compared with the simple and crude monolithic architecture, the microservice architecture breaks up the application and forms multiple microservices for independent development, testing, deployment and operation and maintenance. Although it is more in line with business needs in terms of management and logic, the microservice architecture also brings many core problems that need to be solved urgently:
-
How to discover new service nodes and check the status of service nodes?
-
How to discover services and how to achieve load balancing?
-
How to communicate messages between services?
-
How to expose the service API to the user?
-
How to centrally manage the configuration files of many service nodes?
-
How to collect logs of service nodes and manage them in a unified way?
-
How to implement call link tracking between services?
-
How to protect the link of the system to avoid the avalanche of microservices?
It can be found that the above-mentioned problems are not specific to a certain language or a certain technology. Any software manufacturer who wants to build a microservice architecture must face these problems, either independently develop or integrate multiple existing technologies to form an overall solution. Fortunately, after years of precipitation, the industry has already had a standard answer. The figure below clearly illustrates the standard components required by the microservice architecture.
API gateway: encapsulates the internal architecture of the system and provides a customized API for each client. In the microservice architecture, the core point of the service gateway is that all clients and consumers access microservices through a unified gateway, and handle all non-business functions at the gateway layer.
Registration Center: The core technical component in the microservice architecture system, it plays the role of registration and state maintenance of new service nodes. Mainstream microservice frameworks such as Dubbo and Spring Cloud have built service registries based on distributed system coordination tools such as Zookeeper and Eureka.
Service routing: In a multi-service cluster environment built through the registration center, when a client request arrives at the cluster, how to determine which server will respond to the request? This is the service routing problem.
Service communication: In the microservice definition, it is stated that the communication between services adopts a lightweight protocol, usually HTTP RESTful style. However, because the RESTful style is too flexible, it must be constrained, and it is usually encapsulated in the upper layer when it is applied. For example, Feign and RestTemplate are provided in Spring Cloud to shield the underlying RESTful communication details.
Service protection: For services in a distributed environment, when the service itself fails and causes errors, it will also fail due to dependence on other services. In addition to timeouts, retries, and asynchronous decoupling, which are relatively easy to think of and implement, we need to consider fault tolerance mechanisms for various scenarios.
Link tracking: A complex business process may need to continuously call multiple microservices. We need to record the running status of each microservice involved in a complete business logic, and then display it through a visual link diagram to help software engineers when the system goes wrong. To analyze and solve problems, common solutions include Zipkin and SkyWalking.
Unified log management: The microservice architecture disperses and saves application logs on each microservice node by default. When the system performs user behavior analysis and data statistics, it must collect log data from all nodes, which is very inconvenient. At this time, we need an independent log platform to collect log data of all nodes and facilitate summary analysis. Common solutions include ELK and EFK.
Configuration center: In the microservice architecture, considering the number of services and the dispersion of configuration information, it is generally necessary to introduce the design idea and related tools of the configuration center. By deploying the configuration center server, the originally scattered configuration files are stripped from the application and transferred to the configuration center in a centralized manner. Generally, the configuration center will provide a UI interface, which can conveniently and quickly realize the configuration adjustment of large-scale clusters.
Why choose Spring Cloud
First of all, Spring Cloud has a natural advantage because it is a member of the Spring family, and Spring's strong position in the field of Java EE development has played a very good role in promoting Spring Cloud. At the same time, Spring Boot, on which Spring Cloud is based, has become the most popular development framework in the Java EE field, which is used to simplify the framework construction and development process of Spring applications.
Second, the completeness of technical components is the main reason why we choose Spring Cloud. Spring Cloud contains almost all technical components required to develop a complete microservice system, including service registration and discovery, API gateway, configuration center, message processing, load balancing, fuses, data monitoring and other common technical components can be based on Spring Boot is quickly integrated into business systems.
The following are the commonly used technical components in SpringCloud
Why choose Spring Cloud Alibaba
First of all, the technical components in Spring Cloud are the best of all, such as the registration center Eureka, Zuul, etc. are all dependent on Netflix, which also makes it subject to third-party manufacturers. If Zuul announces to stop maintenance, the Spring organization will have to find alternatives or self-develop; Eureka2.x closed source is not allowed;
Secondly, after Springcloud was introduced into China as a foreign product, it became unacceptable. For example, SpringCloud Config stores files on Github by default, and there is no maintenance interface. Domestic software companies rarely agree to do so. For example, our department uses the Apollo configuration center to replace the native Spring Cloud Config.
Spring Cloud Alibaba is a one-stop solution for domestic microservice development. It is compatible with the original Spring Cloud and expands the microservice ecosystem. By adding a small amount of configuration annotations, it can realize a microservice architecture that is more in line with national conditions. Currently, Spring Cloud Cloud Alibaba is already a sub-project directly under Spring Cloud. The official website is: https://spring.io/projects/spring-cloud-alibaba#overview
Spring Cloud Alibaba integrates the service registration, configuration center, and load balancing functions into Nacos. It has a graphical interface, which simplifies the complexity of the microservice architecture and reduces the probability of problems. The original service protection component is also adjusted to Sentinel, which is more powerful and user-friendly than Hystrix. At the same time, it also supports calls to Dubbo, and Seata is used to support distributed transactions.
This article is shared from the WeChat public account - JAVA Rizhilu (javadaily).
If there is any infringement, please contact [email protected] to delete it.
This article participates in the " OSC Source Creation Program ". You are welcome to join in and share it.