MSE | Alibaba Cloud Native Gateway Trinity Choice and Practice

Introduction to is a unified technical system adopted by Alibaba's "self-research," "open source," and "commercialization". It is hoped that open source will be used as the core, combined with Alibaba's rich internal formats and business needs, and further polished software through self-research The performance and high availability of the trinity eventually form a three-in-one rotating flywheel.

Author | Rufen

The Trinity is a unified technical system adopted by Alibaba for "self-research", "open source", and "commercialization". It is hoped that open source will be used as the core, combined with Alibaba's rich internal business formats and business needs, and the performance and high performance of the software will be further polished through self-research. Usability is then open to all users in the form of commercialized services on the cloud. At the same time, it will continue to contribute to the open source community, and finally form a three-in-one spinning flywheel. The group business supported by the Alibaba Cloud cloud native team is divided into three layers: BaaS, Runtime, and Serverless. Each layer uses open source software as the core, and integrates and extends the open source core. After large-scale production verification, it is promoted to commercialization.

Open source has the advantages of ecology and openness, self-research has the advantages of high performance and strong availability, while commercialization has the advantages of ease of use and security. Based on the three-in-one technology system, open source, self-research and commercialization can have their own advantages The advantages are combined to give play to the greatest advantage.

The development trajectory of cloud native gateways in Alibaba

1. Birth background

The creation of the cloud native gateway originated from the "local life battle" within the group, which started at the "Alipay 2020 Partner Conference", at which Alipay announced the upgrade to an open platform for digital life. The core technical goal of this battle is to achieve direct RPC calls between the Alibaba business domain and the Ant business domain. However, because Alibaba and the Ant business domain network are isolated, that is, the network is not , it is natural to think of using the 16194af8352cdf gateway . Solve this problem.

2. Technical selection

To use the gateway to solve the cross-business RPC interoperability between Alibaba and Ant, we must first select the gateway technology.

I believe everyone is more or less aware of Alibaba's open source reverse proxy program Tengine. Tengine is used in Ali’s internal unified access gateway AServer. Our team was responsible for the development and operation of AServer at the time. At the same time, our team was also responsible for the implementation of Alibaba Service Mesh, whether it was for Tengine or Istio + Envoy. More familiar.

In the selection, although some other software has been investigated, considering the high requirements of the gateway for performance and reliability, combined with our own gateway operation and maintenance experience, we decided to see whether Tengine and Envoy can meet our business needs. In the comparison, we listed four key points, the comparison is as follows:

Here to mention "Why do we think that the hot update of the configuration is very important"?

The configuration update of Tengine/Nginx requires reload, and reload requires restarting the worker process. When restarting, it will cause traffic jitter, and the impact on long connections is particularly obvious. When the cluster size of the gateway is very large, it is not possible to reload at will. At this time, it will cause a contradiction: after the business submits the configuration to the gateway, it is hoped that it can be verified quickly, but it is limited by the reload mechanism and stability requirements. Satisfy the requirements of fast verification and fast trial and error of the business.

How to solve this?

One is to use a two-tier gateway, that is, a traffic gateway + a service gateway; the other is to realize the gateway's native support for configuration hot update. In addition to comparing the advantages and disadvantages of different solutions, we also investigated the trend of Envoy as a gateway in the industry. The conclusion is that Envoy is currently the fastest growing Ingress Provider in K8s (Ingress Provider refers to the specific implementation of the K8s Ingress specification, because K8s Ingress itself is only The specification definition is the specification definition of the gateway for external traffic to enter the cluster under K8s), we finally chose Envoy to implement the two-tier gateway.

3. Development history

From the initial community Istio + Envoy, to Alibaba's internal self-research and expansion, to large-scale generation verification, and finally to complete the commercial product release, the whole process is described as follows:

In this process, we are also continuing to contribute our strength to the open source community. For example, we submitted Dubbo support and RocketMQ support to the Envoy community, and resolved some community issues.

Why is the cloud native gateway called the next-generation gateway

1. Traditional gateway classification and deployment mode

In the industry, gateways are generally divided into two categories: traffic gateways and service gateways.

The traffic gateway mainly provides global policy configuration that has nothing to do with the back-end business. For example, Ali’s internal unified access gateway Tengine is a typical traffic gateway; the business gateway, as the name suggests, mainly provides independent business domain-level and back-end services. Business tightly coupled strategy configuration. As the application architecture model evolves from a single unit to the current distributed microservices, the business gateway has a new name-microservice gateway (illustrated below).

2. What core factors should the next generation gateway have?

In the cloud-native era dominated by container technology and K8s, will the next-generation gateway model still be the two-tier architecture of the traditional traffic gateway and microservice gateway?

With this question, combined with the gateway technology and operation and maintenance experience accumulated in Alibaba, we try to answer what is the next generation gateway.

Let's expand on some of the very core elements:

• Cloud native : To support the standard K8s Ingress, K8s Gateway API, and K8s service discovery, in the cloud native era, K8s has become a cloud OS, and the network inside and outside the K8s native cluster is isolated and is responsible for the entry of external traffic. The standard definition is K8s Ingress, and the K8s Gateway API is a further evolution of K8s Ingress. Based on this, as a next-generation gateway, it is bound to support this feature.
• embrace open source : To build a gateway based on an open source ecosystem, with the help of open source and help open source, I believe that everyone should be familiar with this.
• High expansion : The ability of any gateway can not cover all user requirements, and it must have expandability. For example, the booming development of K8s and its open expansion ability are indispensable.
• Service governance : As the application architecture evolves to distributed microservices, the gateway itself provides traffic scheduling capabilities for back-end services, and its ability to support basic service governance is natural.
• Rich observability : While the distributed microservice architecture brings benefits such as improved collaboration efficiency, it also brings greater challenges to troubleshooting and operation and maintenance. As a traffic bridgehead gateway, it needs to have rich observable data to help The user locates the problem.

Based on the above analysis and practice, we believe that under the microservice architecture in the virtualization era, the business usually adopts a two-tier architecture of traffic gateway + microservice gateway. The traffic gateway is responsible for north-south traffic scheduling and security protection, and the microservice gateway is responsible for things. In the cloud-native era dominated by containers and K8s, Ingress has become the gateway standard for the K8s ecosystem, giving the gateway a new mission, making it possible to combine traffic gateway + microservice gateway into one.

MSE-Advantages of Cloud Native Gateway

1. More economical: Combining the traffic gateway and the microservice gateway into one, the user resource cost is reduced by 50%

MSE-Cloud-native gateway, without any discount on the capacity, can not only save 50% of resource costs, but also reduce operation and maintenance and use costs. The schematic diagram of the deployment structure is as follows, the left is the traditional gateway mode, and the right is the next-generation cloud native gateway mode.

In the context of microservices, rich observable capabilities are also the basic core demands of users. Based on this, MSE-Cloud Native Gateway integrates the Alibaba Cloud application real-time monitoring service ARMS by default, providing rich observable data, and this function is effective for users. free.

2. More secure: Provides a wealth of authentication and authentication capabilities to reduce the cost of secure access for customers

Authentication authentication is the rigid demand of customers for the gateway. MSE-Cloud Native Gateway not only provides regular JWT authentication, but also provides OIDC authentication based on the authorized open network standard OAuth 2.0. At the same time, MSE-Cloud Native Gateway naturally supports Alibaba Cloud's application identity service IDaaS help customers achieve Alipay, Taobao, Tmall and other third-party authentication logins, and support to extend the authentication and authentication functions through plug-ins. , in order to reduce the customer's security access cost. The existing authentication functions are as follows:

3. More unified: the gateway is directly connected to the back-end service, opens up multiple service sources of Nacos/Eureka/K8s, and is the first to support the Apache Dubbo3.0 protocol

Open source has become one of the driving forces to promote software development, and community-oriented, open commercial products have more vitality.

Envoy is one of the most popular Ingress implementations in the K8s community, and it is becoming the standard technical solution for traffic portals in the cloud-native era. MSE cloud native gateway is built on Envoy and Istio to achieve a unified control plane control, and is directly connected to back-end services, supports Dubbo3.0 and Nacos, opens up Alibaba Cloud Container Service ACK, and automatically synchronizes service registration information. MSE Cloud Native Gateway supports Dubbo 3.0 and Nacos and has taken the lead in the Dingding business. The following figure shows the deployment diagram of Dingding Dubbo 3.0 as follows:

4. More stable: The technology has been accumulated for a long time, and it has passed the test of 2020 Double 11, carrying hundreds of thousands of requests per second

Commercial products are not overnight.

The 16194af83534f7 MSE cloud native gateway has already experienced is currently used in Ali’s business systems such as Alipay, Dingding, Taobao, Tmall, Youku, Fliggy, Word of Mouth, etc., and passed the test of the massive requests for Double 11 in 2020, and the big promotion day can easily carry hundreds of thousands per second. The number of requests per day has reached the level of tens of billions.

The cloud native gateway can currently cover all business scenarios in north-south and east-west directions, that is, it can support traditional registration centers such as Nacos, it can also support K8s Service, and it can also support traditional ECS. The following diagram illustrates the following:

Nginx gateway migration cloud native gateway practice case

1. Youku Nginx gateway migration case

Youku’s business has three gateways built with Nginx, and some business extensions have been made using Lua scripts. However, with the iteration of personnel, the operation and maintenance of the gateway has become more and more difficult, mainly including the difficulty of maintaining Lua scripts, non-real-time configuration changes, and more The difficulty of gateway operation and maintenance and the contradiction between configuration change reload and rapid business iteration are increasing. Therefore, we cooperated with the business to complete the smooth migration from the Nginx gateway to the cloud native gateway. In order to ensure smooth migration and low cost, the cloud native gateway has error page and other functions. As shown below:

After seeing the picture above, readers may ask why a two-tier gateway structure is used? Namely AServer (traffic gateway) + service self-built gateway.

This is because for Alibaba’s super-high-traffic business, a two-tier architecture is adopted. The traffic gateway is responsible for security protection. The cost of global traffic scheduling will be lower. There is no need for each business BU to do repetitive tasks. The business self-build gateway Hanging behind the traffic gateway can meet the requirements of fast iteration of the business itself; but for non-ultra-large-scale services, the use of a two-tier architecture will increase the complexity of operation and maintenance.

2. Ingress-nginx migration plan

Although the growth of users using the Envoy architecture ranks first in K8s Ingress Provider, it is undeniable that Ingress-nginx still occupies the largest share of K8s Ingress Provider, then whether the cloud native gateway can be compatible with Ingress-nginx configuration is Do users provide low-cost or even zero-cost migration solutions?

With this question, we also explored. Ingress-nginx did not use the method of defining a new CRD to extend the standard K8s Ingress capabilities, but used the method of Annotation. First, we analyzed the Annotation list of Ingress-nginx, as follows:

Prioritized according to user usage alignment. Among them, the Annotation cloud native gateways at high and medium levels already support automatic conversion. In addition to inserting code snippets and other Annotations related to the internal implementation of Nginx, we are also gradually supporting conversion. , The goal is to achieve zero-cost migration. A simplified diagram of the conversion process is as follows:

Write at the end

MSE-Cloud Native Gateway, aims to provide users with a more reliable, lower cost, and more efficient enterprise-level gateway product that meets the K8s Ingress standard. For more release details, move to the live room to watch: https://yqh .aliyun.com/live/detail/26484

MSE-Cloud Native Gateway provides two types of payment models: post-payment and annual and monthly subscription. It supports the 4 regions of Hangzhou, Shanghai, Beijing, and Shenzhen, and will gradually open up other regions.

Copyright Notice: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright, and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.