The Evolution of Microservice Architecture
An application under the monolithic mode usually has an app server, which contains different sub-modules, each of which is written in the same application package, and sometimes the boundaries between modules are not particularly clearly designed. , especially if the early code is mixed together, it means calling each other.
This relatively heavy monolithic architecture still ensures high availability of applications through redundant deployment and load balancing.
The monolithic architecture is no longer suitable for complex business needs. We will make some adjustments to the business architecture and replace it with subsystems one by one. These subsystems have independent deployment files and independent life cycles. The requirements for high availability of each subsystem are also different. Subsystems and subsystems complete the entire business through network calls.
The original monolithic system, such a model of single instance and single process, will become hundreds of sub-services to form a unified deployment view.
At this time, go to human flesh to control one by one, then the cost will be very high, and the probability of error will be very high. In this way, it is necessary to rely on automated methods to complete application configuration and service discovery capabilities.
Evolution from Monolithic System to Microservice System
Suppose there is an online store, and the sales have a sales module that provides a portal to sell things. The goods sold in the online store must be stored, and there is a warehouse management system to manage the inventory. There are also demands for billing and discounts. For a single application, it will be provided to the functions of the single application.
Since it is the same process, as long as you tell me the address, I can access all the services.
Evolution of microservice architecture
To split a monolithic application into a microservice architecture, different capabilities in an application process are split into different subsystems, and each subsystem assumes its own responsibilities.
Since sales supports the front-end business, its availability requirements will be higher, and the more concurrent requests it will support, here you can deploy more instances, provide more concurrent load support, and then provide Higher availability.
The network should be opened for each system, including calls between services and services. In order to solve this complex coupling, api gateway can be used. There can be many, many services in the cluster, and these services may be exposed through the same domain name, so an API gateway is needed, which accepts different customer requests and forwards them to different services through the gateway.
Calls between services require a service discovery mechanism, and then a service registry is required. After each service is up, it must register itself, and different renews will say that I am alive. He has to register his own health status, and when other people make service calls, they will know which real servers are running behind this service.
There is a service registration center here. The address information registered by the service center is that if it is registered in a point-to-point manner, the health status of each node must be updated in real time. The other is through centralized load balancing or distributed load balancing, then the virtual IP of the unified entrance will be bound.
Typical microservice business scenarios
There may be a fixed call relationship between warehouse and accounting. The current system architecture is designed for failure. When designing the system, it must be assumed that any component is untrustworthy. There are two possible failures in accounting. Possibly, one is that an error code can be returned, and the other is that it may not respond. If there is no response, many applications are written in the business code and return 50x. If it is suspended animation, then the warehouse does not know that there is a problem with accounting, it will forward the request to accounting and wait for its reply, if the application is not well written and robust enough, then it will wait indefinitely, but it will think that accounting is normal, Because accounting does not return any error messages to it, sales will continue to forward the request.
Then it will cause the warehouse to receive a lot of sales requests, there is no effective way to forward these requests to accounting to get the return value, then the backlog of requests on the warehouse will become more and more, so that the warehouse may also malfunction .
After the emergence of the warehouse, similar problems may also be caused, and each component may be affected, which will cause each local failure to expand to the global.
In many cases, the warehouse needs the ability to fuse. One is that you return an error code, and you must be able to correctly handle this error code.
Also, if you do not return an error code, you must at least know how many concurrent requests have gone out, and limit the above concurrent requests. If there are a lot of concurrent requests, you need to do fusing and service degradation, and tell sales that many requests have been sent , but no response was received. Then there is no way to handle more requests now.
Since it is a microservice architecture system, each service is responsible for registering it with the service registry, and each service's downward call requires load balancing capabilities.
If an HTTP service is provided, then no verification is performed. Then this service will be affected by many malicious or non-malicious requests, so the validity, frequency, etc. of the requests cannot be controlled.
If the service provides the ability to delete, if no verification and authentication is done, then this protection is out of the question.
The entire enterprise will have a set of central services for authentication and authentication. Every application will be connected to this service. The calls between services must be based on trusted permissions. I want to know who you are, and you must have this permission. able to call me. There is usually an auth server here.
Each service will communicate with the auth server to obtain the ability to authorize credentials.
A more complete service architecture
The client initiates requests, the server responds to these requests, and the server has business logic and platform capabilities.
Then a complete microservice framework integrates business capabilities and platform capabilities as a whole.
system boundary
How to sort out platform capabilities and business capabilities.
What is the business logic? There are sales warehouse accounting discount, these are really business-related logic codes.
These are business.
The rest are related to authentication, circuit breaking, load balancing, and protocols, which have nothing to do with business. These are more capabilities on the platform side. It is the call between business and business, based on what agreement and what kind of appeal, these are all unified on the platform side.
This kind of architecture is usually divided into two types, one is the spring cloud that java programmers are familiar with, this project integrates netfix, which is some open source software of the company Netflix. These open source software include eurka, such as the service registry, or ribbon, which is for client load balancing.
These embed many open source libraries into the business code. When the business code is used for platform-side capabilities, then the business code and platform capabilities need to be deeply integrated. Secondly, if you want to make any changes, you actually need to move the deployed package. For example, if you want to upgrade the version of your service discovery capability or load balancing capability, then you need to upgrade the entire war package.
In this way, the business side and the platform become a tightly coupled relationship.
So is there a more elegant way and a more reasonable way to make the business belong to the business and the platform belong to the platform. Can you simplify the requirements on the basic platform side that the business faces.
Will authenticate, service discovery. These capabilities of fusing are thrown to the platform side, so that the business side really only cares about the business. This mode is the capability recommended by the service grid, which is the result pursued by istio.
