overview
Now the most talked about are microservices and middle-end systems. My personal understanding is whether micro-services or middle-end systems are good or not. It mainly depends on the actual business scenario. Architecture changes often require a lot of learning costs and time costs, so When changing the structure, think twice, it is especially important to suit yourself.
Evolution from monolithic to multi-application
Since I joined the company, the company has moved from a single unit to a vertical split, such as single-database query, Redis, Es, and MongoDB have been widely used in the system, and some problems of calling confusion have been encountered in the middle. We added in the previous MVC Created a service layer and made a data aggregation layer, and it has been running well for a long time. The peak request is about one million, and it will be a little more during the winter and summer vacations.
Before starting microservices, I actually had my own plan in mind. The team is relatively small. In fact, there is no need to split microservices. If you have to split and replace yaf with Swoole mode on the original basis, you can get the balance between performance and cost. In fact, it is a little regrettable that it has not been adopted. It is a problem that cannot be solved without the right to speak in the team.
Let me say one more thing here. Microservices do not solve the problem of high concurrency. Microservices are an architectural idea. In the process of understanding microservices, many detours have been taken. There are many microservices implemented in Java on the Internet, Go language , Rust, and even python. In fact, purely from the language level, the performance of the language is shrinking. Technicians must have their own thinking and cannot follow the trend numbly.
Problems encountered in splitting microservices
I won't talk about microservices, but write about the elements of design and the pitfalls that must be encountered here.
For example, our business is a reading app, the core of which is the work, but the details page of the work will focus on displaying the data information required by comments, users, and chapters. Before that, it was the same Service layer. This is the first question that needs to be considered.
Split granularity: The most difficult point of splitting microservices is how to grasp the granularity between services and services. This is difficult to grasp. If the split is large, just change the name, change the soup without changing the medicine, and split it small Aggregating data will be problematic again, and the process in the middle is really driving people crazy.
Let me talk about the problems I encountered at that time. The days of splitting were really crazy:
1. If the service division is too fine, the service relationship is complex, and the service division is too fine, the individual complexity will decrease, but the complexity of the whole system will rise, because microservices transfer the complexity within the system to the complexity between systems.
2. There are too many services, and the efficiency of the team drops sharply. The misunderstanding here is that Weizi means that the split is very fine.
3. There is no automatic support, and it is impossible to read and deliver quickly. Now there is GitOps in geek time, you can read this, it is well written.
4. There is no service governance, the number of micro-services reaches a certain level, and the background management is chaotic.
5. Things that were handled by one SQL in the past now need to be obtained from multiple services, which increases the difficulty of development to a certain extent.
Sorting out the method of splitting microservices
I sorted out some methodologies for splitting microservices from the Internet, hoping to have some reference value for you:
1. Vertical split and horizontal split
- For splitting from the business dimension, the standard is determined according to the degree of business association. Businesses that are closely related are suitable for splitting into a microservice, while businesses with relatively independent functions are suitable for splitting into a microservice.
- Split from the public and independent function dimension, the standard is whether there are public ones that are called by multiple other services, and the dependent resources are independent and not coupled with other businesses.
2. Splitting microservices or comprehensive considerations
- Business logic
- Infrastructure construction (automated testing, automated deployment, service monitoring, service discovery, configuration center, etc.), often determines the success or failure of infrastructure construction, which has nothing to do with business.
- Divide the modules in the system according to their stability, and classify those that have matured and those that have not changed much as stable services.
3. According to the division of business granularity, there are two possibilities.
- Divide by coarse granularity: works, users, comments, messages
- According to the fine-grained level: works, users, audio, comments, dynamics, customer service IM, comprehensive, etc., there are many, many.
split principle
Three musketeers principle: a microservice is developed by three people, and it is reasonable to divide the number according to the team size when implementing microservice architecture.
AFK split principle:
- X-axis, horizontal replication, loading several more application instances, and splitting in the mode of cluster plus load balancing
- Y axis, microservices are often divided by business logic
- Z axis, divided according to data
Conway's law
- The first law: Organizational communication methods will be expressed through system design. The Myth of the Man-Month summarizes the rule that communication costs increase exponentially with the increase of personnel. Communication costs
n(n-1)/2 - The Second Law: No matter how much time you have, it is impossible to do one thing perfectly, but there is always time to finish one thing.
- The third law: There are potential heterogeneity and homomorphism between the linear system and the linear organizational structure
- The Fourth Law: Larger systems are always organized more prone to decomposition than smaller ones
Other principles:
- Communication between people is very complicated, and one person's communication energy is limited, so when the problem is too complicated and needs to be solved by many people, we need to split it to achieve communication efficiency management.
- The way people communicate with each other in the organization determines the system design they participate in. Managers can bring different ways of communication between teams through different split methods, thus affecting system design
- If the subsystem is cohesive and the communication boundary with the outside is clear, the communication cost can be reduced, and the corresponding design will be more reasonable and efficient
- Complex systems need to be continuously optimized in a fault-tolerant and flexible manner. Don't expect a large and comprehensive design or architecture. Good architecture and design are slowly iterated.