Introduction to Alibaba Cloud Managed Grid Service and Application Deployment Practice

Introduction: As a developer, you should focus on your own business, and hope that the underlying service grid technology will be simple, easy to use, secure, and stable. To achieve these goals, a managed service mesh pattern may be a reasonable solution. Alibaba Cloud Service Mesh ASM is such a fully managed service mesh platform and is fully compatible with the community open source Istio. In this live broadcast, Xiao Yuan, an expert in Alibaba Cloud's intelligent technology, shared the basic functions and advantages of Alibaba Cloud Service Mesh (ASM), and used a demo to introduce the basic usage of ASM.

1. Introduction to Service Mesh

In the early days of cloud-native applications, we mostly used monolithic applications to deploy, package, and release all business-related applications. Under this architecture, as businesses become more and more complex, applications become increasingly inseparable. Split, the scalability and scalability of different modules are very poor. In order to solve the above problems, we propose a microservice architecture, which divides services into different application units and business components according to their functions. The components call each other through API, and the independent components can be expanded horizontally and vertically. , which improves the scalability of the architecture.

However, the microservice architecture brings good scalability and also increases the complexity of operation and maintenance, and then the container and orchestration architecture was born. Container technology can customize the basic environment for software operation and facilitate the isolation of resources. Containers The orchestration technology can orchestrate applications to different machines, providing the basic mechanism for scalability of container-based applications. On the basis of the software environment based on container deployment, we need a container-based framework for service governance, so the service mesh was born. Different services have their own characteristics, and their advantages and disadvantages are compared as shown in the figure below.

How hard is it to govern microservices in a container environment if you use a microservice architecture instead of grid services? The difficulties mainly include:

*The communication link is complex, and it is difficult to locate the microservice problem;
*Some service functions are difficult to implement, such as service discovery, load balancing, fault tolerance, end-to-end monitoring, dynamic routing, etc.;
*The service function is tightly coupled in the application itself in the form of a code base, which is easy to cause version conflicts;
*Solutions in different programming languages ​​vary greatly and lack commonalities.

In the service mesh, the above problems are handled by the Sidecar proxy, which can be called the "artifact" of container microservice traffic control. At the same time, these functions are standardized, and application developers can focus on the implementation of business logic. Visually speaking, Sidecar is like the sidecar of the motorcycle shown in the figure below. Where the service goes, the Sidecar will go. For example, in Istio, a very famous service grid, its Sidecar is an Envoy written in C++. In this way, components and service meshes implement various service functions including service discovery, observability, and current limiting.

The difference between the traditional way of doing service governance through a third party and the service mesh is shown in the following figure. In the traditional way, we integrate the service governance capability into the application through Library or other methods, but if the version of Library or the language framework is different, the service governance capability will have different differences, which brings huge inconvenience to the version upgrade. ; In the service mesh, we use the sidecar proxy to solve this problem, so that the improvement or upgrade of service capabilities is independent of the application itself.

In addition, since we use the Sidecar proxy method, it is convenient for us to carry out unified management. For example, the Pilot component in Istio continuously reads the rule configuration submitted by the user to the database, and then exchanges information with the Sidecar agent of each service to achieve unified management of the entire platform. Through the service mesh, we unify and standardize the capabilities of this service governance. The main functional services and features are shown in the following figure.

2. Alibaba Cloud Service Mesh (ASM)

(1) Introduction to ASM

Service mesh provides powerful functions, but also brings more complexity as shown in the figure below. The first is deployment complexity, and its complexity has also become the reason why some users are discouraged.

In order to solve the problem of its deployment complexity, Alibaba Cloud released a related product: Alibaba Cloud Service Mesh (ASM). Alibaba Cloud Service Grid provides a fully managed service grid platform that is compatible with the community Istio open source service grid to simplify service governance, including traffic routing and split management between service calls and inter-service communication. Certified security and grid observability capabilities greatly reduce the workload of development and operations. As can be seen from the figure below, Alibaba Cloud's container team has provided services such as ACK, ASK, and ACR before. ASM is a traffic management platform on top of these services.

The architecture of ASM is shown in the figure below. It is actually a managed and unified platform for traffic management and service governance. It is 100% compatible with the community's Istio and has access to some capabilities of Alibaba Cloud, such as security capabilities, logging capabilities, Distributed tracking capabilities, etc., and access to the cloud enterprise network, to achieve mutual access between different networks.

(2) Application scenarios and advantages of ASM

ASM has powerful and convenient functions, so what scenarios is ASM suitable for? At present, the applicable scenarios of ASM mainly include:

* Unified traffic management for multi-cluster applications: Provides consistent visibility and traffic management for K8s clusters deployed in multiple regions, hybrid clouds, and different types of clusters.
*End-to-end observability: Provides optimized integration of tracking, monitoring and logging functions to help users deeply analyze the performance and operation of network and application services.
*Service security hardening and flexible authorization: Through mTLS, the security of communication between services is gradually realized in a gradual manner, providing easy-to-use, role-based access control and custom authorization capabilities, and supporting audit trails for all change operations.
*Application containerization and smooth migration to the cloud: Migrate existing applications in the offline environment to the cloud. By deploying and configuring service meshes, traffic is dynamically routed to the old offline environment or the new online environment to handle stateless service migration.

Compared with the ACK Istio addon and the self-built Istio on the cloud, the comparison of the three methods in terms of management and control plane, user cost, and security is shown in the following figure:

(3) ASM traffic management

As shown in the figure below, ASM first divides data into control plane and data plane. The data plane supports different proxy services. At the control plane, it can host API Server access portals, ETCO, Istio Operator, etc. for users to achieve unified management of traffic and services.
And in terms of traffic management strategy, ASM is fully compatible with the Istio community API, providing users with more convenient services.