共计 5472 个字符，预计需要花费 14 分钟才能阅读完成。
Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联结发动的线上直播流动，流动将不定期举办，为大家带来 Service Mesh 畛域的常识和实际分享。
本文依据 7 月 22 日晚 Service Mesh Webinar#2 有米科技高级后端工程师、MOSN Committer 姚昌宇，线上主题分享《基于 MOSN 和 Istio Service Mesh 的服务治理实际》整顿，文末蕴含本次分享的视频回顾链接以及 PPT 下载地址。
前言
大家好, 欢送大家加入第二期 Service Mesh Webinar。本期的分享主题是《基于 MOSN 和 Istio Service Mesh 的服务治理实际》。我是明天的分享嘉宾姚昌宇，来自有米科技，目前在公司也是负责服务治理相干的工作，我自身也是一名云原生爱好者，在空余工夫关注和参加 Service Mesh 社区，最近参加了 MOSN 新版本的开发，也是有了很多播种。这次受社区邀请来给大家做这次分享，心愿能给大家带来播种。
明天的分享将从以下几个方面进行：
- 第一局部会简略介绍一下什么是 Service Mesh、Service Mesh 能够给咱们带来什么红利以及我参加社区的过程和一些播种；
- 第二局部是这次分享的重点，我会从一个开发者的角度，说说如何基于 MOSN 和 Istio 去做服务治理，两头会包含 MOSN 源码的剖析和 Istio 性能的实操，也是比拟多 Service Mesh 爱好者关注的如何落地的问题，比方流量的管制啊、服务监控等等的性能；
- 第三局部会总结一下明天的分享以及 MOSN 一些近况和将来愿景的介绍；
Service Mesh 简介以及社区共建实际分享
Service Mesh 简介
首先，什么是 Service Mesh 呢？置信这是泛滥爱好者刚接触 Service Mesh 时的最后疑难。Service Mesh 倒退了这么多年，网上介绍和剖析的文章也是很多，在这里我也再啰嗦一句。如果用一句话来概括 Service Mesh，我会说，它是一种微服务的通信计划，是一直演进而成的。
大家都晓得，服务端架构经验了一系列的演进，从最开始的单体服务到 SOA，再到微服务，服务间通信也从最开始的无需通信、到集成在代码里、再到胖客户端库，再演进为 Service Mesh 的 network stub 模式，又或者称为 sidecar 模式。
Service Mesh 次要解决了之前的服务间通信计划的几个问题：
- 语言绑定；
- 降级艰难；
- 反复开发、规范不一；
语言绑定：在将服务治理逻辑抽离到 Sidecar 之前，这些治理逻辑须要集成在代码外面。这就容易导致业务要么要绑死在同一种开发语言上，要么就要雷同的逻辑不同语言保护多份。这样既不灵便，保护起来老本也比拟大。
降级艰难：企业里的基础设施团队，在降级服务治理逻辑之后，须要推动各个业务去重启他们的服务，这样一个周期通常会拖的十分长，重启过程也会有各种问题，导致线上各个版本的治理性能不统一，落地起来相当吃力。
反复开发、规范不一：每个公司都会依据他们的理论状况落地微服务，有的会应用各个语言比拟成熟的微服务框架，比方 Java 的 Spring Cloud、Dubbo；或者 Golang 的 go-micro 之类的框架。有的团队或者会应用集成组件的形式，在各个语言的根底上，加上一些成熟的服务治理组件，比方 Consul、Zookeeper、Hytrix、Vault 等。通常，通过对接这些组件来形象出一个相似于微服务管制立体须要肯定的开发成本，而且这些框架和组件规范也是不统一的，保护起来也会有不少老本。
那么，Service Mesh 是如何解决这些问题的呢？
首先，Service Mesh 架构将服务治理的逻辑抽离到一个独自的 Sidecar 过程中，而 Sidecar 过程是与语言无关的。Sidecar 通过代理的模式劫持业务过程的流量，从而做到与具体的业务开发语言解耦。
其次，Sidecar 通过边车模式和业务过程部署在一起，然而又与业务过程拆散。Sidecar 过程能够随时重启更新，业务过程无需感知这个过程。这样能够减速治理逻辑更新换代的过程，解决了传统服务治理，降级艰难的问题。
最初，Service Mesh 定义了管制面和数据面的概念。管制面提供 UI 给操作者去管制整个集群的流量，数据面，顾名思义就是数据流动的立体，负责接管这些配置信息，体现出对应的代理行为。管制面和数据面通过对立的协定进行通信，也就是 Service Mesh 里的 xDS 协定来替换配置信息。通过这样的形式，实践上实现了 xDS 协定的管制面 / 数据面能够相互插拔替换，这就对立了规范，解决了第三点反复开发和规范不一的问题。
社区共建经验分享
那了这么多，那我是如何从关注 Service Mesh 社区，到参加到 MOSN 开源共建的呢？感觉整个过程能够概括成 3 点：
- 找到组织；
- 常识积攒；
- 参加奉献；
其实一开始我也是一个初学者，刚接触到 Service Mesh 也会被一大堆不出名的名词砸得昏头昏脑的，像是 xDS、管制面、metrics tracing 之类的名词。所幸的是，ServiceMesher 的中文社区相当欠缺和沉闷。我置信有理解过 Service mesh 的同学，必定有加过 2 个微信 — 一个就是宋净超宋大的微信，一个就是 ServiceMesher 社区的微信群。也是得益于泛滥的前辈将 ServiceMesher 中文社区保护的这么好，将各种外部实际分享进来，以及内部一手资讯搬运甚至翻译过去，乃至是这样子的不定期的线上线下分享。这些都是十分好的资源。只有你想去学，就必定有办法的。而对于新人的疑难，社区里的大神们也是十分乐意解答。
既然有了指标和资源，那就差去做了。接下来我通过一直的去了解这些新畛域的概念，了解它们的含意和背地的设计目标以及利用场景，再加上源码剖析和入手实际，缓缓也就搭建起了整个对于 Service Mesh 的常识体系。
在摸清门道之后，其实参加开发也不是什么难事了。那为什么我会抉择 MOSN 呢？其实蚂蚁团体有整个 SOFAStack，也就是金融级云原生架构的开源共建打算，其中有服务注册、流量跟踪、rpc 协定、分布式事务等等的我的项目。我抉择 MOSN 次要是有两点思考：
- 第一是 MOSN 是应用 Golang 实现的，这一点和集体的技术栈比拟吻合；
- 那第二点，我认为 Sidecar 在 Mesh 的地位是比拟要害的。在大型的集群里，上百万的 Sidecar 在集群里相互通信，为业务过程转发解决数据包，其稳定性、性能要求和灵活性都是比拟高的；
近期我也参加到了 MOSN 的 Istio Roadmap 开发中，次要指标是将 MOSN 无 缝地接入到 Istio 里，成为在外面能够工作的 Sidecar。我次要做的几个性能是 pilot-agent 的适配以及一致性哈希负载平衡性能的开发。其实和做业务需要是相似的，首先要晓得性能要达到什么目标，而后预演改变的中央，最初实际：fork 一份 MOSN、开发代码、欠缺单元测试、提交 PR。在做一致性哈希性能预演的时候，因为会用到 Google 的 maglev 算法，我还去看了一遍这个算法的细则。前期实际的时候，发现了一个用到的第三方的库，有一些的性能问题。因为这个性能工作在一个申请的 – 路由解决的过程，肯定不能给申请减少太长的 RTT，我还把第三方库做了一轮性能优化，最初达到可用的状态，给第三方库提了个 PR。
最大的播种，我感觉是和大神们共事带来的技术晋升以及成就感。
总结一下，以上就是我对 Service Mesh 的了解以及我本人参加社区的一些过程。
基于 MOSN 和 Istio 的服务治理实操
接下来是本次分享的第二局部，如何联合 MOSN 和 Istio 去做服务治理。
实操的第一步，首先是把环境跑起来。我的开发环境抉择的是 Linux。我次要思考的点是，Linux 环境和生产环境更类似，而且能够间接应用宿主机跑 Docker 和 K8s，间接运行宿主机打包进去的镜像。而 Mac 和 Windows 平台下 Docker 和宿主机是隔了一层虚拟机的，而且 K8s 环境也比拟难装置。这样只有打包好 MOSN 镜像，配置好 MOSN 联合 Istio 的 yaml 配置，对 MOSN 的调试就只剩下编译和执行两个步骤了，能够省去在 Mac 和 Windows 平台还要 push、pull 镜像的耗时过程。
对于编译 MOSN，我 hack 了一句 MOSN 的 makefile，次要是加了 me 这样的一个工作，首先他会去 build-local，也就是将 MOSN 的 go 源码编译成 MOSN 二进制文件，而后将二进制文件打包进 MOSN proxyv2 的镜像外面。这个 proxyv2 和 Isito 的 proxyv2 镜像是相似的，只不过外面的 Sidecar 换成了 MOSN。
第三步，编译一遍 pilot-agent。因为 MOSN 在 Istio 外面是由 pilot-agent 启动的，在调试 MOSN 联合 Istio 的性能时，有时也须要在 pilot-agent 里打日志，比方看一下 pilotagent 有没有失常启动 MOSN。所以我也将 Isito 的源码克隆了下来，并且在须要的时候从新编译 pilot-agent。
最初是第四步，重启对应的 pod。比方这里就将 ingressgateway 删掉重新启动。因为须要调试 MOSN 的性能，在装置好 Istio 后我会将 ingressgateway 的镜像也改为我调试 MOSN 的镜像。
MOSN 目前反对 Istio1.5 的版本，所以我这次演示的本地环境也是 1.5 版本的。咱们还须要批改一下 Isito Sidecar 注入的 configmap，这样咱们在执行 Istioctl kube-inject 给业务注入 Sidecar 的时候，也能用上 MOSN 作为 Sidecar 代理。具体是在这里，加上 binaryPath 的参数，以及将这里的 tag 改成我编译进去的镜像 tag，1.5.2-mosn-dist。
那么通过下面的步骤，一个 MOSN 联合 Istio 的环境就跑起来了。
这次代码实操的相干服务和镜像以及对应的 yaml 配置，我会放到 webinar2 democode 这个 git 仓库外面，须要的小伙伴也能够自行去克隆下来看看。
Demo：https://github.com/trainyao/webinar2_democode
那接下来，我会展现一下，如何应用 MOSN 联合 Istio 来实现以下性能：
流量治理；
- gRPC 路由性能；
- 限流；
- 故障注入；
可察看性；
- 申请跟踪；
- 指标收集；
具体的理论 Demo 演示能够看视频详解。以上就是 MOSN 联合 Istio 服务治理的一些实际，心愿对你有一些启发和帮忙。
总结
本次 Webinar 也差不多靠近序幕了。最初来总结一下这次分享的内容，首先简略介绍 Service Mesh de 基本概念以及诞生是为了解决什么具体问题：微服务治理的语言绑定、更新艰难、以及规范不对立的问题。前面还介绍了我从关注到参加社区开发的过程和一些思考。
而后到了现场撸码的局部，展现了如何将 MOSN 联合 Istio 运行起来并且搭建一个本地的开发调试环境。之后还展现了而后应用 MOSN 在 Istio 里实现服务治理的性能，包含流量治理和服务可视化的性能。
心愿下面的分享内容对你有所帮忙！
那么在最初还想分享一下 MOSN 的近况，也就是新版本的性能以及将来打算。
MOSN 最近公布了 0.14.0 版本，具体信息大家也能够在 MOSN 的 github release note 看到。
https://github.com/mosn/mosn/releases/tag/v0.14.0
这个版本次要是做了比拟多反对 Istio 的工作，比方反对 Istio 1.5 版本，降级了 go-control-plane，sourcelabel 反对，一致性哈希负载平衡等等，也优化了性能和修复了已知的 bug。同时，咱们也在推动 Istio 官网去促成通用数据面规范的制订，在不久的未来，Isito 或者是 Service Mesh 用户也不再会受限于 Envoy，在数据面上会有更多的抉择。
接下来，MOSN 也会持续对齐 Istio 的性能，成为能够在 Service Mesh 里工作的平安、稳固、功能强大的云原声数据面代理。也如后面的分享内容所见，MOSN 还有很多能够欠缺的中央，也欢送各位有想法有趣味的小伙伴退出，给 MOSN 提 issue 和 PR 吧。
本次的分享就到这里了，感激你的凝听。更多有对于 Service Mesh 和流动的信息，大家能够关注 SOFAStack“金融级分布式架构”和“ServiceMesher”的微信公众号，外面有各种 Service Mesh 的一手资讯。另外在 8 月 15 号在深圳，蚂蚁团体的 MOSN 负责人毅松会带来一场主题分享《云原生网络代理 MOSN 的进化之路》，感兴趣的小伙伴也能够理解一下。
流动详情：http://giac.msup.com.cn/Giac/schedule/course?id=14579
作者介绍
姚昌宇，有米科技高级后端工程师、MOSN Committer，多年后端开发教训、云原生爱好者。目前负责公司外部数据和算法能力接口的服务治理相干的开发工作，2018 年起关注并参加 ServiceMesher 社区发动的各种流动，近期参加 MOSN v0.14.0 版本性能的开发。
本期直播视频回顾地址
没赶上直播的同学也能够看回顾视频，在看完视频后欢送填写本期视频的有奖问卷调研，给到咱们对于本期直播的反馈，反对社区直播越来越好～
- 本期视频回顾：https://www.bilibili.com/video/BV1AZ4y1g7nF/
- 有奖问卷调研：http://sofastack.mikecrm.com/N6eWjyX
