With microservices in full swing, more and more projects have begun to try to transform into microservice architecture. Microservices not only bring convenience to project development, but also increase the difficulty of operation and maintenance and the probability of network unreliability.
When talking about the advantages and disadvantages of microservices, the comparison will be more obvious. First, let’s talk about the monolithic structure.
Monolithic architecture
In a monolithic architecture, the system usually adopts a layered architecture model (MVC), a persistence layer, a presentation layer, and a business logic layer. The architecture mainly has the following problems:
- The internal system accesses each other, and the tight coupling makes it difficult to maintain;
- Each business area needs to adopt the same technology stack, and it is difficult to quickly apply new technologies (for example, it is difficult to transform to SSM using SSH);
- Any modification to the system must be redeployed/upgraded together with the entire system;
- When the system load increases, it is difficult to scale horizontally;
- When a problem occurs in one part of the system, it will affect the entire system;
In order to overcome the above shortcomings, the microservice architecture came into being. Microservices, also known as microservice architecture. Microservices are small and autonomous services that work together.
Microservice architecture
advantage:
1. Technical heterogeneity
In different services, different technologies can be used to develop separately, as long as the services can cooperate with each other.
2. Flexibility
When a certain service in the microservice is unavailable, it will not affect the entire system, but will only affect the unavailability of related functions
3. Expansion
Easy to expand, use small multiple services, easier to expand new functions
4. Simplify deployment
Update deployment of a service without redeploying the entire application
5. Can be combined
By combining multiple services, some new functions can be provided
6. Alternative
Because each microservice is relatively small, it is feasible to re-implement a certain service or directly delete the service
Disadvantages:
1. High complexity
Microservices interact through REST, RPC and other forms. Compared with the monolithic mode, various abnormal situations such as callee failure, overload, and message loss need to be considered, and the code logic is more complicated.
For transactional operations between microservices, because different microservices use different databases, it will not be possible to use the transaction mechanism of the database itself to ensure consistency. It is necessary to introduce technologies such as two-phase commit.
At the same time, when there are a small number of shared functions between microservices but cannot be extracted into microservices, each microservice usually needs to re-develop this part of the function, or at least copy code to avoid coupling between microservices and increase development. cost.
2. Complex operation and maintenance
When adopting the microservice architecture, the system is composed of multiple independently operating microservices, and a well-designed monitoring system is required to monitor the running status of each microservice. Operation and maintenance personnel need to have a detailed understanding of the system to have a better operation and maintenance system.
3. Affect performance
Compared with the monolithic architecture, microservices interact through REST, RPC and other forms, and the communication delay will be greatly affected.
Introduction of distributed transactions
As said above
For transactional operations between microservices, because different microservices use different databases, it will not be possible to use the transaction mechanism of the database itself to ensure consistency. It is necessary to introduce technologies such as two-phase commit.
In a single project, it is easy to achieve transaction control, but difficult to achieve between multiple services
Assume that the service call is as follows:
ABCD's affairs are controlled by each service. How to do it, coordinate and ensure data consistency?
Distributed transaction solution
Two-phase commit based on XA protocol
XA is a distributed transaction protocol, proposed by. XA is roughly divided into two parts: transaction manager and local resource manager. Among them, local resource managers are often implemented by databases. For example, commercial databases such as Oracle and DB2 implement the XA interface. As the global scheduler, the transaction manager is responsible for the submission and rollback of various local resources. The principle of XA to implement distributed transactions is as follows:
Phase 1:
second stage:
In general, the XA protocol is relatively simple, and once the commercial database implements the XA protocol, the cost of using distributed transactions is also relatively low. However, XA also has a fatal shortcoming, that is, the performance is not ideal, especially in the transaction order link, often the amount of concurrency is very high, XA can not meet the high concurrency scenarios. XA is currently supported in commercial databases rather than ideally supported in mysql database. The XA implementation of mysql does not record prepare phase logs. Switching back to main and standby causes data inconsistency between the main database and the standby database. Many nosql does not support XA, which makes the application scenarios of XA very narrow.
Message transaction + final consistency
The so-called message transaction is based on the two-phase commit of the message middleware. It is essentially a special use of the message middleware. It puts local transactions and message sending in a distributed transaction to ensure that either the local operation succeeds successfully. And the external message is successful, or both fail, the open source RocketMQ supports this feature.
This scheme adopts the final consistency, at the expense of consistency, in exchange for a substantial improvement in performance. There is a risk of data inconsistency
TCC programming mode
The so-called TCC programming model is also a variant of the two-phase submission. TCC provides a programming framework that divides the entire business logic into three parts: Try, Confirm and Cancel three operations. Taking online order as an example, the inventory will be deducted in the Try phase, and the order status will be updated in the Confirm phase. If the order update fails, it will enter the Cancel phase and the inventory will be restored. In short, TCC implements two-stage submission through code artificially. The code written in different business scenarios is different, and the complexity is also different. Therefore, this mode cannot be reused well.
Implementation
LCN
The core function of the LCN distributed transaction framework is the coordination and control of local transactions. The framework itself does not create transactions, but only coordinates and controls local transactions. Therefore, the framework has strong compatibility with other third-party frameworks, supports all relational database transactions, supports multiple data sources, supports use with third-party database frameworks (such as sharding-jdbc), and only needs to add distribution when using the framework The comment of the type transaction is sufficient, and the intrusion to the business is low. The LCN framework is mainly to provide distributed transaction support for the microservice framework, and further transaction mechanism optimizations have been made on the microservice framework. In some load scenarios, the LCN transaction mechanism has better performance than the local transaction mechanism. The framework is opened after 4.0 The Fanglai plug-in mechanism allows more third-party frameworks to come in.
Currently LCN is version 4.1
main feature:
- Support various spring-based db frameworks
- Compatible with SpringCloud, Dubbo, motan
- Simple to use, low dependency, and the code is completely open source
- Aspect-based strong consistency transaction framework
- High availability, modules can rely on RPC modules for clustering, and TxManager can also be clustered
- Support the coexistence of local transactions and distributed transactions
- Support transaction compensation mechanism, increase transaction compensation decision reminder
The use of strong consistency scheme, the transaction either all succeed, or all fail, ensuring the consistency of the transaction, the code is simple, just introduced the original project-related jarpackage and method of the transaction requires the participation of add annotations to save The cost of code transformation.
Spring Cloud example:
Add dependency
<properties>
<lcn.last.version>4.1.0</lcn.last.version>
</properties>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>transaction-springcloud</artifactId>
<version>${lcn.last.version}</version>
</dependency>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>tx-plugins-db</artifactId>
<version>${lcn.last.version}</version>
</dependency>
Add a comment on the transaction that needs to be executed
@Override
@TxTransaction(isStart = true)
@Transactional
public int save() {
}
Which @TxTransaction(isStart = true)is lcn transaction control annotation, which isStart = trueindicates that the method is the originator of the transaction, for example, need to call the service A service B, B service need to call the service C, this time for the service A service initiating party, the rest of the participants, participants simply @TxTransactionThat's it.