Why should microservice users use cloud native gateways?

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 Martin Fowler's 2014 article summarizing and sorting out [1] The concept of "microservices" has gradually become popular. 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:

1. Microservices evolve from single point support to platform solutions, such as SpringCloud solutions and Kubernetes systems.
2. 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:

1. 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.
2. 2015 KONG: Nginx-based API gateway with strong performance and relatively few domestic Lua developers.
3. 2016 SpringCloud Gateway: Gateways began to appear as a facade for the entire microservice solution.
4. 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. Cloud native gateways have emerged, and cloud native gateways have not only gathered their advantages, but also more functions, stronger performance, more stability and reliability.

Kubernetes Microservices

Why mention Kubernetes microservices separately here? This requires going back to the microservice architecture without Kubernetes. What problems did we encounter?

1. After the microservices are split, the corresponding construction and deployment workload begins to double, and the operation and maintenance pressure increases sharply;
2. With business iteration, the call links between microservices become more complex, the strong and weak dependencies are unclear, and fault/bottleneck troubleshooting is difficult;
3. 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), you can use unfamiliar applications without modifying the application. Service discovery 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:

1. Extreme elasticity : Resiliency is an important means to deal with burst traffic. Whether the extreme corresponds to the recovery speed of failures, elasticity sometimes depends on the degree of service.
2. experience : After being able to deal with burst traffic, we began to focus on performance optimization and troubleshooting. Systematic observable experience and indicator data are crucial to our governance.
3. non-inductive self-healing : 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 outcome measure is the experience of our users. A better representative of users should be the API security quality report . If the availability of the API increases, and if the response RT of the API decreases, this obviously means that the architecture upgrade/governance has We bring tremendous 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:

1. How to find problems with the current microservice architecture?
2. Does deploying a microservice gateway after Kubernetes Ingress affect performance?
3. Can user login authentication logic be centrally processed/upgraded?
4. Can multiple Kubernetes clusters share a gateway?
5. 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:

1. is ready to use out of the box, and 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.
2. Excellent performance, see below performance is more powerful.
3. It supports the Ingress standard and is the preferred gateway product for the Kubernetes system.
4. Multiple service discovery, supports ACK container service, Nacos and other service discovery methods, and can access multiple Kubernetes clusters at the same time.
5. 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 result:

• The TPS of the cloud native gateway is basically 2 times that of SpringCloud Gateway and 5 times that of Zuul 1.
• The TPS of the cloud native gateway is about 90% higher than that of the 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 of has been 100% in the past two years, and there has been no failure .
• After the test of 2020, 2021 Double 11 massive requests, can easily carry 100,000 requests per second, and the daily request volume reaches tens of billions.

Heavy functions emerge one after another

Related Links​

1. Martin Fowler's 2014 article summarizes and sorts

​​https://martinfowler.com/articles/microservices.html ​​

2.Pods​​

​​https://kubernetes.io/docs/concepts/workloads/pods/​​

Chinese New Year benefits, Hi Go 2022, buy now

You can also **DingTalk search group number 34754806 to join the user group to communicate and answer questions.

Click at the end of the for more details~

Enjoy 30% off MSE cloud native gateway prepaid full specification.