Service Mesh渐热，这些疑问该怎么解决？
InfoQ编辑张晓楠
讲述：丁婵大小：7.84M时长：05:42
在 2018 年至今的两年时间内，Service Mesh 从概念期进入到应用期，国内部分企业甚至已经进入 Service Mesh 大规模落地的深水区。但伴随而来的，是对 Service Mesh 的诸多疑问：非 Kubernetes 环境是否可以进行 Service Mesh 研发？Service Mesh 改造或自研面临的风险有哪些？Service Mesh 维护复杂、成本高昂的问题如何解决？近期 InfoQ 记者采访了北美 Service Mesh 服务商 Tetrate.io CEO 瓦伦·塔尔瓦（Varun Talwar），Founding Engineer 吴晟，以及 Head of Products Sridhar Krishnamurthy，就以上问题给出答案。
目前，Kubernetes 在应用生命周期管理方面很成熟，Service Mesh 的出现让 Kubernetes 在通讯层面、安全、监控以及由此为数据基础的审计、扩容等能力方面增加了新的特性，同时更为重要的是，Service Mesh 还提供另外两种核心能力：
提供了智能网关，替代 F5 成为主入口的能力。同时，由于 Service Mesh 对 Envoy 在网关和 Sidecar 具有相同的管理能力，可以更平滑地完成传统 Proxy 负载均衡到 Service Mesh 的过渡。
在从 VM 到 Kubernetes 迁移过程中，Service Mesh 提供了桥接两端的能力。即使针对陈旧的系统架构，无需微服务化技术改造，依然能获得相应的能力，并为向 Kubernetes 的迁移扫清障碍和提供保障。
目前，许多人有一个疑问：企业使用 Service Mesh 往往需要二度改造或自研，这时会面临哪些风险问题？
其实在北美，包括大型云厂商内部，都有过大量的私有 Service Mesh 先例。但随着 Service Mesh 的建立，复杂度不断增加，即使这些厂商有着全球顶尖的技术人才，他们依然觉得维护私有的内部 Service Mesh 版本工作量巨大、成本高昂。所以，他们大量转向开源的 Service Mesh 解决方案，特别是 Envoy 和 Istio。
这两个项目的社区发展都特别迅速，云厂商投入了很大的精力和人力在这两个项目上。单单集成这两个复杂的项目，往往已经成本巨大。如果是在内部方案中，甚至还不能很好的隔离控制面和数据面的功能，使得项目变得十分臃肿和难以维护。目前，全球几乎所有主流厂商，都在 Istio 和 Envoy 两个社区中进行广泛合作，以开源为核心构建 Service Mesh，而非重复造轮子。
针对其他的 RPC 机制，Envoy 和其他所有开源社区一样，需要有更多的人来参与。比如 Dubbo 协议已经得到初步支持，但性能还需要进一步评估；比如 MySQL、PostgreSQL、Redis 等等，也需要更多厂商的参与。
另外，对于 Service Mesh 模式在业务远程调用中带来性能损耗问题，瓦伦·塔尔瓦表示，目前公开的 Service Mesh 中 Envoy 造成的额外访问延时大概是 3 毫秒。在这个背景下，应用获得包括安全控制、流量管理和可观察性在内的能力。除非应用对于延迟是极其敏感的，否则这些用户可以在使用前对系统工作在 Service Mesh 上的效果进行评估。但是对于多数应用来说，这个延迟不会是真正的问题。
很多公开资料包括 SkyWalking 的实际使用案例看来，绝大多数应用无论集群节点并发流量多大，在单节点点对点模式下，普遍单点很少超过 1000TPS/QPS，延迟也在 50-100 毫秒，甚至更高。在此背景下，3 毫秒的延迟不会给系统带来真正的问题。同时，对于分布式调用深度的问题，超过 5 层的串行深度应用系统，一般已经无法很好的提供优良的响应和 SLA，也更不会因为 Envoy 的额外性能开销，有更明显的降低。多数的深层调用，都是通过低延迟 MQ 或者批量任务异步化处理的，在这个过程中，几十毫秒（即使包含 10 层的分布式调用）也不会产生性能问题。
在实际的 Service Mesh 实践中，Envoy 对访问的延迟能够保证稳定，即在高流量下也依然保持在 3 毫秒左右的延迟，这个是对生产环境最根本的保障。
那么，如果企业决定部署 Service Mesh ，这会对开发团队有什么影响呢？
部署 Service Mesh 可以帮助开发团队提升部署能力，有利于项目更高频率的升级。在生产环境上，无论是 DevOps 形式的团队，还是传统的运维团队，都可以借助 Service Mesh 的能力，在 VM 和 Kubernetes 环境间进行流量切换，或者实施蓝绿发布、金丝雀发布策略等等。平台团队可以更加关注网络性能、路由策略和网络，而无需关心业务代码的语言、类库版本和技术选型等问题。使平台团队和业务开发团队更加专注在自己擅长的领域，从而加速团队的整体能力。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论