These days, almost everyone is talking about microservices. Microservices are also popular because they have many advantages over previous application development methods, such as being more flexible and better able to adapt to the current environment of rapidly changing requirements. This article covers some of the key points in microservices architecture design.
What are the key points when designing a microservice architecture? Take a look at the picture below to see the entire ecology of Spring Cloud.
Here are the twelve principles for perfect microservices:
Next, here are ten things you should know about microservices architecture design.
Load balancing + API gateway
In the process of implementing microservices, it is inevitable to face the aggregation and disaggregation of services.
When the split of back-end services is relatively frequent, as a mobile App, it often needs a unified entrance to route different requests to different services. No matter how to split and aggregate them later, they are transparent to the mobile end.
With the API gateway, simple data aggregation can be completed at the gateway layer, which does not need to be completed at the App end of the mobile phone, so that the mobile App consumes less power and has better user experience.
With a unified API gateway, authentication and authentication can also be unified, although the calls between services are more complex and there are more interfaces.
The API gateway exposes only required external interfaces and implements unified authentication and authentication on the interfaces. In this way, internal services do not need to be authenticated and authenticated when accessing each other.
With A unified API gateway, you can set certain policies at this layer, do A/B testing, blue-green release, pre-release environment diversion, and so on.
API gateways tend to be stateless and scaleable so that they do not become performance bottlenecks.
Programmer learning exchange collection: click here to join, welcome one to five years of engineers to join, reasonable use of their every minute every second of time to learn to improve their own, do not use “no time” to hide their ideological laziness! While young, hard to fight, to the future of their own account!
Stateless and independent stateful clusters
x`
Application state is an important factor affecting application migration and horizontal scaling. Stateless services are designed to move this state outward, storing Session data, file data, and structured data in a unified storage at the back end, so that applications contain only business logic.
States are unavoidable, such as ZooKeeper, DB, Cache, etc., and all these stateful things converge into a very centralized cluster.
The whole business is divided into two parts, one is stateless part, one is stateful part.
Stateless parts can achieve two things:
Random deployment across machine rooms, also known as mobility.
Flexible expansion, easy to expand.
Stateful parts, such as ZooKeeper, DB, and Cache, have their own high availability mechanism, and use their own high availability mechanism to implement this state of clustering.
Although stateless, but the current processing of data, or in memory, the current process hangs the data, must also have a part of the loss.
To achieve this, the service needs to have a retry mechanism, the interface needs to have idempotent mechanism, and through the service discovery mechanism, another instance of the back-end service can be called again.
Horizontal scaling of the database
The database is the state to save, is the most important and most prone to bottlenecks. With a distributed database, the performance of the database increases linearly with the number of nodes.
At the bottom of distributed database is RDS, which is in active/standby mode. Through MySQL kernel development capability, we can achieve zero data loss in active/standby switchover.
So the data falls in this RDS, it is very safe, even if a node is lost, after the switch, your data will not be lost.
On top of that, there is a load balancing NLB with LVS, HAProxy, Keepalived, and a layer of Query Server.
Query Server can scale horizontally based on monitoring data, and if a failure occurs, it can be replaced and fixed at any time, with no awareness of the business layer.
Another is the dual room deployment, DDB developed a data canal NDC component, which enables synchronization between different DDBS in different rooms.
In this case, it is not only distributed in one DATA center, but also has a backup similar to hypermetro in multiple data centers. High availability is very good.
The cache
Caching is important in high concurrency scenarios. Have hierarchical caching so that the data is as close to the user as possible. The closer the data is to the user, the greater the concurrency and the shorter the response time.
There should be a layer of cache on the mobile client App. Not all data should be taken from the back end all the time, but only important, critical and constantly changing data.
Especially for static data, it can be fetched once after a period of time, and there is no need to fetch it from the data center. Data can be cached on the nearest node to the client through CDN for nearby download.
Sometimes there is no CDN, or to go back to the data center to download, called back source, in the outermost layer of the data center, we call access layer, you can set a layer of cache, will be most of the request interception, so as not to cause pressure on the background database.
If the data is dynamic and needs to access the application, it can be generated by the business logic in the application or read from the database. To reduce the pressure on the database, the application can use the local cache or the distributed cache.
Such as Memcached or Redis allows most requests to read from the cache without accessing the database.
Of course, dynamic data can also be statically, or demoted to static data, to reduce the stress on the back end.
Service splitting and service discovery
When the system is overwhelmed and applications change rapidly, it is often necessary to consider splitting the larger services into a series of smaller services.
The first benefit is that development is more independent. When many people are maintaining the same repository, changes to the code often affect each other.
I often failed the test without changing anything, and when the code is submitted, there will often be conflicts and the code needs to be merged, which greatly reduces the efficiency of development.
Another advantage is the independence of online delivery. The logistics module connects with a new express company and needs to be online together with the order, which is very unreasonable.
I didn’t change it and asked me to restart it, I didn’t change it and asked me to release it, I didn’t change it and asked me to have a meeting, all of which are times that should be split.
In addition, the capacity expansion during the time of high concurrency, only the most critical order and payment process is usually the core. As long as the key transaction link is expanded, if many other services are attached at this time, the capacity expansion is not only uneconomical, but also very risky.
In addition to disaster recovery and degradation, it may be necessary to sacrifice some of the functions of the corners when promoting, but if all the code is coupled together, it is difficult to degrade some of the functions of the corners.
Of course, after the separation, the relationship between applications is more complex, so the mechanism of service discovery is needed to manage the relationship between applications, to achieve automatic repair, automatic correlation, automatic load balancing, automatic fault-tolerant switchover.
Service choreography and elastic scaling
When services are unbundled, there are so many processes that service choreography is required to manage the dependencies between services and to code the deployment of services, which is often referred to as infrastructure as code.
In this way, services can be published, updated, rolled back, expanded, or scaled down by modifying the orchestration file, increasing traceability, manageability, and automation capabilities.
Since the choreographer file can also be managed with a code repository, it is possible to update five of the 100 services by changing the configuration of five of the services in the choreographer file.
When the choreographer file is submitted, the repository automatically triggers the automatic deployment of upgrade scripts to update the environment online.
When problems are found in the new environment, you want to roll back these five services atomically, and if there are no choreography files, you need to manually record which five services were upgraded this time.
With marshalling files, you can simply Revert to the previous version in the repository. All operations are visible in the code repository.
Unified configuration center
After services are split, the number of services is so large that it is difficult to manage if all the configurations are stored in the local application as configuration files.
It can be imagined that when there is a configuration problem in hundreds or thousands of processes, it is difficult to find it out. Therefore, there needs to be a unified configuration center to manage all configurations and deliver unified configurations.
In microservices, configurations tend to fall into the following categories:
One is the almost invariable configuration, which can be typed directly into the container image.
The second type is the configuration that is determined at startup, often through environment variables that are passed in when the container is started.
The third type is unified configuration, which needs to be delivered through the configuration center. For example, if some functions need to be degraded, you can configure the functions that can and cannot be degraded in the configuration file.
Unified Log Center
When there are a large number of processes, it is difficult to log in to hundreds of containers one by one to view logs. Therefore, a unified log center is required to collect logs.
In order to make the collected logs easy to analyze, certain requirements are required for the log specification. When all services comply with the uniform log specification, a transaction process can be traced uniformly in the log center.
Programmer learning exchange collection: click here to join (878249276), welcome one to five years of engineers to join, reasonable use of their every minute every second of time to learn to improve their own, do not use “no time” to hide their ideological laziness! While young, hard to fight, to the future of their own account!
For example, in the final log search engine, search for the transaction number and you can see where the error or exception occurred in the process.
Fusing, limiting, downgrading
The service should have the ability of fusing, limiting flow, and degrading. When a service calls another service and there is a timeout, it should be returned in time, rather than blocked in that place, thus affecting the transactions of other users. It can return the default base data.
When a service finds that the called service is too busy, the thread pool is full, the connection pool is full, or there are always errors, it should be disconnected in time to prevent the fault or busy of the next service from causing the abnormal of the service and gradually spreading forward, resulting in the avalanche of the whole application.
When it is found that the whole system is really overburdened, you can choose to downgrade some functions or some calls to ensure that the most important transaction flows pass, and the most important resources are devoted to the most core processes.
Another means is current limiting. When both the fusing and degradation strategies are set, the supporting capacity of the whole system should be known through the pressure test of the whole link.
Therefore, a traffic limiting policy needs to be formulated to ensure that the system can provide services within the tested supporting capacity. Services beyond the supporting capacity can be denied.
When you place an order and the system pops up a dialog box saying “system busy, please try again”, it does not mean that the system is down, but it means that the system is working properly, but the traffic limiting policy is working.
Comprehensive monitoring
When the system is very complex, there are two main aspects of unified monitoring, one is health, and one is where the performance bottlenecks are.
When the system is abnormal, the monitoring system can cooperate with the alarm system to discover, inform and intervene in time, so as to ensure the smooth operation of the system.
When the pressure test, often encountered bottlenecks, also need to have a comprehensive monitoring to find bottlenecks, while preserving the site, so that traceability and analysis, all-round optimization.