我们为什么要远离Service Mesh

注：本文说的是基于Sidecar的Service Mesh。实际上，当前Service Mesh的实现方式也只有Sidecar这种方式。如果有新的Service Mesh的实现方式，我们不排除回归Service Mesh的可能性。

在网上，你会看到关于Service Mesh的各种各样的好处。的确，这些Service Mesh的好处的确是存在的。但是，这些好处是有代价的。

软件行业里为了宣传自己的产品的好处，但是很少提及它的代价，是常态。

我们团队规模不大。业务量也不大。使用Service Mesh整整两年了。我想我们还是有一些发言权的。以下是我总结的Service Mesh的代价：

1. 招人难：你需要招的是同时熟悉K8s和Service Mesh的实现的人，这样的人，像我们这种小团队，根本招不到。特别是现在绝大部分Service Mesh是基于Envoy，这个C++写的proxy。了解Envoy的人，就少之又少了。

2. 升级Service Mesh过程痛苦：Service Mesh的升级依赖于你的K8s的版本，而K8s的版本升级又可能拉扯出N个依赖问题。而且还不能将Service Mesh一次性升得太高级。因为它需要更高级的K8s。

   
   

   这还只是Service Mesh本身的升级。如果你升级好了Service Mesh，它还要求你的业务应用进行滚动更新，因为业务应用的Pod中的sidecar也要升级。如果团队的配置管理及自动化不成熟，这种痛苦，我认为是加倍的。

   
   

对于第2点，现实中肯定很多团队无法接受。因为并不是所有团队都能做滚动更新且不影响业务。

那么，该如何移除Service Mesh呢？以下是我们的过渡方案：

我们会另建一个Namespace2，然后将其它应用逐渐部署到Namespace2。中间通过网关进行代理。当然，并不是说你只能有一个网关。

通过这种渐进的方式，我们的业务不受影响。

为什么中间还要经过一个网关？因为通过网关，我们可以相对低成本的实现金丝雀发布、故障注入等Service Mesh该有的功能。

后记

由于我们绝大部分的配置都是代码化的，且部署也是自动化的。所以，我们的迁移的成本是可以接受的。迁移成本就是要将原来Service Mesh部分的配置转化成网关上的配置。

最后，如果您希望加入“持续交付实践指南”的微信群，可以添加 zhaizhijun0 微信，他会拉你进群。

往期好文推荐：

• Google 云架构的可靠性原则

• SRE认知升级之可用性的本质