企业服务行业如何试水 Istio | Service Mesh Meetup 分享实录-CSDN博客

崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。
本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。
本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。

Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。
企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：

开发、运维、基础设施所属
人员结构、水平和年龄
资源使用率差别
架构和平台一致性
负载能力
...

目前进行 Service Mesh 布道的主力还是互联网行业的旗手们，一味追求跟进互联网同行们的进度和做法，颇有邯郸学步的风险。
本文中将会针对目前 Service Mesh 方面的一些普遍问题和关注热点发表一些个人意见。并尝试提供一种 Istio 的试用思路，给乙方同行们提供参考。

Istio 的功能

无需赘述，多数用户都很清楚，Istio 使用和应用共享网络栈的方式，利用 Iptables 劫持应用的网络流量，从而在不修改业务源码的情况下，完成一系列的功能：

监控服务质量
控制服务间的访问路由
应对服务故障
在服务间通信之间进行加密
访问控制和频率限制

分布式跟踪和业务紧密相关，无法做到无侵入。

这其中最大的优势就是无侵入，这意味着给试用流程留下了全身而退的机会，如果没有回滚的能力，上述种种能力都是空中楼阁。

Istio 的问题

API 稳定性可能是最严重的一个问题。目前最成熟的功能组别应该是流量控制，其版本号也仅是 v1alpha3，一般来说，alpha 阶段的产品，代表着不提供向后兼容的承诺，流量控制 API 在从 v1alpha2 升级为 v1alpha3 的过程中，API 几乎全部改写，使得很多早期用户的精力投入付诸东流。核心功能尚且如此，遑论相对比较边缘的 Mixer、Citadel 以及 Galley 组件的相关内容。
发布节奏和发布质量的问题也相当严重。Istio并不算长的历史中，出现了多次版本撤回、大版本严重延期、发布质量低下无法使用以及 Bug 反复等状况，这无疑会让每次升级尝试都充满了不确定性，会很大的影响生产过程的连续性。
Mixer 是一个问题焦点，其数据模型较为复杂，并且集中了所有应用的流量于一点，虽然其中加入了各种缓存等技术来降低延迟，但是其独特地位决定了 Mixer 始终处于一个高风险的位置。同时其 API 结构稍显混乱，重构风险较大。
Pilot的性能方面也经常为人诟病，虽然经过几次升级，但是即使是 1.0 之后，还是出现了两次 Pilot 在集群中服务/Pod 过多的情况下会超量消耗资源的问题。
安全、物理机和虚拟机的支持以及网格边缘通信这三组功能，目前用户较少，质量尚不明确。
最后就是 Istio 的 Sidecar 注入模式，这种模式一定会增加服务间调用的网络延迟，在目前阶段这是一个痼疾，Sidecar 的固定延迟和 Mixer 的不确定行为相结合，有可能会产生严重后果。

这里提出的只是被反复提及，或者经常出现在 Issue 列表中的问题，由发布问题来看，面临的风险可能远不止这些。

Istio 试用工作的理由和规划

试用 Istio，首先应该确定，该技术的采用，是否能够在可控的风险和投入下，得到有效的产出。

微服务模式的推进，必须要有相应的管理能力，Service Mesh 目前看来，是一个确定有效的方案，如果不是 Istio，也会有其它替代产品出现。
目前看来，Istio 是 Service Mesh 的标志性产品，有一定可能性成为事实标准。
提供了众多开箱即用的丰富特性，能够迅速进入 Service mesh。
最后是无侵入的优势：如果试用失败，可以退回，控制损失范围。

Istio 的多数功能，在无需对程序进行修改（分布式跟踪除外）的情况下，能对应用提供如此之多的功能支持，无疑是非常有吸引力的。Istio 的功能集，完全可以说是服务网格技术的典范。一旦确认现有环境有可能支持 Istio 的运行，并且在合理的投入下能够获得有效益的产出，那么这个试用就是有价值的。
结合 Istio 的现状，以及多数企业的运行状态，个人浅见，Istio 的应用在现阶段只能小范围试探性地进行，在进行过程中要严格定义试用范围，严控各个流程。按照个人经验，笔者将试用过程分为如下 4 个阶段。

范围定义：选择进入试用的服务，确定受影响的范围，并根据 Istio 项目现状决定预备使用的 Istio 相关功能。围绕这些需要，制定试用需求。
方案部署：根据范围定义的决策，制定和执行相关的部署工作。其中包含 Istio 自身的部署和业务服务、后备服务的部署工作。
测试验证：根据既有业务目标对部署结果进行测试。
切换演练：防御措施，用于在业务失败时切回到原有的稳定环境。

Istio 的试用步骤

确定功能范围

在 Istio 中包含了非常多的功能点，从原则上来说，各种功能都是有其实际作用的。然而，Istio 作为一个新产品，本身也有很多不足，我们在 10.1 节中也提到了这些不足。
Istio 提供的众多功能对每个公司或者项目，都会有不同价值。我们在采用一个新系统时，首先要考虑的就是性价比问题，这里的“价”代表着 Istio 带来的风险、对业务应用的影响，还包括可能出现的服务停机等问题。
可以根据性价比，做出一个优先级别列表。在制定了优先级列表之后，就可以根据这一列表，结合项目的实际需求，按照效果明显、功能稳定、部署成本低、少改造或者不改造的标准来进行选择，最终确定待测试的功能点。
在选定功能点之后，应该遵循目前已有的 Istio 文档，对各个功能点进行单项测试和验证，以确保其有效性。并通过官方 GitHub 的 Issue 列表及讨论组内容，了解现有功能是否存在待解决的问题，以及相关的注意事项等。

选择试用业务

在试用功能点确定之后，就要选择用于试用的业务应用了。Istio 作为一个相对底层的系统，其部署和调试过程必然会对业务产生一定的影响，在运行阶段又有 Sidecar 和各个组件造成的损耗，如下所述：

所有网格之间的通信都要经过 Sidecar 的中转，会造成大约 10 毫秒的延迟。
Pilot 对集群规模敏感，集群中的服务数量、Pod 数量都可能对 Pilot 造成较大影响，也会影响到 Istio 各种规则向 Pod 的传输过程。
所有流量都会经由 Mixer 处理，也有造成瓶颈的可能。
安全功能设置不当同样会造成服务中断。

如上所述还只是个概要，对业务来说，对这些风险都是必须正视并做好预案的。为了避免引起过大损失，建议将如下标准作为选择试用服务的依据：

能够容忍一定的中断时间。
对延迟不敏感。
调用深度较浅。
能够方便地回滚和切换。
具备成熟完善的功能、性能和疲劳测试方案。

定义试用目标

按照现有业务的实际需要，对试用服务进行功能分析。和传统的需求功能分析类似，要在该过程中明确一些具体的需求内容。

环境需求：申请符合 Istio 运行以及业务要求的集群以及资源。
功能性需求：在 Istio 的功能中选择需要 Istio 为试用服务提供支撑的功能，应形成功能测试案例。
服务质量需求：根据现有业务的运行状况，对服务质量提出具体要求，例如并发数量、响应时间、成功率等，应形成性能测试案例。
故障处理需求：对于试点应用发生故障时，如何在网格和非网格版本的试用服务之间进行切换以降低故障影响，应形成故障预案。

Istio 部署

首先是基本环境的准备，按照前面提到的环境需求，复查集群环境。如果是内网部署，应该部署内网可达的私有镜像库，推送全部所需的镜像，并利用 Helm 变量设置合理的镜像地址。接下来根据试用需求，利用 Helm 对 Istio 部署进行调整，这方面的调整主要分为两类——资源分配和功能裁剪。

资源分配方面，在官方提供了资源分配建议可以参考，利用 Helm value 进行设置即可。
功能裁剪，同样需要对 Helm value 进行设置，关闭不需要的功能。

后备业务部署

在进行试用应用的注入之前，首先应该部署一组备份服务，这组服务需要和整体服务网格进行隔离。这一组备份服务应处于待机模式，以备网格版本的应用在出现故障时，进行整体切换。基于这一点考虑，负载均衡等前端控制设施也应齐备。

试用业务部署

接下来要把试用服务部署到网格之中，同其他 Kubernetes 一样，网格应用的部署也是从 YAML 代码开始的。原有应用的部署代码需要根据 Istio 标准进行复核，检查其中的端口命名、标签设置。
除了待注入的应用清单文件，还应该为每个部署单元都提供默认的 VirtualService 和 DestinationRule，建立基本的路由关系，提供一个路由基准，方便在路由调整过程中进行对比。
然后根据在前面制定的具体网格需求列表，逐个编写所需的路由、规则等方面的配置内容。在这些都完成之后，就可以按照顺序逐个提交部署了。

监控告警部署

在试用服务部署之后，就有更多的项目可以监测了，这里建议将其自带的 Prometheus 进行变更，连接到能够有效发出告警的 Alert manager 组件上，并根据试用业务的服务质量、Istio 组件进行告警设置。

验证测试

根据功能需求对试用服务进行功能测试，在测试通过之后进行性能和疲劳测试，观察各方面的性能指标是否符合，如果性能出现下滑，则可以尝试扩容，提高资源分配率。
关键组件的性能下降有可能是 Istio 自身的问题，应检查社区 Issue 或提出新的 Issue。
此处是一个关键步骤，如果测试方案不符合实际情况或者预期目标无法达到，则强烈建议放弃试用。

切换演练

在功能和性能测试全部通过之后，就应该进行试用服务和后备服务之间的双向切换的演练，在双方切换之后都应该重复进行验证过程，防止故障反复。切换演练是试点应用的最后一道保险，在网格严重故障之后能否迅速恢复业务，全靠这一步的支持，因此同样需要认真对待。

结论

虽然很多企业服务团队的研发能力不高，无法像一些高水平技术团队一样，对开源软件进行因地制宜的适应性修改。然而需要理解的重要一点是，不少软件项目其实并非为世界级的流量而生的，互联网 Say No 的时候，其它场景中未必无法接受。通过细致的调查研究，详尽的方案设计，谨慎的执行和验证之后，Service Mesh 或者其它的新技术的试用决策都是可以进行尝试的，甚至也是有可能因此获利的。

PPT 下载和视频地址
点击页面回顾按钮，回顾当天所有讲师分享：
https://tech.antfin.com/activities/72

延伸阅读