轻量ServiceMesh实践
徐亮
前言
UCloud 作为一家 To B 的公有云服务商，我们的 CTO 莫显峰经常说：“ 研发团队最首要的任务是提供稳定的服务，然后才是提供符合客户需求的、易用和低成本的产品 ”。但事实是，在提供稳定云服务的同时，面对快速发展的客户业务场景，我们还需要不断 “ 拥抱变化 ”。 Max Kanat-Alexander 在《简约之美：软件设计之道》（Code Simplicity）中提出的软件设计的 6 条法则恰到好处的描述了这一矛盾的事实，具体内容如下：
软件的目的是帮助他人；
相比降低开发成本，更重要的是降低维护成本；
变化定律：软件存在的时间越久，它的某部分需要变化的可能性越大；
缺陷定律：软件出现缺陷的可能性，正比于你对它所做修改的程度；
简洁定律：软件任一部分的维护难度，正比于该部分的复杂程度；
测试定律：你对软件行为的了解程度，等于你真正测试它的程度。
正像法则 1、3、4 和 6 所说的软件的目的就是满足客户的需求，而随着时间的推移，用户需求总会改变；伴随着用户需求的改变，软件也需要适应新的需求而做修改，修改必然会引入缺陷；如果要排除缺陷就必须进行测试。
但目前软件行业的现状大部分面临这样的问题，即无论花多大的成本去测试，真正的用户行为背后的需求总是不可能被完全满足的，缺陷总是会有的，这时我们最后的安全网就是 “ 灰度发布 ”（又名 “ 金丝雀发布 ”）。在采用用户真实行为作为终极测试的同时，通过控制变更范围尽可能的减少风险；一旦真的有缺陷可以快速回滚，尽可能以最大程度降低影响。
为何采用 ServiceMesh 实现灰度发布
Service Mesh 是用来处理各服务间通信的基础设施层。它主要通过构建云原生应用程序的各种复杂拓扑结构来完成传递请求。实际上，Service Mesh 通常与应用程序代码一起部署轻量级网络代理的阵列来实现请求。
在 ServiceMesh 之前，我们已经采用了 APIGateway 来实现灰度发布，但 APIGateway 通常仅部署在用户流量的入口，完全灰度发布就需要完整地部署两套系统。但是在微服务时代，任何一个微服务发生变更都需要完整地部署两套系统，这不仅成本很高而且严重影响了产品变更的速度。
而 ServiceMesh 正好可以解决这些问题，它的应用类似于将 APIGateway 部署到本地，同时提供了集中化控制，极大地简化了灰度发布的实现流程、降低了变更成本、同时加快了产品发布的进度。
为何采用轻量 ServiceMesh
正如敖小剑在《DreamMesh 抛砖引玉》系列文章中提到的：“Service Mesh 的发展进程，当前还处于前景虽然一致看好，但是脚下的路还处于需要一步一步走的早期艰难阶段。由于 Istio 和 Conduit 的尚未成熟，造成目前 Service Mesh 青黄不接的尴尬局面。” 到底该如何让 ServiceMesh 落地，这也是我们在 2017 年 10 月选择了 ServiceMesh 之后面临的难题。
Istio 可以提供一个完整的解决方案，通过为整个服务网格（ServiceMesh）提供行为检测和操作控制来满足微服务应用程序的各种需求。它在服务网络中提供了许多关键功能例如：流量管理、可观察性、策略执行、服务身份和安全、平台支持、集成和定制。
事实上我对 Istio 的流量管理 DSL 非常满意，同时通过评测也能够接受 Envoy 的性能开销，从当时来看 Istio 确实是一个非常优秀的且是唯一的候选者。但敖小剑在《DreamMesh 抛砖引玉》描述的几个问题，也困扰着我是否采用 Istio。
1. Ready for Cloud Native?
我们目前并没有采用 K8S，事实上我们所开发的 IaaS 控制面程序，本身就和 K8S 的功能类似。
2. 如何从非 Service Mesh 体系过渡到 Service Mesh？
我们有大量既有的服务。
3. 零侵入的代价
K8S 的网络方案已经是非常复杂且性能堪忧了，再通过 IPTables 来透明引流确实是雪上加霜，给未来的运维、Trouble-Shooting 带来了很高的复杂度。
4. 网络通讯方案
目前我们主要使用 gRPC 和 HTTP，但仍有数据库服务等业务不适合跑在 K8S 中，而 K8S 的网络方案需要能够兼容现有的数据库等业务。
如何实现轻量 **ServiceMesh**
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论