Introduction: The following will explain to you how the cloud native gateway can help you solve a series of pain points and gracefully play with the upgrade of the microservice architecture on the cloud.
Author: Baizhang
With the development of cloud-native technology, the architecture selection of microservices is also changing with each passing day. In the cloud era where Kubernetes reshapes the operation and maintenance system, we have higher requirements and more choices in terms of security, cost reduction and efficiency improvement, and refined operations. The once-popular Zuul/SpringCloud Gateway/Kong, etc. began to seem powerless in their gateway positions. They lack the ability to discover container services, their performance may not be as good as Nginx Ingress, and observability, security, and other aspects require secondary development and reintegration. These key shortcomings hinder the development of technology. Today, let’s take a look at how cloud native gateways can help you solve these pain points and gracefully upgrade the microservice architecture on the cloud.
Development of Microservices (Gateways)
Milestones in Microservices Development
With the summary of Martin Fowler's article in 2014 [1 ] The concept of "microservice" began to gradually gain popularity. After that, all kinds of open source or commercial support sprang up like mushrooms after the rain, and now the author has simply sorted out the annual memorabilia by year. Two of the changes are worth paying attention to:
- Microservices evolve from single point support to platform solutions, such as SpringCloud solutions and Kubernetes systems.
- Open source and commercial products are more closely integrated, and the development of cloud native allows technology practitioners to have more choices.
Changes to Microservice Gateways
The author has compiled a few simple comparisons by time:
- 2013 ZUUL: Netflix's open source load balancing component is simple and easy to use, but the performance limit of the early ZUUL 1 is slightly lower.
- 2015 KONG: Nginx-based API gateway with strong performance and relatively few domestic Lua developers.
- 2016 SpringCloud Gateway: Gateways began to appear as a facade for the entire microservice solution.
- 2019 Ambassador (now named Emissaey-ingress): Supports the Kubernetes ingress standard and integrates seamlessly with Istio.
As microservices gradually develop into platform solutions, there is also a higher demand for the integration capabilities of gateways. This is why we have seen this trend, and cloud native gateways have emerged as the times require, and cloud native gateways not only integrate their advantages, but also have more functions, stronger performance, stability and reliability.
Kubernetes Microservices
Why is the Kubernetes microservice mentioned separately here? This requires going back to the microservice architecture without Kubernetes. What problems did we encounter?
- After the microservices are split, the corresponding construction and deployment workload begins to double, and the operation and maintenance pressure increases sharply;
- With business iteration, the call links between microservices become more complex, the strong and weak dependencies are unclear, and fault/bottleneck troubleshooting is difficult;
- Different business teams use heterogeneous service frameworks or technology stacks, which increases the cost of interdependence and integration.
Reasonable splitting of services can reduce the cost of collaboration and control the risk of change. This is the value brought by the idea of microservices. However, there are also huge governance difficulties and operation and maintenance pressures that follow.
However, Kubernetes seems to have solved many of our problems with its complete standard definition of network, service, and load balancing.
Unified service definition and service discovery mechanism
Thanks to Kubernetes' network model and Pod standard, Kubernetes Service can abstract applications running on a set of Pods [2 ] into network services (Kubernetes microservices), and you can use unfamiliar service discovery without modifying the application mechanism. Kubernetes provides Pods with their own IP addresses, and provides a set of Pods with the same DNS name, and can load balance among them.
Userspace proxy mode:
iptables proxy mode:
IPVS proxy mode:
Load Balancing Ingress Standard
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.
With the operation and maintenance scheduling capabilities of containers and Kubernetes, as well as the foundation of standard services and load balancing, the microservice architecture can develop to a higher level and meet more technical scenarios.
Technology Trends and Pain Points
High requirements and options in the cloud-native era
Kubernetes is good. At the same time, its huge system and many conceptual standards also bring learning costs to technical practitioners. DevOps seems to have a lot more workload than before. Fortunately, in the cloud-native era, commercial products meet high requirements. It also gives us more options.
The above figure shows that there are usually three parts in the code: business code, third-party software, and code that handles non-functional features. Among them, "business code" refers to the code that implements business logic; "three-party software" refers to all three-party libraries that business code depends on, including business libraries and basic libraries; "processing non-functional code" refers to the realization of high availability, security, and observability. Code for non-functional capabilities such as sex.
From a technical point of view, cloud-native architecture is a set of architectural principles and design patterns based on cloud-native technology, which aims to maximize the stripping of non-business code in cloud applications, so that cloud facilities can take over the original applications in the application. A large number of non-functional features (such as elasticity, resilience, security, observability, grayscale, etc.) make the business no longer troubled by non-functional business interruption, and at the same time, it has the characteristics of light weight, agility, and high automation.
The need for refined operations
The microservice architecture has developed all the way, from a simple split service to a service discovery mechanism, to supporting the sidecar proxy governance traffic, what is the final form? Or what are our technical needs?
simple split
service discovery mechanism
Sidecar proxy traffic
Cloud Native Architecture Maturity Model & API Security Quality Report
In the cloud-native era, the cloud-native microservice system will make full use of the high availability and security system of cloud resources, so that applications can obtain more guaranteed elasticity, availability, and security. The application is built on the infrastructure and basic services provided by the cloud, making full use of the convenience and stability brought by the cloud service and reducing the complexity of the application architecture. The cloud-native microservice system will also help to upgrade the application architecture in an all-round way, so that the application naturally has better observability, controllability, fault tolerance and other characteristics.
We may need a model similar to the above to describe the maturity of the architecture in the dimensions of serviceability, elasticity, observability, and automation. Although this is relatively comprehensive, it does not seem to be suitable for summarizing and communicating. If described with simple concepts, the author summarizes several stages:
- Extreme elasticity : Resiliency is an important means to deal with sudden traffic. Whether the extreme corresponds to the recovery speed of failures, and elasticity sometimes depends on the degree of service.
- Observable experience : After being able to deal with burst traffic, start to focus on performance optimization and troubleshooting. Systematic observable experience and indicator data are crucial to our governance.
- Self-healing without inductance of faults : If you can find problems in 360 degrees, you can summarize the rules and formulate common plans and inspection mechanisms, and routine faults can be automatically recovered.
The most important result measurement is the experience of our users. It should be the API security quality report that better represents the user . If the availability of the API is improved, and if the response RT of the API is reduced, this obviously shows that the architecture upgrade/governance has brought us It brings huge value to meet the needs of refined operations.
Pain points of architecture upgrade
The value of architecture upgrades (governance) is obvious to all, and we even have a closed-loop methodology for the continuous evolution of related architectures.
As the facade of the technical architecture, the gateway is very important in the measurement of the overall maturity of the architecture and the compatibility of sustainable evolution and integration. It is a good choice to use the gateway as the entry point for architecture governance upgrades. However, some pain points are still real. Before us:
- How to find problems with the current microservice architecture?
- Does deploying a microservice gateway after Kubernetes Ingress affect performance?
- Can user login authentication logic be centrally processed/upgraded?
- Can multiple Kubernetes clusters share a gateway?
- How to use SpringCloud and Kubernetes svc at the same time grayscale?
Here are just a few examples. You have a deep understanding of the actual pain points. Open source products often do not match our business needs. Let's see how the cloud native gateway solves these problems.
Advantages of Cloud Native Gateways
Cloud native gateway = traffic gateway + microservice gateway + ?
Cloud native gateways have been emphasizing since the beginning, combining traffic gateways (Kubernetes Ingress, Nginx) and microservice gateways (Spring Cloud Gateway, Zuul gateway, etc.) into one, reducing resource costs by 50%, shortening request time, and reducing operation. dimensional complexity.
Just 2-in-1 is obviously not enough to meet our expectations, let's see what else it has:
- Out of the box, it supports systematic observability capabilities such as global Kanban, instance monitoring, log retrieval, business TOP list, log delivery, link tracking and alarm management by default, allowing you to easily understand the quality of microservices and APIs.
- Excellent performance, see more powerful performance below.
- It supports the Ingress standard and is the preferred gateway product for the Kubernetes system.
- Multiple service discovery, supports ACK container service, Nacos and other service discovery methods, and can access multiple Kubernetes clusters at the same time.
- Based on the implementation of envoy+istio, it is perfectly compatible with service meshes, and the technology is the general trend.
more feature-rich
In addition to the systematic observability capabilities, there are also complete security protection capabilities, rich service/traffic governance capabilities, high-availability experience in large-scale production practices, and refined API management and expansion support.
more powerful performance
Pressure test results:
- The TPS of cloud native gateway is basically 2 times that of Spring Cloud Gateway and 5 times that of Zuul 1.
- The TPS of cloud native gateway is about 90% higher than that of Nginx Ingress.
Stable and more reliable
- Since its internal launch in 2020.5, the cloud native gateway has been used in Alipay, DingTalk, Taobao, Tmall, Youku, Fliggy, Koubei and other Ali business systems. The availability rate has been 100% for two years without any failures .
- After going through the test of massive requests on 2020 and 2021 Double 11 , the big promotion day can easily carry 100,000 requests per second, and the daily request volume reaches tens of billions.
Heavy functions emerge one after another
This article is original content of Alibaba Cloud and may not be reproduced without permission.