# 2020年，落地 Service Mesh 还有那些问题 ？ 

## 前言

从2017年 Istio 横空出世到 2020年 多款 Service Mesh 产品面世，似乎就像当年 Docker 的一样，毫无疑问 Service Mesh 重新定义了微服务治理，目前也依然是 Sevice Mesh的事实标准。然而，即使 Istio 宣称2020年中的 1.7 版本是一个真正产线可用的版本，它依然存在诸多问题。就像 Docker 的荣光已经被 Kubernetes 遮盖，Istio 是否也会像 Docker一样，从第一个吃螃蟹的人变成探路者呢?


## 拿着锤子找钉子
2020年我有幸在公司参与了 istio 的落地项目，虽然最终成功落地，但是过程曲折，结果也并不那么完美。我们在早期做技术调研的时候，大家对于 Service Mesh的理论都已经了解，但是如何落地，怎么去从现有的微服务架构迁移，是一个非常痛苦的思考和探索的过程。不像 Kubernetes 那样，有完整的解决方案，我们面临最大的问题是，我们在Kubernetes集群里安装好了Istio，接下来我们要怎么用Istio？没有人会告诉你，我们只能自己探索 我们就像是拿着锤子到处找钉子的工人，在不断的尝试后，我们才知道如何做到服务名调用，如何充分利用Istio的流量管理来实现灰度发布，流量治理，基于istio-gateway+mTLS来做到跨集群调用，通过Kiali来将网络链路可视化，通过Skywalking来做链路性能监测和分析，并将他们集成到现有的微服务治理系统中。


## 新老系统的迁移
当然，还有一个落地Istio不得不面对的问题：新老系统的迁移。服务迁移的过程是非常漫长的，我们有线上有几百个微服务，需要很多的人力和时间去整理现有的调用链路以及迁移过程中的兼容处理，因为互联网的业务不像传统IT服务，它不会给你停机维护的机会。虽然我们从前的微服务已经运行在容器环境下，但是迁移的最大问题并不在于容器化，而在于调用链路的变化。即使在我们花了很多时间去整理迁移方案，迁移的过程中问题也是层出不穷，除了整理过程中的遗漏和一些历史包袱，一些服务的迁移还涉及到存储的变化，这也是我们最初没有考虑到的。所以我们只能一边迁移，一边发现问题并尽快解决。所以，一旦决定要落地Istio，必须要做好长期的迁移规划。

## 复杂链路下的延迟增加与资源占用
sidecar解放了不同开发语言下的微服务的治理，但是却带来了新的问题。微服务架构下的网络链路必然会随着系统的迭代变得愈加复杂，而每个请求经过的sidecar代理的数量也越来越多，即使envoy作为一个高效的网络代理，单个sidecar带来的延迟可以忽略不计，但是如果链路复杂，envoy带来的延迟就不能忽略了。我们在实际的测试中，迁移到服务网格后，请求的平均延时增加了约20%，由于我们团队并没有足够的时间和人力去优化Envoy和重新开发sidecar代理，但是开弓没有回头箭，我们没得选择。 但是有时候这样的延时是业务难以忍受的，这种情况下，我们不得不在部分业务中，暂时放弃服务网格。除此之外，Envoy作为一个代理却并不轻量：在我们的微服务中，有很大部分的微服务初始内存cpu资源占用并不高，甚至在很多时候，这些服务的sidecar的资源占用甚至超过了应用容器本身，这是一件很有意思的事情。所以这种业务场景，我们其实开始考虑使用serverless，毕竟，service mesh也并不是银弹，在解决研发痛点的同时，也应该考虑成本。

## sidecar容器的启动、关闭顺序
sidecar容器启动、结束的顺序的问题自isito发布以来就存在：由于应用容器的流量都需要经过sidecar容器，如果sidecar容器后于应用容器启动，那么就会存在一段时间应用容器中的请求无法发送；而停止容器时，如果应用容器后于sidecar容器终止服务，即使应用容器能够优雅关闭，那么也会有部分请求由于sidecar容器先停止而无法发送。当然，这个问题的主要原因不在于Istio，而是Kubernetes并没有提供有效的机制去保证。随着Istio1.7的发布，sidecar容器的启动顺序的问题已经通过 `preStart lifecycle`得以解决，而sidecar的关闭的问题，则只能等待 Kubernetes 未来的` sidecar lifecycle` 来解决。

## 流量管理的细化
相比于Kubernetes本身，Istio对于流量的管理的功能已经很细致了。在传统的Kubernetes下，如果要实现对应比例金丝雀发布，只能以Pod级别来控制流量，而使用Istio则可以通过`VirtualService`很轻松地做到网络层面流量的控制，从而不必保持Pod的比例，可以放心的扩缩容。但是，有些场景下的流量治理，却扔需要更加细化的功能。比如服务作为RESTFul API的提供者，有时候仅仅需要针对某个接口进行限流或者熔断，而Istio的限流和熔断是针对的是应用服务级别的，如果要利用Isito的功能，只能把微服务拆的更加细化，这反而有些违背了Isito的无侵入应用的思想。所以，如果要让Istio和微服务结合的更好，还有很多路要走。

## 商标与商业化的争议

2020 年 7 月 8 日，Istio 社区官方博客发文称，将把Istio 项目商标的所有权转让给 Open Usage Commons 组织，而 OUC 是是谷歌刚刚宣布成立的一个组织，专注于以符合开放源码定义的方式提供开源项目商标的管理和指导。但是，作为Istio的创始方之一，IBM对于这个决定并不满，认为其违背了当初厂商中立的约定，没有将项目捐献给CNCF。事实上，有了Kubernetes的前车之鉴，我们很容易理解 Google的作法：Google 开源了 Kubernetes，却并没有从中获取到太多利益，反而让 AWS这样的云厂商通过 Kubernetes赚的盆满钵满。然而正是因为Kubernetes事实上的厂商中立，才得以使得Kubernetes得到众多的云厂商支持，从而得以发扬光大。商业化的争议，可能对Service Mesh 技术的影响有限，但是对于 Istio 本身，随着其他 Service Mesh 厂商的发力和 Service Mesh 标准的确立，可能反而会影响到Istio的地位。


## 结语
虽然目前Istio存在些许问题，但是从我们落地的经验来看，Istio给我们带来的收益是非常大的。多语言下的微服务治理能力的下沉，解放了我们的基础架构研发人员，不必再去化大量时间去维护和升级不同语言的SDK；而istio带来的流量治理能力，让我们很轻松地有了蓝绿、金丝雀发布的能力；同时依托于Istio的双向 mTLS、服务访问控制能力，我们对于应用安全和多云多中心下的服务治理也有了充分的保障。