With the advancement of digital informatization, the dependence on systems and platforms is getting higher and higher, especially for important business systems. Stable and continuous service capabilities are particularly important, which is what we often call high availability. Generally, there are master-slave, master-slave, multi-master, same-city disaster recovery, same-city multi-active, remote disaster recovery, remote multi-active and other architecture designs. Remote multi-active is an advanced practice of high availability.
1. Overview of multi-active architecture
High availability of software systems has always been a function that must be considered in architecture design, but at different nodes in the software life cycle, different architectures are adopted, such as:
-
At the beginning of the project, we may only be in the active-standby mode of the database. When an error occurs in the main database, we can restore the standby database in time and continue to use it. However, the active-standby mode is generally not timely, and some data will be lost. Projects with strict data integrity requirements generally do not use this method.
-
In the middle stage of project development, master-slave and high-availability modes can be adopted. This mode is generally near real-time synchronization. In the event of an accident, we can switch in time and seamlessly switch to provide services without interruption. At the same time, business services should also consider high availability during this period.
-
In the stable period of the project, after the project and platform are mature and stable, high availability should be the top priority. Multiple IDCs in the same city can be considered. Multiple IDCs in the same city are basically enough to support most unexpected situations, and the network delay in the same city will not fluctuate too much. However, this solution is very difficult to implement, and there are many factors to consider. Therefore, a gradual and iterative approach is generally adopted to finally realize multi-site multi-activity on the entire platform.
2. Three important indicators of software architecture
In software architecture design, three aspects are mainly considered for whether the architecture design is good or bad and whether it can withstand the impact brought by the rapid development of business
-
High performance, high performance mainly manifested as TPS and QPS, the more processed per unit time, the better the performance, mainly related to business logic code implementation, communication protocol, database and basic resources
-
Easy to expand, which is reflected in the difficulty of version iteration, function expansion, middleware replacement and system docking. It is mainly related to the understanding of business and scalability in the architecture planning stage. A sufficiently flexible interface is reserved to minimize the coupling between modules and systems. The general docking protocol and data structure are used to make sufficient preparations for expansion.
-
High availability, high availability is an indicator with the lowest sense of existence, because under normal circumstances, it is often ignored. High availability is the ability to continue services. Try not to affect the normal use of the platform due to external factors, which is very important for important business systems.
The common implementation methods of high availability include master-slave, master-slave, multi-active in the same city, multi-active in different places, etc., but the difficulty gradually increases, and the high availability provided is also gradually improved.
3. Multi-active design in different places
In our architecture design, multi-active mainly involves the application, service, and storage layers, and multi-active in different places is basically the multi-active of these three levels.
-
It is not complicated to implement multi-active on the application side at present. When deploying, you only need to maintain multi-center deployment at the same time, as long as you maintain the consistency of the application-side files in multiple places. Generally, there is no big problem.
-
The service layer is more active, which is a bit troublesome, and needs to be adjusted according to the capabilities provided by the storage layer.
-
The master-slave mode of the storage layer. In this way, the service layer needs to process CUD for routing to the master node. At the same time, the master node performs real-time synchronization to the slave node. If the R operation is performed, the local storage layer operation is performed directly. Generally, this method considers the use of middleware for transfer and data proofreading, which is what we often call the final consistency. If the business requires strict data consistency, 2PC and 3PC methods can be used.
-
The storage layer is a master-master mode. For example, MySql has a master-master mode. The service layer can directly perform local operations, and there is storage to synchronize data between the two places.
-
Through the middleware method, if the storage does not have its own multi-data center synchronization mechanism, it needs to be realized through the development of middleware, such as the common Redis multi-center synchronization tool XRedis, and the MongoDB cross-computer room replica set synchronization tool MongoShake. The service layer generally only needs a small amount of adaptation.
-
-
The storage layer is a key point to consider in the implementation of remote multi-active, because the application layer and service layer are basically stateless, which is relatively easy to implement, but storage is stateful. In remote multi-active, special processing is often required. If there is no multi-center synchronization mechanism function, it needs to be developed to achieve it. At the same time, the network delay caused by remote and cross-center affects performance.
Four. Summary
Multi-active in different places is a difficult point in architecture design, but it is also a very important part. It is best to take this into consideration in the early stage of architecture design, and consider multi-active in different places in technology selection and scheme design in advance, so that it can be easily implemented when needed. But despite this, it is not easy to achieve multi-active in different places. It belongs to the relatively advanced stage of architecture design, and there are not many general solutions, most of which are designed according to specific business needs.
If you have any questions about living in different places, please leave a message or private message to communicate.