How to use Nacos to build a service grid ecosystem?

Introduction to Nacos in Alibaba originated from the colorful stone project in 2008 (the project completed the micro-service split and the construction of the middle stage of the business). The scalability and high availability of the service solves the scalability problem of millions of instances (10w->100w instances). In 2018, we deeply felt the influence of the open source software industry, so we decided to open source Nacos, exporting Ali's ten years of accumulation of service discovery and piping management, promoting the development of the microservice industry, and accelerating the digital transformation of enterprises. With the development of cloud native technology in recent years and the proposal of service grid technology, more and more companies are trying to migrate the microservice architecture to the service grid architecture. This has put forward a new demand for Nacos, that is, how to upgrade Good support for the service grid ecosystem.

Author | Huaicheng

Introduction to Nacos

Nacos /nɑ:kəʊs/ is the first letter N a ming and C The goal is to build a dynamic service discovery, configuration management, and service management platform that is easier to build cloud-native applications.

Nacos in Alibaba originated from the Cobblestone project in 2008 (the project completed the split of microservices and the construction of the middle stage of the business), and grew up in the ten-year peak test of Alibaba Double Eleven. This stage mainly helps the business solve the scalability of microservices. And the problem of high availability solves the scalability problem of millions of instances (10w->100w instances). In 2018, we deeply felt the influence of the open source software industry, so we decided to open source Nacos, exporting Ali's ten years of accumulation of service discovery and piping management, promoting the development of the microservice industry, and accelerating the digital transformation of enterprises.

With the development of cloud native technology in recent years and the proposal of service grid technology, more and more companies are trying to migrate the microservice architecture to the service grid architecture. This has put forward a new demand for Nacos, that is, how to upgrade Good support for the service grid ecosystem.

Nacos seamlessly supports service mesh

Let's first look at the architecture under Microservice 1.0. Traffic comes in from Tengine, passes through the microservice gateway, and then enters the microservice system.

Here is an explanation of why it is divided into two layers of gateways. The first layer of Tegine is responsible for the access of traffic. The core capabilities are anti-large traffic, security protection and support for https certificates, and the pursuit of versatility, stability and high performance. The second layer is the microservice gateway, which focuses on microservice-related capabilities such as authentication, service governance, protocol conversion, and dynamic routing. For example, the open source spring cloud gateway and zuul all belong to the microservice gateway.

After the traffic enters the microservice system, the calls between services will be implemented through the microservice framework, such as hsf/dubbo, spring cloud, etc., then the core role of Nacos here is the service discovery capability. For example, cousumer will first obtain the provider from Nacos And then initiate the call, and the microservice gateway will also obtain the upstream service list through Nacos. These capabilities are mainly provided through the SDK. At the same time, some load balancing and load protection strategies will be added to the SDK.

The microservice 1.0 architecture mainly has the following problems:

1. Tengine does not support dynamic configuration, including the open source Nginx natively. Ali internally implements configuration changes by reloading configuration regularly, which results in configuration changes that cannot be changed in time, which affects R&D efficiency;
2. In the Fat SDK mode, the logic of service governance and service discovery is strongly coupled with the SDK. If the logic needs to be changed, the SDK must be modified to promote the upgrade of the business side;
3. Under multiple languages, it is necessary to maintain SDKs in different languages, which is costly and it is difficult to unify service governance strategies.

With the development of cloud native technology and the proposal of the microservice 2.0 architecture, many companies are trying to solve the problems in the microservice 1.0 architecture through service grid technology. In the microservice architecture 2.0 architecture, traffic is accessed through the ingress gateway and enters the microservice system. Unlike the 1.0 architecture, the data plane Envoy and the control plane Istio are introduced.

Envoy is deployed in the same Pod as the application in Sidecar mode, which hijacks the incoming and outgoing traffic of the application, and then can achieve flow control, security, and observability through the XDS configuration issued by the control plane Istio. The advantage of this architecture is to manage the service Capabilities are decoupled from business logic, and most of the capabilities of the SDK in the service framework are stripped out and moved to Sidecar, which also realizes unified governance of different languages.

The service grid technology has many advantages, but the introduction of new architectures will also bring new problems, especially for companies with heavy technical burdens, they will face problems, such as: sidecar performance issues, private protocol support issues, new and old architecture systems How to smoothly migrate and so on.

This article focuses on the smooth migration of the old and new architecture systems. Two issues related to service discovery that a smooth migration will inevitably face:

1. How do the old and new architecture systems discover each other, because the two systems must coexist in the migration process, and applications need to call each other;
2. How does the registry support the microservice grid ecosystem, because istio currently supports the k8s service discovery mechanism by default;

Let’s look at how to solve these problems in the Nacos service grid ecosystem. The architecture diagram is as follows. It can also conform to the cloud native architecture and support the K8s standard ingress gateway), and then enter the microservice system. The 1.0 application (non-mesh application) and the meshed application coexist in the microservice system.

Let's first look at how non-mesh applications can access applications that have been meshed.

From this architecture diagram, you can see that non-mesh applications are still registered or subscribed to services from Nacos through the SDK, and the providers that have been meshed will also be registered on Nacos, so that non-mesh applications can also get meshed For application service information, the provider registration service is generally through the SDK method, because the open source envoy does not support the proxy registration function. Of course, when we implemented it internally in Alibaba, we have actually subverted the service registration capability to the sidecar.

Another question is how the service discovery of meshed applications is done.

We can look at the lower part of the architecture diagram. Nacos already supports the capabilities of the MCP server. Istio obtains the full list of service information from Nacos through the MCP protocol, and then converts it into XDS configuration and sends it to envoy, which supports meshing In-app service discovery can also access non-mesh services. In the process of meshing services, service discovery can be seamlessly migrated without any modification.

Here is a brief introduction to the MCP protocol. The MCP protocol is a configuration synchronization protocol between components proposed by the Istio community. This protocol was abandoned after 1.8. The alternative is the MCP over XDS protocol. Both Nacos protocols are compatible.

In addition to the MCP protocol synchronization solution, there are other solutions to synchronize the service data of the registry to the ServiceMesh system. We have compared these solutions, as described in the following figure:

Nacos Service Grid Ecosystem Alibaba Landing Practice

Finally, I will introduce you to the practice of Alibaba's Nacos service grid ecology. The following picture summarizes the two scenarios of Alibaba's landing.

Scene 1:

The scenario of DingTalk cloud and group intercommunication is actually the application interoperability in the hybrid cloud scenario. We use a gateway to connect these two environments. DingTalk vpc (Alibaba Cloud deployment) uses the MSE cloud native gateway. The group uses the Envoy gateway, and they use Dubbo3.0's triple protocol for network communication. The control plane of the gateway uses Istio. Istio will synchronize service list data from Nacos through the MCP protocol.

Using this architecture solves two problems:

1. Private cloud and public cloud network communication security issues, because the gateways use mtls to encrypt communication;

2. Smooth support for the microservice architecture, because the application calls the gateway through the triple protocol, and does not require business code changes, and the service discovery uses Nacos mcp to synchronize data;

This set of architecture is also used in the ant group intercommunication scene. It is on the left side of this picture. The ant gateway uses the Mosn on Envoy architecture.

Scene 2:

The group’s microservice mesh scenario corresponds to the middle and lower part of this picture. The difference between the internal landing and the community is that Envoy directly connects to the Nacos registry. The use of this solution is mainly due to performance issues. Some of our applications will have several Wan's instance IP, if pushed through EDS, because the data volume is too large, it will cause problems such as high CPU of Istio OOM or Envoy data plane.

This article is a text compilation of the Nacos service grid ecological live broadcast. For the complete live broadcast content, please refer to: https://yqh.aliyun.com/live/detail/26211

Nacos source code repository: https://github.com/alibaba/nacos

Copyright Statement: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and 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.