Abstract: Using k8s and lstio grid for development, leaving service discovery and service governance to the infrastructure, can free developers from complex services and focus on business development, which is a better solution at present.
This article is shared from HUAWEI CLOUD Community " Detailed Explanation of Traditional Microservice Framework Accessing Istio Scheme ", author: Coriander Chat Game.
Concepts and principles of microservices
Problems with Microservices
The benefits of microservices:
The business is decoupled, the code and the architecture are decoupled, the business is more compact, and the logic is simpler and simpler.
Problems with microservices:
In the early days, with a monolithic architecture, all the business was within one service, without some complexity across processes and networks.
The problems introduced after microservices include how to do service discovery, how to do load balancing, including access protection between services, such as circuit breaker, fault location and so on.
When locating faults, you only need to look at the logs in the original single service, but after microservices, you need to use the distributed call chain tool, which brings the complexity of development and positioning problems.
Microservice and lstio grid architecture comparison
As for the microservice framework, we know more about Spring cloud or Dubbo, which is widely used in China. The framework itself will not be introduced much. I think everyone knows it.
The principle is to provide developed SDKs or frameworks. These frameworks have built-in solutions to microservice problems, such as service discovery, load balancing, service fuse and downgrade, as well as buried points of call links and dynamic routing. matter.
The following figure is a typical usage, and it is also a very widely used usage
Grid-based governance has been widely used in recent years. As can be seen from the above figure, although the grid-based governance provides the same capabilities as the SDK-based capabilities in the above figure, the design principles and usage scenarios of the two are The design philosophy is different.
Detailed introduction
Service discovery and load balancing
The above picture is the principle of the traditional microservice framework
The general process is:
• Register with the service center when the service is started
• When calling, first obtain the address of the backend service from the service center
• Select an instance to send the request and wait for a reply
How a service mesh works:
Service mesh is generally used in conjunction with k8s, because k8s itself maintains the endpoint of the service, so lstio does not need to do service registration, but only needs to do service discovery.
See the detailed difference
Service fuse
The mechanism of service fuse:
If a service has been unavailable for a configured period of time, the fuse mechanism can be used to isolate the service, make it impossible to access traffic, and enter a semi-fuse state.
If it can return to normal within a certain inspection period, the fuse state will be turned off. If it is still not normal, it will continue to enter the fuse state.
Problems with traditional microservice frameworks and solutions based on service mesh
Issue 1: Multilingual Issues with Microservice SDK
The above picture shows the relationship between microservices. Some large customers support large systems. The system consists of multiple services, and services may be developed in multiple languages.
For example, there may be go services, C++ services, python services and spring cloud services in the system, which is a relatively common situation.
When I want to do a general service discovery among these services, but the services developed by Spring cloud or Dubbo have their own service discovery mechanism, but the discovery frameworks are different between services developed in different languages, such as services developed by go services It is impossible to go to the service center of spring cloud to register, there is no way to solve this problem.
The rough solution is to use Java to refactor projects in other languages, which is acceptable when the project is not complicated, but unacceptable when the system business is complex and there are many projects that need to be modified, not only It requires a lot of manpower and a lot of time, and the stability of the service cannot be guaranteed.
Under the service grid solution, service discovery is decoupled from business, no matter what language the service is developed, because the proxy does not need to participate in the compilation, only the ports need to be opened between grids and remain accessible. Under this solution , do not need to modify the original code, reduce the amount of development, is acceptable to the enterprise.
Problem 2: SDK-based services have delays and data inconsistencies under k8s
In the case of the above figure, the Consumer service was originally on pod1. Later, due to scheduling problems, the Consumer service was migrated to pod2. Normally, pod1 needs to be logged out and pod2 is re-registered. However, if the pod migration is frequent, the Producer will be If the old registered address is still obtained when accessing the Consumer service, there will be delays and data inconsistencies.
Question 3: Service upgrades based on SDK logic development must be recompiled
When the logic code developed based on the SDK is upgraded, all services developed based on the SDK must be recompiled. This upgrade will bring a lot of workload. The SDK upgrade process must be upgraded together with the business team, which is very time-consuming. The resulting requirement is that recompilation is not required if the business code has not changed.
Under the grid solution, if the business is not modified, there is no need to compile and modify it. It is very friendly to developers and operation and maintenance, and at the same time reduces the risk of operation and maintenance. After all, any change is a risk.
Question 4: Based on SDK development, unified discovery and governance capabilities need to be fully transformed
If a single application is microserviced, it is generally a gradual microservice. For example, as shown in the figure above, generally, svc1 is microserviced first, and then svc2 is microserviced. In the process of development, it is still necessary to access and interoperate. However, microservices using SDK sometimes need to use the same framework and the same version to communicate and interact, which is the pain point.
In the case of using grid, the first step is to microservice svc1, and svc2 will not be changed, and the original access will not be affected during development.
Practical details of traditional microservice framework integration in service mesh
general idea
Uninstall the service discovery and service governance functions of the SDK, and migrate these functions to the infrastructure, so that users can be freed from these and only focus on their own business code.
solution
The discovery of traditional microservices is registered to the registry
After using the grid, the same service is discovered on the platform, and kube-proxy is used for service discovery and load balancing. Kube-proxy directly returns the ip and port of the service, which eliminates the problem of untimely service discovery data in the container environment.
When using k8s for service discovery and then using grid capabilities, services do not need to be modified and adapted at all
The transformation of the Spring cloud project
In the original configuration, cancel the registration of the registration center and use the service name: port to access directly. This way of direct connection will be forwarded by k8s, and there is no need to modify the business code, which reduces the workload.
Note: The protocol must be consistent with the accessed service.
Remove project dependencies of spring cloud
Improvements to Microservices Gateway
Case 1: Microservice gateway has business logic
I wrote a lot of custom logic, such as filter filtering, etc. In this case, the gateway can be deployed in the grid as an ordinary microservice.
Case 2: Microservices only have general logic capabilities
Directly replace it with Ingress, perform basic capabilities such as address mapping and path mapping, and remove the original gateway.
Integrate the microservice registry to the grid
Since some project development architectures are self-contained, it is not suitable to directly exclude the original basic capabilities. In this case, if you want to use the grid capabilities, you need to import the original registration center. Istio imports registration data from the microservice's registry and stores it in a converted format, in which case the same governance rules can still be configured.
Summarize
Using k8s and lstio grid for development, leaving service discovery and service governance to the infrastructure, can free developers from complex services and focus on business development, which is a better solution at present.
Video address: https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/
Click Follow to learn about HUAWEI CLOUD's new technologies for the first time~