This is what we do to privatize the output service grid

Introduce

Problems of microservice development

There are four common problems in the development of microservice architecture:

• Multilingual problem: there are multiple programming languages, node.js, JAVA, GoLang... microservices need to maintain a middleware SDK for each language

• Difficult to promote the upgrade: SDK upgrade needs to promote the code modification and release of business applications, which disturbs the business, and the promotion cost is high under business pressure

• Slow iteration speed: due to the existence of multiple languages and versions, it needs to spend a lot of energy to maintain the historical version, which reduces the iteration speed and slow the upgrade speed (the problem of R&D efficiency is also considered in the selection of data plane)

• Multi-version problem: SDKs in each language are faced with version upgrades, and there are a large number of different versions accessing each other. The cost of compatibility and test maintenance is huge

In order to solve these problems, the Sidecar+APP model of service grid is a good solution

Service Grid

Service Mesh is an infrastructure layer that deals with service communication. It is responsible for reliable request transmission under the complex topology of services composed of cloud native applications. In practice, it is a set of lightweight network agents deployed together with application services, and transparent to application services. The concept of service grid has been put forward for many years. There have also been many different types of implementations of service grid, such as Istio, Linkerd, Open Service Mesh, etc., as well as other methods of service grid implementation such as ebpf+envoy, proxylessMesh and so on. In fact, they are all thinking about how to solve the problems in current production and development. We are most familiar with Istio. The architecture is as follows:

Through the separation of Sidecar and business applications, the control surface Istiod realizes the control of the entire traffic. Based on the capabilities of Istio+Envoy, the connection, security, control and observability of microservices are realized. The service grid reflects the platform-level service governance capability that is decoupled from the application under the microservice architecture, and promotes the unified multi-protocol and multilingual microservice governance, while maintaining the decoupling of infrastructure and application, Reduce the cost of upgrading and operation and maintenance, and realize safe and reliable communication between microservices, so that the communication of different types of microservices can be observed.

Alibaba Cloud Private Cloud Service Grid Capability

The advantages of the service grid are widely recognized by everyone. Until today, many users have used the service grid in their own production and business systems. However, for many common users, the use and operation and maintenance of such a system is still too complex. In normal use, we may only need to do a grayscale release, which involves different rule configurations, and is very easy to make mistakes, How to define the application's VirtualService, DestinationRule and other rules requires a high learning cost for most users. In order to reduce the cost of use and the difficulty of operation and maintenance, Alibaba Cloud Private Cloud Service Grid pushes out the capabilities of the service grid through a high degree of productization. It only needs to operate the console according to common ideas, and can easily complete such tasks as grayscale publishing, label routing, authentication Full link and other capabilities.

The following is a large picture of the capabilities of Alibaba Cloud's private cloud service grid, covering protocol, environment, service governance, observability, and safe production:

Next, let's introduce our product capabilities:

Service governance

• Traffic management

There are many capabilities of traffic management, including load balancing, fusing, current limiting, timeout, retry, traffic mirroring, connection pool management, fault injection, routing with AZ, and service Mock.

The current limit capability provides the current limit of single machine, the flow limit based on header, and the flow limit of Path.

In addition to the service-level faults of the open source community, fault injection for a single Pod of the service is also provided in the fault injection, so that the test of a single Pod can be carried out.

The ability of service Mock can specify the return of the interface for the developer Mock. When the interface has not been developed, it can improve the efficiency of development testing. In the configuration of service Mock, you can select the requested path, port number, method, status code, header, and return Json data.

• Label routing

Through label routing, you can select the baseline version, then select the corresponding routing version, configure routing policies, such as weight-based policies and content-based policies, and easily complete the configuration of routing rules through simple configuration.

• Service registration

Service registration, as its name implies, is to register microservices to the registry. This capability is mainly to help some non-Java type services realize communication with existing Java type services. For example, Spring Cloud services need to communicate with non-Java services. In order to facilitate code writing, Spring Cloud services need to call non-Java services like other Spring Cloud services, Therefore, non-Java services need to be registered in the corresponding registry. Here we support the registration of non-Java services in the Nacos and Eureka registries.

• Operation monitoring

Display the operation monitoring data of the service, such as the average number of requests processed and the success rate of requests.

• Grayscale publishing

You can publish a grayscale image by publishing the version, fill in the corresponding version number and image, configure the weight and content routing rules, and use the rollback and grayscale success capabilities.

• Zero trust security

You can configure two-way identity authentication, requested JWT authentication, and corresponding authorization policies.

Full-link routing

Full-link routing can be implemented in the whole call chain according to the specified rules. For example, when testing whether a service meets the expectations, but the test service needs to rely on other services. At this time, you can pull a swimlane of the development environment through the full link capability, and send the traffic of the specified tag to the test service, while other requests are still in the baseline environment. At this time, if there are other services to be tested, You can also join this swimlane for testing. The advantage of full-link routing is that you can route to the intermediate service of the service link at will. The R&D/testing personnel can easily deploy a set of independent environments outside the baseline environment, improve the efficiency of R&D and testing, and reduce the cost of operation and maintenance.

• Create swimlanes

Create a swimlane that belongs to the corresponding service grid, that is, a different environment (determine the baseline version environment before creating the swimlane).

• Publishing service/import service

After creating the swimlane, you can publish a service to the swimlane, or import the deployed service.

Select the application of the entrance and configure the rules (what traffic characteristics of the request can enter the swimlane).

Portal gateway

The services in the service grid can be exposed through the capabilities of the Istio Ingress Gateway of the service grid. In the protocol, we support HTTP, HTTPS, and GRPC. In addition to exposure, we also support the configuration of routing rules, which can manage the traffic of the entry service.

External services

External service management can be used to manage the extra-network services. You can configure the protocol, address and EndPoint of the service, and also configure the labels of different EndPoints of the service.

Service topology

Combined with Prometheus+Kiali, the topology of the entire call link can be displayed, including the service and version of the call.

Grid management

• Cluster management

The existing K8s cluster can be added through simple access to the cluster. After adding, the service grid can be deployed in the corresponding cluster through the ability to create the grid in the grid management. When creating the grid, you can configure the high availability of the gateway, the control plane Istide, the Sidecar resource of the service in the cluster (can also be configured separately), and whether to open the AccessLog log.

• Grid configuration management

After creating a service grid, you need to manage and configure the grid. You can see common configurations in the advanced options, such as gateway high availability, control plane high availability, gateway resources, control plane resources, service access restrictions, observable, etc.

In addition to these, it also provides the ability to connect the service grid to the registry. Here we support the common Nacos, Eureka, Zookeeper, and Consul registry to connect to the service grid.

• Multi-cluster management

The single cluster can meet the requirements of most users, but for disaster recovery, the management and interworking of multiple clusters are also very important. The multi-cluster capability of the service grid is also supported in the community version, but the configuration is complex. Our product provides the ability to manage multiple clusters with one key. Through the multi-cluster configuration - the ability to manage clusters, it is easy to realize the interworking and governance of applications between multiple clusters.

Deployment and output

We support the output of Alibaba Cloud Hybrid Cloud Enterprise Edition and CNStack. At the same time, we also support the independent deployment of output. We only need a K8s cluster to quickly and easily pull up the capacity of the private cloud service grid and experience the product-based service grid.