Article directory
Chapter 1 Microservices
What are microservices? Microservices are small, autonomous services that work together.
main benefit?
technology heterogeneityFor example, for social networks, graph databases can better handle interactions between users, but for user posts, document databases may be a better choice.
Elasticity, for a single-block service system, the probability of complete unavailability of functions can be reduced by running the same instance on a different machine, but the microservice system itself can handle service unavailability and function degradation problems well.
Expansion, a huge single-block service can only be expanded as a whole, even if only a small part of the system has performance problems, the entire service needs to be expanded. If you use smaller multiple services, you can only scale the services that need to be scaled, so that those services that do not need to be scaled can run on smaller, slightly lower-performance hardware.
Simplify deployment, in a monolithic service with millions of lines of code, even if only one line of code is changed, the entire application needs to be redeployed to be able to publish the change. This kind of deployment has great impact and high risk, so I dare not deploy it lightly. Therefore, in the summary of actual operations, the frequency of deployment will become very low, which means that we have made many functional modifications to the software between two releases, and released a large number of changes to the production environment at one time, which has brought One problem, the greater the difference between two releases, the higher the chance of error. In the microservice architecture, the deployment of each service is independent, so that a specific part of the code can be deployed faster, and if something goes wrong, it will only affect one service, and it is easy to roll back quickly, which also means Customers can use the new features we develop faster.
Match the organizational structure, The microservice architecture can well match the architecture with the organizational structure, avoiding an excessively large code base, and thus obtaining the ideal team size and productivity.
**Composability,** In the microservice architecture, people can use the same function in different ways according to different purposes, which is especially important when considering the user's use of the software. The system will open many interfaces for external use. When the situation changes, different methods can be used to build the application, while the overall application can only provide a very coarse-grained interface for external use. If you want to get more useful detailed information, You need a hammer to pry it open!
Optimizing for Substitutability, There are some huge and ugly legacy systems that no one dares to touch, but they are critical to the company's business operations. Why these systems have not been replaced until now, in fact, the answer is very clear to you: a lot of work and high risks. When using multiple small-scale services, it is relatively feasible to reimplement a service or simply delete the service.
Service Oriented Architecture
SOA (Service-Oriented Architecture) is a design method that includes multiple services, and the services will eventually provide a series of functions through cooperation. A service usually exists independently in the operating system process, and the services are called through the network.
Other decomposition techniques
Shared libraries, basically all languages support decomposing the entire codebase into multiple libraries, which is a pretty standard decomposition technique, and these libraries can be provided by third parties or your own organization. Different teams can share functionality in the form of libraries, for example we might create a set of swim set manipulation tools, or a reusable statistics library. But shared libraries also have some disadvantages. First, you cannot choose heterogeneous technologies. Second, you will lose the ability to independently expand a certain part of the system. Third, unless you are using a dynamic link library, every time the library is updated Every now and then, the entire process needs to be redeployed, making it impossible to deploy changes independently.
Modules. Some languages provide their own module decomposition technology. They run and manage the life cycle of modules, so that modules can be deployed to running processes, and a module can be modified without stopping the entire process.
no silver bullet
Microservices are not a free lunch, let alone a silver bullet. To use microservices, you need to face the complexity of distributed systems. You need to do a lot of work in deployment, testing, monitoring, etc., and you also need to consider how to expand the system to ensure them flexibility. Every company, organization and system is different. Whether microservices are suitable, or the extent to which microservices need to be adopted, depends on many factors.
Chapter 2 Evolutionary Architect
Compared with building buildings, in software we will face a large number of requirements changes, and the tools and technologies used are also diverse. What we create doesn't stop changing after a certain point in time, software can continue to evolve even after it's released to production. For most of the products we create, after delivery to the customer, we still have to respond to the customer's changing needs, rather than simply handing the customer an immutable software package. Therefore, architects must change the idea of designing a perfect product from the beginning. Instead, we should design a reasonable framework under which a correct system can slowly evolve. Architects should focus on the big picture like urban planners, and only get involved in very specific details in very limited cases.
Chapter 3 How to Model Services
What kind of service is good service
Loose coupling, if the loose coupling between services is achieved, then modifying one service does not need to modify another service. A loosely coupled service should know as little as possible about the services it is written with. This also means that the number of distinct calls between two services should be limited, because in addition to potential performance issues, excessive communication can lead to tight coupling.
High cohesion, gather related behaviors together, and put unrelated behaviors elsewhere.
upper and lower limits
Bounded context, any given field contains multiple bounded contexts, and the things in each bounded context are divided into two parts, one part does not need to communicate with the outside, and the other part needs it.
Shared hidden models, modules and services, premature division
Business functions
When thinking about Bounded Contexts within an organization, think not in terms of shared data, but in terms of the functionality those contexts can provide.
Gradually divide the context
At first you'll recognize some coarse-grained Bounded Contexts, which may contain nested Bounded Contexts.
Communication about the concept of business
The purpose of modifying the system is to meet the needs of the business. We will modify the customer-oriented functions. If the system is decomposed into a bounded context to represent the domain, then the modification to a function is more likely to be limited to a single within the microservice boundary.