“This is the fifth day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”
Hello, I’m looking at the mountains.
At the end of the article, it is not recommended for start-up teams to directly use micro-services. The most fundamental thing for start-up teams is to survive, and a lot of infrastructure is needed to use micro-services. In this paper, what infrastructure is needed for micro services.
It should be noted that the following components are based on the premise that there are too many services.
Microservices are designed to improve r&d efficiency: the same number of people can handle more requirements, maintain more products, and deliver products faster. Based on this, the basic components of microservices start from freeing up manpower and reducing human error.
1 container
1.1 Running Containers
The container of service operation is the basis to support the service to provide external access. According to the requirements of microservices, in the independent process of each service running separately, the required operation container needs to be small and flexible. The operation container can be integrated in the operation environment, or can be integrated in the service executable package.
In the Java space, each major vendor has its own Web container: WebLogic, JBoss, Tomcat, Jetty, etc. SpringBoot is embedded with Tomcat and Jetty, and the default package is FatJar, which is guaranteed to contain all the basics of service operation and can support the basic requirements of microservice deployment.
1.2 Deploying Containers
A deployment container is an added component to running a service, and the benefit of a container is that a set of images can support testing and build deployments. Doing so can avoid problems in the test environment and various errors in the production environment. But to have a set of images running everywhere, you need centralized configuration support.
And for deployment containers, it is better to have a container scheduling platform so that resources can be used more efficiently. If not, you might use a deployment container and a normal deployment, and the difference is not that great.
2 Service registration/discovery
Service registration/discovery are two components that are not necessarily related to each other, but typically come in pairs to solve the same problem: configuration of dynamically changing service addresses.
In the era of monolithic architecture, there were only a few large systems inside the enterprise, and all you needed to do was specify IP addresses in advance to call other services. However, in the cloud native era, network addresses of service instances are dynamically allocated, so it is difficult to specify IP addresses in advance. Moreover, during deployment, dynamic scaling, service migration, service death, and service instances change dynamically. If you still rely on manual, not only a waste of time, and prone to error.
The best way is for the service to report its location either by itself or through a proxy, and then when the client wants to invoke the service, it simply takes an available service address from the registry and invokes it directly, which is the service registration/discovery component.
3 the gateway
In a singleton architecture, there is usually only one set of redundant or load balanced services. In a microservice architecture, each service provides a fine-grained set of services. For a normal application, it might be necessary to call several different microservices to get all the data. There are three disadvantages to this:
-
Calling too many services, which applies to back-end service bundling, also creates a second disadvantage
-
Services are difficult to reconstruct. Over time, services may be merged or split. When services are bundled together, it is difficult to reconstruct
-
The protocols exposed by the back-end services are inconsistent and may be unfriendly to the Web. Although microservices require lightweight communication between services, there is no emphasis on using the HTTP protocol.
At this point, there needs to be a unified gateway that decouples the application to microservices and shields the internal details to receive all caller requests.
At present, there are many excellent practices on the gateway, such as reverse routing, security authentication, current limiting fuse, log monitoring, gray publishing and other functions on the gateway, which simplifies the function of micro-service, so that the micro-service team can concentrate more on the business.
4 Authentication
Safety first, any industry is safety first.
Authentication consists of two concepts: user authorization and security authentication. User authorization means that a user is authorized to access resources. Then, when a user accesses resources, the user is authenticated to access resources. They work together to protect resources. OAuth2 protocol is commonly used in the industry to achieve authorization.
5 Configuration Management
Configuration management, like service registration/discovery, addresses the pain point of too many services and human travel.
Often, developers put configuration in configuration files, which are not standardized enough to trace configuration items. More dangerous is that some security configurations, such as user names and passwords, do not meet audit requirements. In addition, if large-scale configuration changes are required, the changes will take a long time and then require redeployment, which may affect the entire product. Therefore, a centralized configuration management service is required.
6 Collecting Logs
Logging is the primary source for recording the health of the service, and can also be used to restore the site in the event of an exception. However, as the number of services increases, logs are distributed on many servers. Without aggregation, troubleshooting becomes more difficult.
7 Monitoring Alarms
Monitoring alarms is not a patent of microservices. When a service cluster or server reaches a certain scale and wants to provide services with 7 x 24 shutdown and downtime, alarms need to be monitored. Because the service scale of microservices is relatively large, the necessity of monitoring will be amplified.
7.1 indicators
Generally, monitoring indicators are based on system, application, and service:
-
System monitoring: Monitors the running status of dedicated servers, VMS, and operating systems (oss). The main indicators include cpus, memory, disks, and networks. Other data includes the running time of dedicated servers, OPERATING system versions, and operating system cores, which are also the basic basis for troubleshooting. Here, we also need to focus on the network. Microservices are called or invoked through the network. Once the network has problems, the whole microservice cluster is unavailable.
-
Application monitoring: Monitors the running status of applications, including application running time, HTTP service port, SERVICE URL, HTTP service response code, HTTP service response time, SQL, cache hit, TPS, and QPS. For Java applications, you also need to include JVM health: JDK version, memory usage (heap memory, non-heap memory, etc.), GC, and other Java virtual machine health.
-
Service monitoring: Mainly monitors the execution of some core services, which is intrusive to some extent. The indicators of each service are different, and different monitoring methods are also different. Such as monitoring login registration, commodity information, inventory, order, payment, delivery and other businesses.
7.2 health
A general health check is done through a heartbeat check and is usually divided into two types:
-
One is to establish a TCP connection and perform a ping/pong call. In this way, the TCP connection between the service and the monitoring system needs to be established, and the monitoring component needs to be embedded in the service, which intrudes the service. But because of its high efficiency and strong pertinence, there will be no under-reporting.
-
One is to monitor service ports. In this way, only monitoring plug-ins need to be added in containers or virtual machines, which does not invade services. However, port availability and service availability are not the same concept, so there will be missed reports.
7.3 call chain
Microservices call each other, and the entire invocation link is interlocked, which, if left unmanaged, can turn into a request storm.
Call chain monitoring is a way to analyze system dependencies, request time, and request bottlenecks. At present, most of the call chain monitoring components in the market are developed based on Google Dapper. The following is a schematic diagram of the principle of call chain monitoring (since there are many contents of call chain monitoring, a separate chapter will be opened later) :
7.4 Exception Collection
Exceptions fall into two categories, logical exceptions and behavioral exceptions. Logical exceptions are exceptions in the code, such as the common NPE; Abnormal behavior Abnormal behavior occurs when the user’s behavior is unexpected. Both of these situations have certain harm to the system. So you need to collect these exceptions and be able to locate where they occur. Exception information is collected to locate faults. Therefore, the reported information must be comprehensive and easy to locate. Therefore, an exception code must be protected in the reported information. You can customize a string of a certain length to facilitate location. The next step is to report parameters for restoring the site. Also report abnormal information, used to analyze abnormal conditions.
The last eight
All of the components mentioned above are designed to better manage microservices, reduce human operations, and reduce human error. It’s hard to describe all the advantages of the above components in a few words. Each component needs to be discussed in detail separately, so this is a primer.
Hello, I’m looking at the mountains. Swim in the code, play to enjoy life. If this article is helpful to you, please like, bookmark, follow. Welcome to follow the public account “Mountain Hut”, discover a different world.
