This article is shared from huawei cloud community “Traditional micro service framework access Istio Solution”, author: Coriander chat game.

Concepts and principles of microservices

Problems with microservices

Benefits of microservices: decoupled business, decoupled code and architecture, more compact business, simpler logic.

Problems caused by microservices:

In the early days, with a monolithic architecture, all the business was within a service without some of the complexity across processes and networks.

Problems introduced after microservitization include how to do service discovery, how to do load balancing, including access protection between services, such as fuse, fault location and so on.

In the case of fault location, in the original single service, you only need to look at the log, but after microservitization, you need to use the distributed call chain tool, which virtually brings the complexity of development and fault location.

Microservices versus LSTIO grid architectures

We know more about the micro service framework is Spring Cloud or the domestic use of more Dubbo, the framework itself is not introduced, I think we have some understanding.

The principle is to provide development SDKS or frameworks that have built-in solutions to microservice problems such as service discovery, load balancing, service fuses and downgrading, call link buries, dynamic routing, and so on.

Here is a typical usage, and one that is very widely used:

Grid-based governance has been widely applied in recent years. It can be seen from the figure above that although the capabilities provided by grid-based governance are the same as those provided by SDK in the figure above, their design principles, application scenarios and design concepts are different.

Detailed introduction

Service discovery and load balancing

The diagram above shows the principle of a traditional microservice framework. The general flow is as follows:

• Register with the service center when the service is started

• Obtain the address of the back-end service from the service center before invoking

• Select an instance to send the request and wait for a response

How the service grid works:

Service grid is generally used in combination with K8S, because K8S itself does service endpoint maintenance, so LSTIO does not need to do service registration, only service discovery.

Take a look at the detailed differences:

Service fusing

Service circuit breaker mechanism:

If a service is unavailable for a specified period of time, you can use the circuit breaker mechanism to isolate the service from traffic and enter the semi-circuit state.

If it can be restored to normal within a certain inspection period, the fusing state will be closed; if it still cannot be normal, it will continue to enter the fusing state.

Problems of traditional microservice frameworks and solutions based on service grid

Problem 1: Multilingual problem with microservice SDK

The diagram above illustrates the relationship between microservices, with some large customers supporting a large system consisting of multiple services that may be developed in multiple languages.

For example, the system may have go services, C++ services, python services, spring cloud services, etc. This is a relatively common situation.

When you want to do a universal service discovery among these services, but the services developed by Spring Cloud or Dubbo have their own service discovery mechanism, but the discovery framework of services developed by different languages is different. For example, the services developed by Go service cannot be registered in the service center of Spring Cloud. There is no way to solve this problem.

More brutal solution is for other project in the Java language refactoring, under the condition of the project not complex is acceptable, but in the business system is more complex, more need to modify the project situation is unacceptable, not only need a lot of manpower, also spend a lot of time, the stability of the service can’t guarantee.

In the solution of service grid, service discovery is decoupled from business. No matter what language the service is developed, proxy does not need to participate in compilation and only needs to open ports between grids and maintain access. In this solution, there is no need to modify the original code and the amount of development is reduced, which is acceptable to enterprises.

Problem 2: SDK-BASED services have latency and inconsistent data under K8S

In this case, the Consumer service was originally on POD1, and then migrated to Pod2 due to scheduling problems. Pod1 needs to be unregistered and Pod2 needs to register again. However, if pod migrations are frequent, As a result, Producer attempts to access the Consumer service and still gets the same registered address, resulting in delays and data inconsistencies.

Problem 3: Service upgrades developed based on SDK logic must be recompiled

When the logical code developed based on SDK is upgraded, all services developed based on SDK must be recompiled. This upgrade will bring a lot of work, and the SDK upgrade process must be upgraded together with the business team, which is very time-consuming. The resulting requirement is that there is no need to recompile if the business code has not changed.

Under the grid solution, there is no need to compile and modify if the business is not modified, which is very friendly for developers and operation and maintenance, and reduces the risk of operation and maintenance, after all, any change is a risk.

Problem 4: Based on SDK development, unified discovery and governance capabilities need to be completely reformed

If micro service on a single application is usually gradual micro service, such as above, the general for svc1 micro service first, and then to micro svc2 service, are in the process of development still need access to Shared, but using SDK micro services sometimes need to use the same framework, the same version to communicate interaction, that is the pain points.

In the case of grid, the first step is to microservize SVC1, leaving SVC2 unchanged and still not affecting the original access during development.

Practical details of integration of traditional microservice frameworks in service grids

The overall train of thought

Uninstall the SDK’s service discovery and service governance capabilities and migrate them to the infrastructure, freeing users to focus on their business code.

The solution

Traditional microservices are found by registering to a registry.

After using grid, platform same service discovery, using Kube-proxy for service discovery and load balancing, Kube-Proxy directly returns the IP and port of the service, so as to eliminate the problem of service discovery data in the container environment is not timely.

The ability to use the grid for service discovery using K8S requires no modification at all

Transformation of the Spring Cloud project

In the original configuration, cancel the registration of the registry, change to directly use the service name: port for access, direct connection of this way will be forwarded by K8S, no need to modify the business code, reducing the workload.

Note: Keep the protocol consistent with the service being accessed.

Remove project dependencies for Spring Cloud

Improvements to the microservices gateway

Case 1: The microservices gateway has business logic

A lot of custom logic is written, such as filtering of filters and so on, in which case the gateway can be deployed within the grid as a normal microservice.

Case 2: Microservices only have general-purpose logic capabilities

Directly replace with Ingress, address mapping, path mapping and other basic capabilities, remove the original gateway.

Integrate the microservice registry into the grid

Because some project development architectures are self-contained, it is not appropriate to directly exclude the original infrastructure capabilities, in which case the grid capabilities need to be imported from the original registry. Istio imports the registration data from the microservice registry and stores it in a converted format, but the same governance rules can still be configured.

conclusion

Using K8S and LSTIO grid for development, leaving service discovery and service governance to infrastructure, can free developers from complex services and focus on business development, which is a better solution at present.

Video address: education.huaweicloud.com/courses/cou…

Click to follow, the first time to learn about Huawei cloud fresh technology ~