云原生世界中的隐形人如何拥抱 Istio

Posted 2021-04-13 伪架构师

一直想给我所从事的企业服务行业写点啥，又千头万绪不知从何说起。此次 KubeCon 上海一行，眼见 CNCF 高起朱楼大宴宾客，深受触动。企业服务这个巨大的“角落”，似乎已被遗忘。本文尝试给云原生时代的同学们讲讲这个似乎有点蒙昧的角落。也希望能给奋斗在企业服务项目中的朋友们一点启发。

谁是隐形人

身为一个企业服务部门的 IT 工人，在为甲方殚精竭虑的同时，经常有一种跟世界脱节的感觉：流量经济持续不断的冲刷之下，微服务、云原生等新的架构和概念如火如荼；大咖说、InfoQ 等各色机构的活动也是越来越多；新技术产品和新技术偶像层出不穷。云原生时代以来，更大的困扰出现了：漫山遍野的“免费”、“开源”技术，似乎难于学习、无力推进、更不要说做出贡献了。

• 产品一般称为 “XXXX 管理系统”。

• 在甲方自有数据中心或托管服务器上运行。

• 硬件利用率不高，相对硬件规模来说，业务规模相当小。

• 令出多头，一些工作内容可能需要多个公司/部门之间的配合。

• 基础设施群之间，通常会采用传统的多分区、白名单系统来保证隔离。

• 开发环境和生产环境之间经常会没有高速网络连接。

• 上线活动需逐级审批、定时定点停服更新。

• …

在这种令人惶惑的情形之下，CNCF、微服务浪潮的出现更加剧了隐形人们的生存危机。尤其是台上大佬们大声疾呼——XX 产品那德行，不改还能用？这种时候，隐形人就更害怕了——我还没学会安装那！大佬们已经上手改了！还怎么活啊！

几个问题

开源软件到底能不能用

首先要相信，世界上是很有些聪明人的。

Apache 和 CNCF 都有严格的准入控制，对成熟度有明确的要求，同时热度够高的项目通常会吸引较多的高水平贡献者加入。高成熟度的系统。质量总体来说还是有一定保障的。

大佬说不改就不能用是个什么情况

这通常是来自百度阿里京东蚂蚁等流量大厂的大佬们的呐喊，并不算是危言耸听。但是有个前提，就是国内几个巨头的流量和应用特点，都是属于极端情况。通常说来，并不会有哪个开源组织，有闲心又有能力，丧心病狂的做出能丢给几大厂一个直接可用适用的大系统。反过来说，经过大厂魔改的系统，很可能不再具备原有版本的普适性以及升级能力。作为透明人的 Istio 体验，应该遵循应用和 Istio 都无伤的做法。

等前辈们踩过了坑我们再上会更稳妥

这是个很不现实的想法，各家公司各个项目的情况千差万别，这些坑还是要自己踩的，多数情况下没人能够用微信帮你完成工作。

生产应用/性能问题/..解决了么

其实这跟上一个问题是一体的，通常需要用户自行严格按照生产环境标准进行相应的测试。

这里有一个前提，如果采用新的系统对现有系统的性能是有影响的，那么首先应该保证，技术团队有能力应对现有的业务负载，这样通过对新系统的学习，才能够有一个合适的技术基础。对一个服务进行容器化改造，不要希望它的容器化成功之后，立刻就出现十倍的性能提升。稳妥的方式是水平迁移稳定之后，才进一步的挖掘新技术的性能潜力。

我们没有上 Kubernetes

这一点上，我认为答案很简单，Istio 并不适合你。

Istio 的试点

这两天学习了小剑同学在上海 ServiceMesh Meetup 上的演讲，在仰望蚁人们在面临棘手情况时展露出来的强大实力的同时，也有一些窃喜——在我们隐形人的隐形系统中，可没这么多麻烦。我们只求在原装系统的支持下，获得其有限的好处。

为什么采用 Istio

首先要判断的是，这一系统对我们来说有什么好处，除了官方各种宣传之外，可能还会有一些边际效应，例如采用新系统带来的光环、声明式操作提高了对环境和配置的控制能力等。Istio 的官宣好处非常之多，然而按照开源系统通常的晚熟状况，我们可以仅挑选一些对我们促进最大的亮点来进行验证和测试，对于一些难于掌握的复杂特性或不稳定特性，可以徐徐图之——或者叫眼不见为净。

而存量应用经常会比较落后于时代，经过各种补丁和重构，以及或真或假的微服务改造之后，往往会变成杂乱不堪的应用丛林；经过 Kubernetes 迁移之后，得益于 K8S 的支持，具备了容器调度、服务注册和发现、初步的配置管理等能力。

服务监控和跟踪（高性价比，推荐）

现存应用的监控和跟踪通常都是比较欠缺的，Istio 能轻松的为应用注入这两种能力，熟悉 Istio 的用户可能会质疑，分布式跟踪还是要求对代码做出一定改动的，本着能不动就不动的原则，仅获取一对一调用的跟踪信息，也是一个巨大的进步。在这一功能的基础上形成的统一 Dashboard 对存量应用的增值会有非常大的帮助。

流量控制（高性价比，推荐）

这是 Istio 的核心功能，应该也是使用率最高的功能，这一功能有效的增强了基于 K8S 的应用支撑，对存量应用的通信控制大幅增强。并且在新应用的开发中，可以协助架构师将部分通信细节延后到部署和运维阶段来实现，也降低了新应用的开发难度。流量控制能力中的超时和重发等小功能，都能很好的提高存量应用的健壮性；而路由部分还为现有应用提供了金丝雀发布和蓝绿部署之类的新能力。

边缘通信（刚需可用）

这部分的功能通常会使用硬件负载均衡和其它相关的基础设施来实现，因此可以暂不考虑。

mTLS 和访问控制（刚需可用）

这部分功能在我们的情况中较少遇到，内网中的服务经常是无需访问控制和加密的，因此仅在存在刚需时候可以尝试使用。

限流等其它 Mixer 功能（慎用）

Mixer 是 Istio 中比较遭人诟病的一个组件，强大但是难于驾驭，并且具体实现又依赖于各个 Adapter，因此这部分功能建议押后采纳。

试点服务的选择

Sidecar 注入导致的延迟是众所周知的，因此我们会选择调用链条较短、延迟不很敏感的应用来进行试点。

准备工作

环境准备

1. 检查 Kubernetes 版本是否符合要求。

2. 检查试点应用的 Service 是否符合注入要求。

3. 为试点应用在负载均衡或其它类似基础设施上做好切换准备，防止故障无法恢复。

4. 获取 Istio 镜像文件并上传到私库。

安装 Istio

备份 values.yaml 并部署 Istio，根据实际情况为 Dashboard 等管理功能设置 Ingress/NodePort 等开放方式。

应用部署

1. 加大试点应用的 Deployment 中的实例数量，降低 Istio 开销造成的损耗。

2. 为试点应用编写缺省路由和目标规则。和 Kubernetes 资源等同样纳入交付物的版本管理中。

3. 如果使用的是 CI/CD，建议在其中加入注入环节。

部署完成之后，应该进行功能、压力、疲劳等一系列测试，来完成验证。

应用上线

负载均衡进行切换，将 Istio 转入生产服务。

结论

以上步骤执行下来，最终我们用较小的代价，换来较大的系统改观，让传统应用像服务网格一样的运行了起来。另外在系统负载较低的情况下，Istio 的稳定性还是比较有保障的。最终，我们也保留了随时回滚的能力。