kubernetes-handbook/usecases/service-mesh-conclusion.md

2.5 KiB
Raw Blame History

总结

既然服务网格这么好,那到底用还是不用,如果用的话应该什么时候用,应该怎么用?这取决于您的公司的云原生技术的成熟度曲线的位置,服务的规模,业务核心和底层基础设施管理是否适应等。

技术总是在不断向前发展,容器出现后,解决的软件环境和分发的问题;但是如何管理分布式的应用呢,又出现了容器编排软件;容器编排软件解决的微服务的部署问题,但是对于微服务的治理的功能太弱,这才出现了服务网格,当然服务网格也不是万能的,下一步会走向何方呢?会是 Serverless 吗?我们拭目以待。

服务网格还有一些遗留的问题没有解决或者说比较薄弱的功能:

  • 分布式应用的调试,可以参考 squash
  • 服务拓扑和状态图,可以参考 kialivistio
  • 多租户和多集群的支持
  • 白盒监控、支持 APM
  • 加强负载测试工具 slow_cooker、fortio、lago 等
  • 更高级的 fallback 路径支持
  • 可拔插的证书授权组建,支持外部的 CA

下面是采纳服务网格之前需要考虑的因素。

因素 可以考虑使用服务网格 强烈建议使用服务网格
服务通信 基本无需跨服务间的通讯 十分要求服务间通讯
可观察性 只关注边缘的指标即可 内部服务和边缘指标都要考虑以更好的了解服务的行为
客户关注 主要关注外部 API 的体验,内外用户是隔离的 内部外部用户没有区别体验一致
API 的界限 API 主要是作为客户端为客户提供,内部的 API 与外部是分离的 API 即产品API 就是你的产品能力
安全模型 通过边缘、防火墙可信内部网络的方式控制安全 所有的服务都需要认证和鉴权、服务间要加密、zero-trust 安全观念

在考虑完上述因素后,尽量选择开源的平台和解决方案,还要想好开源软件的边界在哪里,哪些能力将是企业版才会提供的。