I talked about "What is a microservice " in the previous article . At the end of the article, it is mentioned that start-up teams do not recommend direct use of microservices. For start-up teams, the most fundamental thing is to survive. If you want to use microservices, you need a lot of infrastructure. This article will talk about what infrastructure is needed for microservices.
It should be noted that the following components are based on the premise of too many services.
The emergence of microservices is to improve the efficiency of research and development: the same number of people can handle more needs, maintain more products, and deliver products faster. Based on this, the basic components of microservices start from liberating manpower and reducing human errors.
1 container
1.1 Run the container
The container in which the service runs is the foundation that supports the external access provided by the service. According to the requirements of microservices, in the independent process of each service running separately, the required running container needs to be small and flexible. The running container can be integrated in the running environment, or can be Integrated in the service executable package.
In the Java field, major manufacturers have their own web containers: WebLogic, JBoss, Tomcat, Jetty, etc. SpringBoot embeds Tomcat and Jetty, and the default packaging method is FatJar. The jar guarantees that it contains all the foundations for service operation and can support the basic requirements of microservice deployment.
1.2 Department container
The deployment container is an added component of the service operation. The advantage of the container is that a set of images can support testing and generation deployment. Doing so can avoid the situation where there is no problem in the test environment and various errors in the production environment. But if you want to implement a set of mirrors to run everywhere, you also need the support of centralized configuration.
And for deploying containers, it is best to have a container scheduling platform, so that resources can be used more effectively. If not, you may use the deployment container and the ordinary deployment method, the difference is not very big.
2 Service registration/discovery
Usually service registration/discovery are two components, which are not necessarily related to each other, but these two components appear in pairs to solve the same problem, so they are grouped into one.
In the era of monolithic architecture, there are only a few large systems inside the enterprise. If you want to call other services, you only need to specify the IP address in advance. With the subsequent system modularization process, and then to the SOA architecture, to the current microservice architecture, there are hundreds of services, and it is possible to expand or migrate services at any time. If it is still done manually, it will not only waste time, but also be prone to errors.
The best way is to report the location of the service itself, and then the client can find the service that needs to be called by itself. This is the service registration/discovery component.
3 Gateway
The gateway is to shield the internal details, provide a unified entrance for the caller, receive all the caller's requests, and forward them to the components of the service instance through the routing mechanism. Gateway is not a new concept. Many service proxy components (such as HAProxy, Nginx, SLB, etc.) can be called gateways.
At present, there are many excellent practices on the gateway. Reverse routing, security authentication, current limiting fuse, log monitoring, gray release and other functions are placed on the gateway, and the functions are front-facing, simplifying the microservice functions, so that the microservice team can Focus more on business.
4 Authorized authentication
Safety first, all industries are safety first.
Authorization and authentication are two concepts: user authorization and security authentication. User authorization refers to authorizing a specified user to access resources, and then when a user accesses the resource, it is verified whether the user has the authority to access the resource. The two cooperate to complete the security protection of resources. The more commonly used in the industry is to use the OAuth2 protocol to achieve authorization and authentication.
5 Configuration Management
Configuration management is the same as the service registration/discovery mentioned above, which is to solve the pain point of too many services and manual business trips.
Usually developers put the configuration in the configuration file, so that the configuration is not standardized enough, and it is troublesome to trace the configuration items. The more dangerous thing is that some security configurations such as user names and passwords do not meet the audit requirements. Moreover, once the configuration needs to be modified on a large scale and the modification takes a long time, it needs to be redeployed after the modification, which may affect the entire product. So a centralized configuration management service is needed.
6 Log collection
Logs are the main source to record the running status of the service, and you can also restore the scene when an abnormal situation occurs. However, with the increase of services, logs are distributed among many servers. If they are not aggregated, it will be more difficult to troubleshoot problems.
7 Monitoring alarm
Monitoring alarms is not the patent of microservices. When a service cluster or server reaches a certain scale, and you want to provide services without downtime or downtime, you need to monitor alarms. Because the service scale of microservices is relatively large, the necessity of monitoring will be magnified.
7.1 Indicators
Generally, monitoring indicators are carried out from several dimensions such as system, application, and business:
- System monitoring: It mainly monitors the running status of physical machines, virtual machines, and operating systems. The main indicators include CPU, memory, disk, network, etc. Other related data include physical machine running time, operating system version, and operating system kernel. These are also some basic basis for troubleshooting. I also need to focus on the network. Microservices are all called or called through the network. Once the network has problems, the entire microservice cluster is unavailable. Therefore, network monitoring needs to be refined to traffic, data packets, packet loss, and errors. Report, connection number and other indicators.
- Application monitoring: It mainly monitors the running status of the application, including application running time, http service port, service url, http service response code, http service response time, SQL, cache hit, TPS, QPS, etc. For Java applications, it is also necessary to include the running status of the JVM: JDK version, memory usage (heap memory, non-heap memory, etc.), GC and other Java virtual machine running status.
- Business monitoring: It is mainly to monitor the execution of some core businesses, which is intrusive to the business. The indicators of each service are different, and the monitoring methods of each company are also different, usually buried codes. Such as monitoring login registration, product information, inventory status, order placement, payment, delivery and other businesses.
7.2 Health
The general health check is carried out through heartbeat detection, and there are usually two types:
- One is to establish a TCP link and perform ping/pong calls. This method requires the establishment of a TCP link between the service and the monitoring system, and the monitoring component needs to be embedded in the service, which is intrusive to the service. But because of its high execution efficiency and strong pertinence, there will be no underreporting.
- One is to monitor the service port. This method only needs to add a monitoring plug-in in the container or virtual machine, which does not invade the service. However, because the port availability and service availability are not the same concept, there will be false negatives.
7.3 Call chain
Microservices call each other, and the entire call link is interleaved with each other. If it is not managed, it is likely to evolve into a request storm.
Call chain monitoring is a way to analyze system dependencies, request time-consuming, and request bottlenecks. Currently, most call chain monitoring components on the market are developed based on Google Dapper. The following is a schematic diagram of the principle of call chain monitoring (because the content of call chain monitoring is relatively large, a separate chapter will be opened later):
7.4 Exception collection
Anomalies are divided into two types, logical anomalies and behavioral anomalies. Logical anomaly refers to the existence of abnormal logic in the code, such as common NPE; abnormalities that occur when user behavior is unexpected when the behavior is abnormal, both of which are harmful to the system. Therefore, it is necessary to collect these abnormal conditions and be able to locate the location of the abnormality. Exception information collection is mainly for locating problems, so the reported information must be comprehensive and easy to locate. Therefore, the exception code needs to be protected in the reported information, and a character string of a certain length can be customized to facilitate location location. Then it is necessary to report the parameters to restore the scene. Also report abnormal information to analyze abnormal conditions.
8 final
The components mentioned above are all to better manage microservices, reduce human operation and maintenance, and reduce human errors. In a few words, it is difficult to fully explain the advantages of the above components. Each component needs to be discussed in detail. Here is an introduction.
Personal homepage: http://www.howardliu.cn
Personal blog post: Infrastructure work of
microservices CSDN homepage: http://blog.csdn.net/liuxinghao
CSDN blog post: Infrastructure work of microservices