table of Contents
Advantages and disadvantages of microservices
Microservices technology stack
Some common misunderstandings about the principle of CAP
The relationship between spring cloud and spring boot
The difference between spring cloud and dubbo
Microservices
The core of microservices is to split the traditional one-stop application into services one by one according to the business, and thoroughly decouple them. Each microservice provides a service with a single business function, and one service does one thing , from a technical perspective. It is a small and independent process, similar to the concept of a process, which can be started or destroyed independently and has its own independent database.
Advantages and disadvantages of microservices
Let ’s take a look at what microservices can bring us? Features of microservice architecture:
For specific service release, the impact is small, the risk is small, and the cost is low
Frequently release versions to quickly deliver requirements
Low-cost expansion, elastic expansion, adapt to cloud environment
We know a simple concept. Nothing is perfect. Anything has two sides, and there must be some losses. So when choosing microservices solves the problems of rapid response and elastic scaling, it brings us what is the problem?
The complexity of distributed systems
The cost of deployment, testing and monitoring
Issues related to distributed transactions and CAP
The application of the system has changed from a single unit to dozens to hundreds of different projects. Problems such as dependencies between services, how to unpack services, internal interface specifications, data transfer, etc., especially service splitting, are required. The team is familiar with the business process and knows the trade-offs. To ensure that the granular service of the split meets the basic principle of "high cohesion and low coupling", it must also take into account the business development and the company's vision. And actively invest in achieving a balance among multiple parties.
For distributed systems, deployment, testing and monitoring require a lot of middleware to support, and the middleware itself also needs to be maintained. The original simple application of single transaction issues, it becomes very complicated to move to a distributed environment . Whether the transaction is resolved using a simple retry + compensation mechanism or a strong consistency method such as a two-phase commit protocol depends on familiarity with the business scenario and repeated trade-offs. The same problem also includes trade-offs on the CAP model. In short, microservices have higher requirements on the overall technical stack level of the team
Microservices technology stack
| Microservice entry | Floor technology |
| Service development | Springboot、Spring、SpringMVC |
| Service configuration and management | Netflix's Archaius, Ali's Diamond, etc. |
| Service registration and discovery | Eureka、Consul、Zookeeper等 |
| Service call | Rest、RPC、gRPC |
| Service fuse | Hystrix、Envoy等 |
| Load balancing | Ribbon、Nginx等 |
| Service interface call (simplified tool for client to call service) | Feign et al |
| message queue | Kafka、RabbitMQ、ActiveMQ等 |
| Service Configuration Center Management | SpringCloudConfig、Chef等 |
| Service routing (API gateway) | Zuul et al |
| Service monitoring | Zabbix、Nagios、Metrics、Spectator等 |
| Full link tracking | Zipkin，Brave、Dapper等 |
| Service deployment | Docker、OpenStack、Kubernetes等 |
| Data flow operation development kit | SpringCloud Stream (encapsulation and Redis, Rabbit, Kafka, etc. send and receive messages) |
| Event message bus | Spring Cloud Bus |
CAP principle
First briefly introduce what is the principle of CAP:
C：Consistency
Strong consistency, the data obtained by accessing all nodes should be the same. Note that the consistency here refers to strong consistency, that is, after the data is updated, the data seen by accessing any node is completely consistent, and it must be distinguished from weak consistency and eventual consistency.
A：Availability
Availability, all nodes maintain high availability. Note that high availability here also includes that no delays can occur. For example, if Node B blocks requests because of waiting for data synchronization, then Node B does not meet high availability.
In other words, any service that has not failed must return a reasonable result set within a limited time.
P：Partiton tolerence
Partition tolerance, here refers to the partition in the sense of the network. Because the network is unreliable, it is likely that there will be no communication between all nodes. When the nodes cannot communicate, it is necessary to ensure that the system can continue normal service.
In terms of actual effect, the partition is equivalent to the time limit of communication. If the system cannot achieve data consistency within the time limit, it means that a partition has occurred, and you must choose between C and A for the current operation.
The CAP principle says that a data distributed system cannot satisfy the three conditions of C and A and P at the same time. Therefore, when designing a system, the system architect should not waste energy on how to design a perfect distributed system that satisfies the three, but should make a choice. Due to the unreliable nature of the network, most open source distributed systems will implement P, that is, partition tolerance, and then choose between C and A.
Some common misunderstandings about the principle of CAP
I saw many articles on the Internet that said that the CAP principle is the cornerstone of a distributed system , but the CAP principle is actually a conclusion to a distributed data storage system . We assume that each node of a distributed system reads and writes the same mysql instance, so for this distributed system, it is meaningless to discuss the CAP principle. Because each node can communicate without data replication, it meets partition tolerance (P), can respond to requests at any time, and meets availability (A). At the same time, because it is accessing a database instance, it has already guaranteed data consistency C).
Therefore, when discussing the principle of CAP, it is more aimed at those distributed storage systems with data storage and data replication scenarios, that is, the familiar NoSql database.
Since most of us will not design a new NoSql database to use, more is to use the existing NoSql open source system for data storage, such as Hbase, MongoDB, Cassandra, etc. So most of the time, we actually do n’t use the CAP principle.
Regarding the principle of CAP, one thing that needs special attention is that although we design the system, we cannot guarantee to have three points at the same time. But it does not mean that after guaranteeing two of them, the other point will be completely abandoned. It's just a relative sacrifice . For example, in the case of ensuring CP, although there is no way to ensure high availability, this does not mean that the availability is 0. We can increase the availability as much as possible through reasonable design, so that the availability is as close to 100% as possible. Similarly, in the case of AP, you can also try to ensure data consistency, or achieve weak consistency, that is, final consistency.
Spring Cloud
SpringCloud = a one-stop solution under the distributed microservice architecture, which is a collection of landing technologies of various microservice architectures, commonly known as the microservice family bucket
SpringCloud, based on SpringBoot, provides a set of microservice solutions, including service registration and discovery, configuration center, full link monitoring, service gateway, load balancing, fuse and other components, in addition to highly abstract packaging based on NetFlix open source components There are also some open source components that are neutral in selection.
SpringCloud uses SpringBoot's development convenience to subtly simplify the development of distributed system infrastructure. SpringCloud provides developers with some tools for quickly building distributed systems, including configuration management, service discovery, circuit breakers, routing, micro-agents, and events Buses, global locks, decision campaigns, distributed sessions, etc., can all be started and deployed with one click using the SpringBoot development style.
SpringBoot does not repeat the manufacturing of wheels. It just combines the more mature and practical service frameworks developed by various companies. Re-encapsulation through SpringBoot style shields the complex configuration and implementation principles, and finally gives developers A set of distributed system development toolkits that are easy to understand, easy to deploy, and easy to maintain is set aside.
The relationship between spring cloud and spring boot
SpringBoot focuses on the development of single individual microservices quickly and easily.
SpringCloud is a global microservice coordination and governance framework that integrates and manages
individual microservices developed by SpringBoot to provide various microservices , configuration management, service discovery, circuit breakers, routing, micro proxy, Integrated services such as event bus, global lock, decision campaign, distributed session, etc.
SpringBoot can leave SpringCloud to use development projects independently, but SpringCloud is inseparable from SpringBoot, which belongs to the dependency relationship.
SpringBoot focuses on the rapid and convenient development of a single microservice individual, and SpringCloud focuses on the global service governance framework.
The difference between spring cloud and dubbo
The biggest difference: Spring Cloud abandoned Dubbo's RPC communication and used HTTP-based REST.
Strictly speaking, these two methods have their own advantages and disadvantages. Although the latter sacrifices the performance of service calls to a certain extent, it also avoids the problems caused by the native RPC mentioned above. And REST is more flexible than RPC. The service provider and the caller rely on a single contract, and there is no strong dependency at the code level. This is more appropriate in a microservice environment that emphasizes rapid evolution.
Dubbo and Spring Cloud are not completely competitive, and the problem domains they solve are different: Dubbo's positioning is always an RPC framework, and Spring Cloud's purpose is a one-stop solution under the microservice architecture.
For comparison, Dubbo can be compared to the Netflix OSS technology stack, and Spring Cloud integrates Netflix OSS as a distributed service management solution, but in addition Spring Cloud also provides distributed including config, stream, security, sleuth, etc. Service solutions.
At present, due to problems such as RPC protocol and registry metadata mismatch, Dubbo and Spring Cloud can only choose one of two when faced with the selection of microservice basic framework, which is why they are always compared.
After Dubbo will actively seek to adapt to the Spring Cloud ecosystem, such as the use of SpringCloud's binary communication solution to take advantage of Dubbo's performance advantages, or Dubbo adapts to Spring Cloud through modularization and http support
The difference between brand machine and assembly machine
Obviously, the function of Spring Cloud is more powerful than DUBBO and covers a wider range, and as a fist project of Spring, it can also be perfectly integrated with other Spring projects such as Spring Framework, Spring Boot, Spring Data, Spring Batch, etc. These are for microservices Is crucial. The microservice architecture built with Dubbo is like assembling a computer. We have a high degree of freedom in the choice of each link, but the final result is likely to be not bright because of the quality of a memory. Being a master, these are not problems; and Spring Cloud is like a brand machine. Under the integration of Spring Source, a lot of compatibility tests have been done to ensure that the machine has higher stability, but if you want to use non- For things outside the original components, you need to have a sufficient understanding of their basics.
Community support and update efforts
Most importantly, DUBBO has stopped updating for about 5 years, although it was restarted in 2017.7. New requirements for technological development need to be expanded and upgraded by the developers themselves (for example, DubboX has made DubboX). This is obviously not suitable for many small and medium-sized software organizations that want to adopt a microservice architecture. Small and medium companies are not so powerful The technical ability to modify the Dubbo source code + a complete set of solutions around, not every company has Ali Daniel + real online production environment tested.
