As a Java programmer, I still need to be clear about the evolution of the system architecture. First, I will briefly describe the evolution of the architecture.
1. Monolithic architecture (centralized architecture)
The single structure is relatively elementary, a typical three-level structure, front-end (Web/mobile terminal) + intermediate business logic layer + database layer. This is a typical Java Spring MVC framework application
Monolithic architecture is to gather all functions and modules into one project and deploy them on a server to provide external services (centralized architecture, monolithic service, monolithic application)
Monolithic applications are easier to deploy and test. In the early stages of a project, monolithic applications can run well. However, as demand continued to increase and more and more people joined the development team, the code base also expanded rapidly. Slowly, the monolithic application becomes more and more bloated, the maintainability and flexibility gradually decrease, and the maintenance cost becomes higher and higher.
2. Distributed Architecture
In the book "Principles and Paradigms of Distributed Systems", there is the following definition: a distributed system is a collection of several independent computers , and these computers are like a single related system to users. A system of computer nodes that work together to accomplish a common task.
To put it simply, it is to split all functions and modules into different sub-projects and deploy them on multiple different servers. These sub-projects cooperate with each other to provide external services
Compared with the single architecture, this architecture provides load balancing capabilities, greatly improves the system load capacity, and solves the high concurrency requirements of the website. For example, an e-commerce project can be split into sub-projects/modules such as user user, order order, shopping cart shop, etc.
The picture is from Baidu
Advantages of this architecture:
(1) Reduce the coupling degree: split the module, use the interface to communicate, and reduce the coupling degree between the modules
(2) Clear responsibilities: split the project into several sub-projects/modules, and different teams are responsible for different sub-projects/modules
(3) Easy to expand: when adding functions, you only need to add another sub-project/module, and call the interface of other systems.
(4) Easy deployment: flexible distributed deployment
(5) Improve the reusability of the code: For example, if the service layer does not adopt the distributed service architecture, it is necessary to write a service layer on the pc, android, and ios ends. The large amount of development is difficult to maintain and upgrade. Distributed services are used and shared a service layer
Disadvantages: The interaction between systems requires remote communication, and interface development increases the workload (but the overall advantages outweigh the disadvantages)
3. Microservice architecture
The following focuses on combing
4. Cloud Native Architecture
Cloud-native applications generally refer to applications that natively support cloud deployment and can make full use of the capabilities of the cloud platform. It generally has three characteristics:
Containerized packaging. Containerized encapsulation refers to the container-based application, which is encapsulated in the container and runs in the container, so as to realize the relative isolation of resources and the reuse of container images.
Microservice-oriented. Microservice-oriented refers to splitting a large functional application into micro-applications with single function, relatively independent and decoupled from each other, and the micro-applications communicate through interfaces.
Dynamic management. Dynamic management refers to the dynamic management and scheduling of these microservices through a unified orchestration tool, such as K8S.
Later, with the development of cloud computing, the CNCF Cloud Native Computing Foundation added two more items: declarative API and service grid .
If an application meets the above characteristics, it can be called a cloud-native application. Because of the inherent advantages of cloud-native applications, more and more enterprises are embracing cloud-native applications, which requires enterprises to have a new technical architecture to make better use of cloud-native technologies. And this kind of technical architecture that uses cloud-native technology to make businesses more agile, cost-effective, and more powerful can become a cloud-native architecture. It uses container technology, is based on microservices, and uses agile methods to achieve continuous delivery of applications through the DevOps journey.
Cloud Native Architecture = Microservices + Containerization + DevOps + Continuous Delivery .
1. Microservice Architecture
Microservice Architecture
Microservices (Microservices) is an architectural style for building a single application through the composition of multiple small services, which are built around business capabilities rather than specific technical standards. Each service can use different programming languages, different data storage technologies, and run in different processes. The service adopts a lightweight communication mechanism and an automated deployment mechanism to achieve communication and operation and maintenance.
The Origin of Microservices
The technical term "microservice" was first proposed in 2005. It was first used by Dr. Peter Rodgers at the 2005 Cloud Computing Expo (Web Services Edge 2005), when it was called "Micro-Web-Service" , refers to a single-responsibility-focused, language-independent, fine-grained Web service (Granular Web Services).
Microservices
The real rise of microservices was in 2014, and it was also the first time I learned about microservices from the article " Microservices: A Definition of This New Architectural Term " co-written by Martin Fowler (Martin Fowler) and James Lewis (James Lewis). . The "microservice" that everyone knows is the "microservice" defined in this article
Original link to Microservices
Translate the original link to microservices｜YYGCui's blog
In this article, the concept of modern microservices is first given:
" Microservices is an architectural style that builds a single application through the composition of multiple small services. These services are built around business capabilities rather than specific technical standards. Each service can use different programming languages, different data storage technologies, run In different processes. The service adopts a lightweight communication mechanism and an automated deployment mechanism to achieve communication and operation and maintenance ."
In addition, the article lists nine core business and technical characteristics of microservices, which will be listed and interpreted below.
- Organized around Business Capability . The importance of Conway's Law is emphasized here again. A team with any structure, scale, and capabilities will produce products with corresponding structures, scales, and capabilities. This conclusion is not a coincidence encountered by a certain team or a certain company, but an inevitable result of evolution. If the functions that should belong to the same product are divided into different teams, a large amount of cross-team communication and collaboration will inevitably occur. Crossing team boundaries will have higher costs in terms of management, communication, and work arrangements. Efficient teams will naturally Improvements will be made for it. When the team and product are adjusted and stabilized, the team and product will have a consistent structure.
- Decentralized Governance . This is to express the meaning of "whose child is in charge". The development team corresponding to the service is directly responsible for the quality of service operation, and should also have the right to control all aspects of the service without external interference, such as choosing and other services. Heterogeneous technologies to implement your own services. This point has some leeway in actual practice. Most companies will not use Java for one service, Python for another, and Golang for the next. Instead, they usually have a unified mainstream language, or even a unified Technology stack or proprietary technology platform. Microservices neither advocates nor opposes this kind of "unification". As long as the team responsible for providing and maintaining the basic technology stack has the awareness of being relied on by all parties, and must be mentally prepared to "often be woken up by the alarm clock at 3 o'clock in the morning", good. What microservices emphasizes is that when technical heterogeneity is really necessary, they should have the right to choose "non-uniformity". For example, Node.js should not be forced to develop report pages. When doing artificial intelligence training models, you should be able to choose Python. etc.
- Componentization via Services to realize independent and autonomous components (Componentization via Services). The reason why we emphasize building components through "Service" instead of "Library" is because the class library is statically linked into the program at compile time and provides functions through local calls, while the service is an out-of-process component. Functionality is provided through remote calls. In the previous article, we have analyzed that although remote services have higher invocation costs, this is a necessary price for bringing isolation and autonomy to components.
- Product thinking (Products not Projects). Avoid viewing software development as a function to be completed, but as a process of continuous improvement and improvement. For example, operation and maintenance should not only be regarded as the work of the operation and maintenance team, but development should only be regarded as the work of the development team. The team should be responsible for the entire life cycle of the software product. Developers should not only know how software is developed, but also know how it is developed. How it works, how users give feedback, and even how the after-sales support work is carried out. Note that the user of the service here is not necessarily the end user, but may also be another service that consumes this service. In the past, under the monolithic structure, the scale of the program determined that all personnel could not pay attention to the complete product. In the organization, there would be members with detailed division of labor such as development, operation and maintenance, and support. Each person only focused on his own piece of work, but Under microservices, it is feasible for everyone in the development team to have product thinking and care about all aspects of the entire product.
- Data decentralization (Decentralized Data Management). Microservices clearly advocate that data should be managed, updated, maintained, and stored in a decentralized manner. In a single service, each functional module of a system usually uses the same database. It is true that centralized storage is inherently easier to avoid consistency problems , however, the abstract form of the same data entity is often different from the perspective of different services. For example, the book in the Bookstore application focuses on the price in the sales field, the inventory quantity in the warehousing field, and the introduction information of books in the product display field. If it is used as a centralized storage, all fields must Modifying and mapping to the same entity makes it possible for different services to affect each other and lose their independence. Although it is quite difficult to deal with the consistency problem in a distributed environment, and traditional transaction processing cannot be used to guarantee it in many cases, but the lesser of two evils, some necessary costs are still worth paying.
- Strong terminal weak pipeline (Smart Endpoint and Dumb Pipe). Weak pipeline (Dumb Pipe) is almost a bunch of complex communication mechanisms that directly oppose SOAP and ESB. ESB can handle message encoding processing, business rule conversion, etc.; BPM can centrally orchestrate enterprise business services; SOAP has dozens of WS-* protocol families to handle a series of tasks such as transactions, consistency, authentication and authorization, etc. These are built on the communication pipeline The above function may be necessary for a certain part of the service in a certain system, but it is an imposed burden for more other services. If the service needs the above additional communication capabilities, it should be resolved on the service's own Endpoint, rather than a package on the communication pipeline. Microservices advocate a simple and direct communication method similar to classic UNIX filters, and RESTful style communication will be a more suitable choice in microservices.
- Fault-tolerant design (Design for Failure). No longer illusory pursuit of eternal stability of services, but acceptance of the reality that services will always go wrong. In the design of microservices, there is an automatic mechanism that can quickly detect the failures of the services they depend on, and isolate them when they continue to go wrong. Reconnect when service is restored. Therefore, facilities such as "circuit breakers" are not optional peripheral components for microservices in the actual production environment, but a necessary support point. If there is no fault-tolerant design, the system will easily be damaged due to one or two The avalanche effect brought about by the collapse of a service is overwhelmed. It is entirely possible for a reliable system to consist of services that can fail. This is where the greatest value of microservices lies, and this is the meaning of the title of this open source document "The Fenix Project".
- Evolutionary Design . Fault-tolerant design recognizes that services will fail, and evolutionary design recognizes that services will be obsolete. A well-designed service should be able to be scrapped, not expected to live forever. If there are unchangeable and irreplaceable services in the system, this does not mean how excellent and important the service is, but rather a sign of the fragility of the system design. The independence and autonomy pursued by microservices is also against manifestation of this vulnerability.
- Infrastructure Automation . Infrastructure automation, such as the rapid development of CI/CD, has significantly reduced the complexity of construction, release, and operation and maintenance work. Because the objects of operation and maintenance under microservices have an order of magnitude increase compared with the single architecture, teams using microservices are more dependent on the automation of infrastructure, and it is difficult for humans to support hundreds, thousands, or even tens of thousands of services. .
Microservices are very small services, so small that a service only corresponds to a single function and does only one thing. This service can be deployed and run independently, and the services can interact with each other through rpc . Each microservice is developed, tested, deployed, and launched by an independent small team, responsible for its entire life cycle
Distributed services are distributed and deployed on different machines. A service may be responsible for several functions. It is an SOA-oriented architecture. Services also interact through rpc or webservice.
Each module of a distributed system interacts with data through interfaces. In fact, distributed is also a kind of microservice, because it splits modules into independent units and provides interfaces to call
Therefore, we will find that there are many similarities between distributed and microservices, but they are not identical. There are still some differences between them
1. Compared with distributed services, microservices have smaller granularity and lower coupling between services. Since each microservice is in charge of an independent small team, it has higher agility. Distributed services are finally Will evolve to microservice architecture
2. The essential difference between microservices and distributed
The essential difference between microservices and distributed structures is reflected in the "target"
The subtle difference between microservices and distributed is that the application of microservices is not necessarily scattered on multiple servers, but can also be the same server.
Distributed belongs to microservices, and the module is split into an independent service unit to realize data interaction through the interface.
The architecture of distributed and microservices is very similar, but the way of deployment is different.
Distributed architecture is to solve: a large number of user visits can not be afforded by one machine, or because of cost issues, multiple machines have to be used to complete the deployment of services
The microservice structure design is to not affect the existing system business due to the upgrade and BUG of a certain module; it just separates each module and will not be affected by each other, such as module upgrades or BUG or refactoring, etc. Do not affect other modules, microservices can be deployed on one machine
Microservices focus on decoupling so that each module is independent. Distributed focuses on resource sharing and speeding up computer computing
Distributed is also a kind of microservice, and microservice is also distributed
二、SpringCloud
Microservice is a project architecture method and architecture concept; then Spring Cloud is the technical realization of this architecture method
SpringCLoud official website: Spring Cloud
The following is quoted from the official website
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
Features
Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.
Distributed/versioned configuration
Service registration and discovery
Routing
Service-to-service calls
Load balancing
Circuit Breakers
Global locks
Leadership election and cluster state
Distributed messaging
The translation is as follows:
Spring Cloud provides developers with tools to quickly build some common patterns in distributed systems and solve some common problems (such as configuration management, service discovery, circuit breakers, intelligent routing, micro-agents, control buses, one-time tokens , global locks, leader elections, distributed sessions, cluster state). The coordination of distributed systems leads to a lot of boilerplate code (a lot of code with fixed routines), and using Spring Cloud developers can quickly build services and applications that implement these patterns. They work well in any distributed environment, including developers' own laptops, bare-metal data centers, and hosting platforms such as cloud computing;
Spring Cloud characteristics
Spring Cloud provides good out-of-the-box functions for typical application scenarios of distributed system development, such as:
Distributed/versioned configuration
Service Registration and Discovery
routing
Calls between services
load balancing
breaker
global lock
Leader election and cluster state
distributed messaging
SpringCloud main project
Spring Cloud Config
Spring Cloud Netflix
Spring Cloud Bus
Spring Cloud Cloudfoundry
Spring Cloud Open Service Broker
Spring Cloud Cluster
Spring Cloud Consul
Spring Cloud Security
Spring Cloud Sleuth
Spring Cloud Data Flow
Spring Cloud Stream
Spring Cloud Stream App Starters
Spring Cloud Task
Spring Cloud Task App Starters
Spring Cloud Zookeeper
Spring Cloud AWS
Spring Cloud Connectors
Spring Cloud Starters
Spring Cloud CLI
Spring Cloud Contract
Spring Cloud Gateway
Spring Cloud OpenFeign
Spring Cloud Pipelines
Spring Cloud Function
Spring Cloud is a one-stop solution based on the distributed microservice architecture developed on SpringBoot, including service registration and discovery, configuration center, service gateway, load balancing, fuse, full link monitoring, etc. Spring Cloud is called building distributed microservices
. The "family bucket" of the service system is not a certain technology, but an ordered collection of a series of microservice solutions or frameworks. It integrates mature and proven microservice frameworks on the market, and repackages them through the idea of Spring Boot, shielding and adjusting the complex configuration and implementation principles, and finally provides developers with a set of simple, easy-to-understand and easy-to-deploy And an easy-to-maintain distributed system development kit.
The version released by Spring Cloud is an alphabetical name of the London subway station ("Angel" is the first version, "Brixton" is the second), the alphabetical order is from AZ, the latest stable version 2021.0 .x aka Jubilee, when some sub-projects in Spring Cloud have critical bugs or major updates, the release sequence will launch a version whose name ends with ".SRX", where "X" is a number, such as: Greenwich SR1, Greenwich SR2, Greenwich SR3
1. Common components of Spring Cloud
Spring Cloud itself is not an out-of-the-box framework. It is a set of microservice specifications with two generations of implementation.
(1) Spring Cloud Netflix is the first generation implementation of Spring Cloud, mainly composed of Eureka, Ribbon, Feign, Hystrix and other components.
(2) Spring Cloud Alibaba is the second generation implementation of Spring Cloud, mainly composed of Nacos, Sentinel, Seata and other components.
Spring Cloud (specifically Spring Cloud Netflix) contains nearly 20 sub-projects such as spring-cloud-config and spring-cloud-bus, providing service governance, service gateway, intelligent routing, load balancing, circuit breaker, monitoring tracking, distribution solutions in the fields of message queuing and configuration management.
Netflix is an online video website in the United States. It is recognized as an outstanding practitioner of large-scale production-level microservices and a leader in the microservices industry. Netflix's open source components have been proven in production for many years in its large-scale distributed microservice environment, and are mature and reliable.
Spring Cloud integrates the open source service components in Netflix (such as Eureka, Ribbon, Feign, and Hystrix, etc.) into the Spring Cloud Netflix module. The integrated components are called Spring Cloud Netflix XX, so the first generation SpringCloud implementation is also called Spring Cloud Netflix
Subsequent distinctions will be made between Spring Cloud Netflix and Spring Cloud Alibaba
Common components of Spring Cloud (especially Spring Cloud Netflix ) are shown in the table below
| Spring Cloud components | describe |
|---|---|
| Spring Cloud Netflix Eureka | The service governance component in Spring Cloud Netflix includes the implementation of service registry, service registration and discovery mechanism. |
| Spring Cloud Netflix Ribbon | Service invocation and client load balancing components in Spring Cloud Netflix. |
| Spring Cloud Netflix Hystrix | Known as "Brother Porcupine", the fault-tolerant management component of Spring Cloud Netflix provides strong fault tolerance for delays and failures in the service. |
| Spring Cloud Netflix Feign | A declarative service call component based on Ribbon and Hystrix. |
| Spring Cloud Netflix Zuul | The gateway component in Spring Cloud Netflix provides functions such as intelligent routing and access filtering. |
| Spring Cloud Gateway | A gateway framework developed based on technologies such as Spring 5.0, Spring Boot 2.0, and Project Reactor. It uses the Filter chain to provide the basic functions of the gateway, such as security, monitoring/indicators, and current limiting. |
| Spring Cloud Config | Spring Cloud's configuration management tool supports the use of Git to store configuration content, realizes external storage of application configuration, and supports operations such as refreshing, encrypting, and decrypting configuration on the client side. |
| Spring Cloud Bus | The event and message bus of Spring Cloud is mainly used to propagate events or state changes in the cluster to trigger subsequent processing, such as dynamic refresh configuration. |
| Spring Cloud Stream | The message middleware component of Spring Cloud integrates message middleware such as Apache Kafka and RabbitMQ, and perfectly realizes the isolation between the application and the message middleware by defining the binder as the middle layer. By exposing a unified Channel channel to the application, the application can easily send and receive messages without having to consider various message middleware implementations. |
| Spring Cloud Sleuth | Spring Cloud distributed link tracking component can perfectly integrate Twitter's Zipkin. |
2. Association between Spring Cloud and Spring Boot
SpringBoot focuses on the rapid and convenient development of individual microservices.
SpringCloud is a microservice coordination and governance framework that focuses on the overall situation. It integrates and manages individual microservices developed by SpringBoot, and provides: configuration management, service discovery, circuit breakers, routing, micro-agents, Integrated services such as event bus, global lock, decision-making campaign, distributed session, etc.
SpringBoot focuses on the rapid and convenient development of individual microservices, while SpringCloud focuses on the global service governance framework
Spring Boot can directly create projects or modules that can run independently without Spring Cloud
Spring Cloud is implemented based on Spring Boot. It cannot create projects or modules independently, let alone run independently from Spring Boot.
The corresponding relationship between Spring Cloud and Spring Boot compatible versions is as follows (refer to Spring Cloud official website )
3. Architecture diagram of Spring Cloud Netflix
Service Provider: The service provider that exposes the service
Service Consumer: The service consumer who calls the remote service.
EureKa Server: Service Registry and Service Discovery Center
reference article
[Java] Summary of Service Architecture Evolution -- Read "The Fenix Project" - herrhu - 博客园
Phoenix Architecture: Building a reliable large-scale distributed system | Phoenix Architecture