Shulou(Shulou.com)06/02 Report--

This article shows you what service governance based on MOSN and Istio Service Mesh is like, the content is concise and easy to understand, can definitely make your eyes bright, through the detailed introduction of this article, I hope you can get something.

ServiceMesh Webinar is an online live broadcast event jointly sponsored by the ServiceMesher community and CNCF. The event will be held from time to time to share knowledge and practices in the field of ServiceMesh.

This article is organized according to the online topic sharing "Service Governance practices based on MOSN and Istio Service Mesh" by Yao Changyu, senior back-end engineer and MOSN Committer of Service Mesh Webinar#2 Youmi Technology. The video review link and PPT download address of this sharing are included at the end of the article.

Another recommended live broadcast starts at 9: 00 tonight, and you can watch it at the bottom.

Preface

Hello, everyone. Welcome to the second phase of Service Mesh Webinar. The sharing theme of this issue is "Service Governance practices based on MOSN and Istio Service Mesh". I am today's sharing guest Yao Changyu, from Youmi Technology. At present, I am also responsible for service governance in the company. I am also a cloud enthusiast myself. I have paid attention to and participated in the Service Mesh community in my spare time. Recently, I have participated in the development of a new version of MOSN. This time, I was invited by the community to share this with you. I hope it can bring you a harvest.

Today's sharing will take place from the following aspects:

The first part will briefly introduce what is Service Mesh and what dividends Service Mesh can bring to us, as well as the process and some gains of my participation in the community.

The second part is the focus of this sharing. From a developer's point of view, I will talk about how to do service governance based on MOSN and Istio, which will include the analysis of MOSN source code and the actual operation of Istio functions. It is also a problem that many Service Mesh enthusiasts pay attention to, such as traffic control, service monitoring and so on.

The third part will summarize today's sharing and an introduction to some recent developments and future vision of MOSN.

Brief introduction of Service Mesh and sharing of community co-building practice

Introduction to Service Mesh

First of all, what is Service Mesh? I believe this is the first question when many enthusiasts first came into contact with Service Mesh. Service Mesh has been developed for so many years, and there are many articles introduced and analyzed on the Internet. Here, I would like to talk about it again. If you sum up Service Mesh in one sentence, I would say that it is a micro-service communication solution that is constantly evolving. As we all know, the server-side architecture has undergone a series of evolution, from the initial single service to SOA, and then to micro-service, the communication between services has also evolved from no communication at the beginning, to integration in code, and then to fat client library, and then evolved into Service Mesh's network stub pattern, or sidecar pattern. Service Mesh mainly solves several problems in the previous inter-service communication solution: language binding; difficulty in upgrading; repeated development, different standards; and language binding: before the service governance logic is extracted from Sidecar, these governance logic needs to be integrated into the code. This can easily lead to business being tied to the same development language or maintaining multiple copies of the same logic and different languages. This is not flexible, and the cost of maintenance is relatively high. Upgrade difficulty: the infrastructure team in the enterprise needs to push various businesses to restart their services after upgrading the service governance logic. Such a cycle is usually very long, and there will be various problems in the restart process. As a result, the governance functions of different versions of the online version are inconsistent, and it is very difficult to land. Repeated development and different standards: each company will implement micro-services according to their actual situation, and some will use mature micro-service frameworks in various languages, such as Java's Spring Cloud, Dubbo; or Golang's go-micro. Some teams may use the approach of integrating components, adding some mature service governance components, such as Consul, Zookeeper, Hytrix, Vault, etc., to each language. In general, it takes a certain development cost to abstract a micro-service control plane by docking these components, and these frameworks and component standards are inconsistent, and there will be a lot of cost to maintain.

So how does Service Mesh solve these problems?

First, the Service Mesh architecture removes the logic of service governance into a separate Sidecar process, while the Sidecar process is language-independent. Sidecar hijacks the traffic of business processes in the form of agents, so as to decouple from the specific business development language. Second, Sidecar is deployed together with the business process through the side car mode, but is separate from the business process. The Sidecar process can restart updates at any time, and the business process does not need to be aware of this process. This can speed up the process of updating governance logic and solve the difficult problem of traditional service governance and upgrading. Finally, Service Mesh defines the concept of control plane and data plane. The control plane provides UI to the operator to control the flow of the entire cluster. The data plane, as its name implies, is the plane of data flow, which is responsible for receiving the configuration information and showing the corresponding agent behavior. The control plane and the data plane communicate through a unified protocol, that is, the xDS protocol in Service Mesh to exchange configuration information. In this way, it is theoretically realized that the control plane / data plane of xDS protocol can be plugged and replaced each other, which unifies the standard and solves the third problem of repeated development and different standards.

With so much community co-building experience sharing, how did I move from following the Service Mesh community to participating in MOSN open source co-building? I feel that the whole process can be summarized into three points: finding the organization; accumulating knowledge; participating in contribution; in fact, I was also a beginner at the beginning, and when I first came into contact with Service Mesh, I would be bewildered by a lot of unknown nouns, such as xDS, control surface, metrics tracing and so on. Fortunately, ServiceMesher's Chinese community is quite complete and active. I believe that some students who have known Service mesh must have added two Wechat posts-one is Song Jing Chao Song Da Wechat, and the other is the WeChat group of ServiceMesher community. It is also due to the fact that many predecessors have maintained the ServiceMesher Chinese community so well, sharing a variety of internal practices, as well as external first-hand information handling and even translation, and even such irregular online and offline sharing. These are very good resources. As long as you want to learn, there must be a way. As for the newcomers' questions, the great gods in the community are also very happy to answer them. Now that we have goals and resources, we need to do it. Then I continue to understand the concepts of these new areas, understand their meaning and behind the design purpose and application scenarios, coupled with source code analysis and hands-on practice, slowly build the whole knowledge system about Service Mesh. After figuring out the way, it is not difficult to participate in the development. Then why did I choose MOSN? In fact, Ant Group has an open source co-construction plan for the entire SOFAStack, that is, a financial-level cloud native architecture, including service registration, traffic tracking, rpc protocols, distributed transactions, and so on. I chose MOSN mainly for two considerations: first, MOSN is implemented using Golang, which is consistent with the personal technology stack; second, I think the position of Sidecar in Mesh is more critical. In large clusters, millions of Sidecar communicate with each other in the cluster, forwarding and processing data packets for business processes, and their stability, performance requirements and flexibility are relatively high; recently, I have also participated in the Istio Roadmap development of MOSN, the main goal is to seamlessly connect MOSN to Istio and become a Sidecar that can work inside. My main functions are the adaptation of pilot-agent and the development of consistent hash load balancing. In fact, it is similar to doing business requirements, first to know what the function is going to achieve, then to rehearse the changes, and finally to practice: fork a MOSN, develop code, improve unit tests, and submit PR. When doing a rehearsal for the consistent hash function, I also went over the details of this algorithm because of the use of Google's maglev algorithm. In the later practice, I found a third-party library used, with some performance problems. Because this function works in a request-routing process, we must not add too long RTT to the request. I also made a round of performance optimization of the third-party library, and finally reached the available state, and proposed a PR to the third-party library. I think the biggest gain is the technical improvement and sense of achievement brought about by working with the great gods. To sum up, this is my understanding of Service Mesh and some of my own processes of participating in the community.

Practice of Service Governance based on MOSN and Istio

Next is the second part of this sharing, how to combine MOSN and Istio to do service governance.

The first step in practice is to make the environment run. My development environment chose Linux. My main consideration is that the Linux environment is more similar to the production environment, and you can use the host machine to run Docker and K8s directly, and run the image packaged by the host directly. On the Mac and Windows platforms, Docker and the host are separated by a layer of virtual machines, and the K8s environment is also difficult to install. In this way, as long as the MOSN image is packaged and MOSN is configured with the yaml configuration of Istio, there are only two steps to compile and execute MOSN debugging, which saves the time-consuming process of push and pull images on Mac and Windows platforms. For compiling MOSN, I hack a makefile of MOSN, mainly adding a task like me. First of all, he will go to build-local, that is, compile the go source code of MOSN into MOSN binaries, and then package the binaries into the image of MOSN proxyv2. This proxyv2 is similar to the proxyv2 image of Isito, except that the Sidecar in it is replaced by MOSN. The third step is to compile pilot-agent. Since MOSN is started by pilot-agent in Istio, it is sometimes necessary to log in pilot-agent when debugging the functions of MOSN combined with Istio, such as to see if pilotagent starts MOSN properly. So I also cloned the source code of Isito and recompiled pilot-agent when needed. Finally, step 4, restart the corresponding pod. For example, delete the ingressgateway and restart it here. Since I need to debug the function of MOSN, I will change the image of ingressgateway to the image of my debugging MOSN after installing Istio. MOSN currently supports the Istio1.5 version, so the local environment I demonstrated this time is also version 1.5. We also need to modify the configmap injected by Isito Sidecar so that when we execute Istioctl kube-inject to inject Sidecar into the business, we can also use MOSN as the Sidecar proxy. Specifically, here, add the parameters of binaryPath, and change the tag here to the mirror tag,1.5.2-mosn-dist I compiled. So after the above steps, an environment where MOSN is combined with Istio is running. This time, I will put the relevant services and images and the corresponding yaml configuration in webinar2 democode, the git repository, and the required partners can clone them by themselves. Demo: https://github.com/trainyao/webinar2_democode next, I will show how to use MOSN combined with Istio to achieve the following functions: traffic management; gRPC routing function; current limit; fault injection; observability; request tracking; metric collection; the actual Demo demonstration can be explained in detail in the video. These are some of the practices of MOSN combined with Istio services governance, which I hope will give you some inspiration and help.

Summary

This Webinar is almost over. Finally, to summarize the content of this sharing, first briefly introduce the basic concepts of Service Mesh de and what specific problems are solved: the language binding of micro-service governance, the difficulty of updating, and the problem of inconsistent standards. Later, I also introduced the process and some thoughts from paying attention to participating in community development.

Then it comes to the field code section, which shows how to run MOSN with Istio and build a local development and debugging environment. It then demonstrates the ability to implement service governance in Istio using MOSN, including traffic management and service visualization. I hope the above sharing content is helpful to you! In the end, I would also like to share the current situation of MOSN, that is, the features of the new version and future plans. MOSN recently released version 0.14.0, and details can be found on MOSN's github release note. This version of https://github.com/mosn/mosn/releases/tag/v0.14.0g mainly does more work to support Istio, such as supporting Istio version 1.5, upgrading go-control-plane,sourcelabel support, consistent hash load balancing, etc., as well as optimizing performance and fixing known bug. At the same time, we are also promoting Istio officials to promote the development of general data plane standards, in the near future, Isito or Service Mesh users will no longer be limited by Envoy, there will be more choices on the data side. Next, MOSN will continue to align the functions of Istio and become a secure, stable and powerful cloud soundtrack data surface proxy that can work in Service Mesh. As can be seen in the previous sharing content, MOSN still has a lot of room for improvement, and you are welcome to join us if you are interested in ideas and mention issue and PR to MOSN. The above is what service governance based on MOSN and Istio Service Mesh is like. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.