Service Mesh 的出现主要被用于解决微服务架构下出现的问题，所以在阅读本文之前我比较建议先看下我介绍微服务的文档： ，里面有介绍相关的微服务问题痛点。 字节的服务组成的微服务部署与关系调用越来越复杂，这就导致如果加以管理与控制的话，随着复杂性的增加，整个字节架构与业务维护复杂性的成本会越来越高，如：安全调用的复杂性 / 服务发现的复杂性 / 部署的复杂性 / 调用关系网的复杂性 等等。
正如我在 中所提到并总结的，我认为当人们采用微服务时，人们会看到很多很普遍的问题，这其中很多问题都围绕着 网络 和 可观察性 。而这些具有通用性的问题，目前却是在各个微服务框架中去提供能力解决的，这就导致服务治理实现的不一致；监控打点标准的不一致；网络通信协议的不一致性；策略不一致；安全合规不一致 等等不一致的问题。
- 服务治理不一致
- 由于在不同框架 / 不同语言间，维护团队不同，实现细节不同，导致实现后的功能效果与性能不一致，甚至功能缺失。
- 监控打点标准的不一致
- 由于在不同框架 / 不同语言间，维护团队不同，实现细节不同，导致实现后的打点内容 / 打点查询方式不一致，甚至打点指标缺失。
- 网络通信协议不一致
- 由于不同框架之间的协议不同，导致框架之间需要做各类协议的适配
- 策略不一致
- 许多团队在不同的位置使用各类不同的工具去指定策略。（这里策略说的比较笼统，需要解释下）这增加了调用链路整体策略失败的风险（因为各不一致行为），这也增加了修改策略的工作（需要在各处各工具间切换），并且你还需要确保所有策略是否正常 work（而各种工具的验证方式又各不相同）。
- 安全合规不一致
- 公司采用 DevOps + 微服务架构后，我们的团队迭代速度可以变得更快，这也意味着可以更快地将产品应用推向市场，但也为企业带来更大的风险。为什么？你虽然很快，但是你犯错误也会变得很快，当公司因为挂站和安全漏洞受到巨大影响的时候，我们的竞争对手就会抢走本属于我们的客户。
- 我们渐渐意识到，只有敏捷性已经不足以帮助公司获得成功。我们需要敏捷 + 安全稳定才能够支撑公司成为业界第一。那么，谁统一负责了解和管理公司的安全性和合规性要求？这就是我们需要解决的问题。
那么既然这些问题这么通用，而目前各类实现有各不一致，那么我们就需要采用更加通用且一致的方式去解决这些问题。我们在 2016 年底注意到了 service mesh 技术，但是那个时候的 service mesh 所能做的很少，但是我们依旧在持续关注，等待技术成熟。架构组在 2018 年的时候正式决定将 service mesh 技术引入公司，并投入人力进行自研 bytemesh。
首先介绍下我对 Service Mesh 的理解：
| 本质 | 抽象了网络的一种方式 |
| 目标 | 标准化 + 透明 |
| 从上可以看到 service mesh 其实是在对网络有控制能力的基础上，做到标准化 / 透明的将能力进行交付。我们可以从中看到 3 各关键词：网络控制 / 标准化 / 透明。 |
- 网络 ：首先我们回顾下上文可以知道微服务很多问题都是围绕网络与可观测性，我们拥有的强大的网络控制就能够较为统一的处理微服务网络问题
- 标准化 ：当我们有能力统一处理问题时候，我们就需要设置处理问题的标准能力，以解决目前各类不一致的问题。
- 透明 ：是指要对业务是基本无感知的，这样接入的时候就能够非常方便，接入的方便性也将会帮助我们将 mesh 应用到更广泛的不同类型的服务当中。第二就是升级无感知，这样我们的 mesh 在升级的时候就可以在不影响业务的前提下为业务提供更好的新的技术支持。
我们从下图中看到 mesh 的应用对解决微服务复杂性问题有更好的表现：
随着应用程序 复杂性 的增加，service mesh 的表现更优
我们分析了微服务架构带来的问题，以及为了应对这些问题引入一种叫做 service mesh 的技术来解决，我们也介绍了 mesh 的核心与目标来方便我们理解这种技术，接下来简单介绍下实践情况。 在理想的世界中，业务团队可以 专注于他们的业务逻辑 ，而将平台问题留给一个 集中管理 和 标准化 的 service mesh。业界的一般方法是将 service mesh 分为 2 部分：data panel 与 control panel。
- data panel（数据面）：是一个伴随业务进程一起启动的 proxy，用于代理业务的所有进出流量，目前业界主流为 envoy（支持 L7 网络流量代理，拥有灵活强大的网络控制能力）。data panel 的出现实现了我们之前希望统一解决微服务网络通信等问题目标，data panel 由于代理了业务的所有进出流量，就可以统一对流量作出标准一致的行为。
- control panel（控制面）：是用于统一管理 service mesh 所有服务的动态配置信息，这些配置信息最终会下发到各个 mesh proxy（data panel）端，我们就是利用动态修改这些配置来控制 proxy 端的动作行为。
Service Mesh 的功能可以分为三类：流量管理，安全性，可观察性。这些功能的实现可以帮助我们解决上述微服务架构的一些列不一致问题。
- 流量管理的出现，可以解决服务治理不一致 / 网络通信协议不一致
- 安全性的出现，可以解决安全合规不一致 / 策略不一致
- 可监控性的出现，可以解决监控打点标准的不一致
基础架构标提供的 service mesh 能够标准化的执行以上能力，这样就将安全控制，流量管理和可观察性的挑战从业务开发人员手中解放出来，交给基础架构来进行集中管理（当然重点不是基础架构，耳而是集中管理哈）。 Service mesh 为业务开发人员提供了丰富的功能，例如服务发现，客户端负载均衡，超时，重试，熔断等（具体可参考：，这里包含了 mesh 的实现具体功能介绍），无论业务服务框架或语言如何，接入 service mesh 后，这些能力就都能够获得。Service mesh 也为流量路由，策略实施以及强身份（身份验证和授权）和安全性（加密，mTLS）提供了一组 L7 控制，帮助服务更加安全合规。
以上就是我大概想要讲述的一些内容，谢谢。
