1. Identify the seam (bounded context)
A monolithic system does not have the characteristics of high cohesion and low coupling, so the first step of decomposition needs to be very cautious. The first step is to identify the location of the seam. We can extract a relatively independent part of the code from the seam and modify this part Does not affect other parts of the system, and can clean up the code base and become the boundary of the service.
Many programming languages have the concept of namespaces, which help us organize similar codes together. For example, Python/Java/Go have the concept of package. When we recognize the bounded context, we can maintain them separately through pkg.
2. More efficient decomposition
If you want to decompose a larger monolithic system, you need to do some prioritization of the decomposed code.
- If the next development task is for the inventory system, then the next step is to extract the inventory seam as a service and make it an autonomous unit, which will greatly speed up the later development speed
- Team structure, if a system is maintained by different teams, it is a good practice to prioritize independent services by team, so that a single team can take full responsibility for their code base
- In terms of security, if a certain system will implement security audits and transmission data protection measures for financial-related interfaces, if this service is separated, it can be better monitored, transmitted data protection, and static data protection, etc.
- In terms of technology, if the recommender system team develops a new algorithm (in another language), if this part of the code can be separated, it will be easy to refactor and test when there is a problem
3. Share static data
If the system wants to use the country list data, there are several ways to share it in the microservice architecture:
- Data is written to a table in the database, and all services read this table directly
- Put the data into a static file in a separate service, and other services call the interface provided by this service to read
The first method is inconvenient when modifying. The second method is more reasonable in my opinion. It only needs to modify the static file of a service when updating. Because the service code is not updated, other services do not need to update the pkg information. .
Here you may have doubts about the specific method of updating the static file. This is how we put the static file in the /static directory and name it countries_202006270920.txt. The number behind it is the change time. When updating, we will have The file with the latest change time is placed in the /static directory, and the service reads the latest file when reading.
4. Try not to share tables
Usually our multiple services will need to read a user's information, such as whether he is a member, whether to log out, etc. The best thing to do is to serve an independent user, and other services call the interface provided by this service to work, so as to be better Do resource isolation and practice the principle of single responsibility.
5. Refactor the database
In this step, we are going to implement separation, so what do you think is to directly turn the monolithic system into two services in a certain release? And they have their own database tables?
In fact, I would recommend that you first separate the database structure and not separate the services for now.
After the table is separated, the number of visits to the database may increase for an original action, because in the past only one SELECT was needed to get all the data, but now it is necessary to get the data from different places and store them in memory connect. Also, splitting into two table structures can break transactional integrity, which can have a significant impact on applications, which will be discussed later. The advantage of detaching the database structure first without detaching the service is that you can choose to roll back these changes or continue doing so at any time without affecting any consumers of the service. Once we are satisfied with the database separation, we can consider splitting the entire service.
6. Data consistency under microservices
Unfortunately, I have not seen the author put forward a more feasible solution for this part. The book describes two methods:
- Compensation transactions or operations are retrying immediately or periodically checking and eliminating inconsistencies in the database through scheduled tasks, but compensation transactions still have the possibility of failure, and there are two, three or even more operations that need to be synchronized Timed tasks are very difficult to understand, and may be a nightmare for later maintenance.
- Distributed transactions, which require a centralized transaction manager tool to uniformly orchestrate transactions running in the system. One of the algorithms mentioned by the author is two-phase commit, and also mentioned many shortcomings of this algorithm, such as the transaction manager has a single point of failure, and the commit after the vote may fail, etc.
On this topic, I think we need to continue to explore.