注:本文说的是基于Sidecar的Service Mesh。实际上,当前Service Mesh的实现方式也只有Sidecar这种方式。如果有新的Service Mesh的实现方式,我们不排除回归Service Mesh的可能性。
在网上,你会看到关于Service Mesh的各种各样的好处。的确,这些Service Mesh的好处的确是存在的。但是,这些好处是有代价的。
软件行业里为了宣传自己的产品的好处,但是很少提及它的代价,是常态。
我们团队规模不大。业务量也不大。使用Service Mesh整整两年了。我想我们还是有一些发言权的。以下是我总结的Service Mesh的代价:
-
招人难:你需要招的是同时熟悉K8s和Service Mesh的实现的人,这样的人,像我们这种小团队,根本招不到。特别是现在绝大部分Service Mesh是基于Envoy,这个C++写的proxy。了解Envoy的人,就少之又少了。
-
升级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 微信,他会拉你进群。
往期好文推荐:
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/70949.html