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

32 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 总结
最后是对全书的总结2018年必然是一场服务网格或者说Proxy的战争。
### 用还是不用
既然Service Mesh这么好那到底用还是不用如果用的话应该什么时候用应该怎么用这取决于您的公司的云原生技术的成熟度曲线的位置服务的规模业务核心和底层基础设施管理是否适应等。
技术总是在不断向前发展容器出现后解决的软件环境和分发的问题但是如何管理分布式的应用呢又出现了容器编排软件容器编排软件解决的微服务的部署问题但是对于微服务的治理的功能太弱这才出现了Service Mesh当然Service Mesh也不是万能的下一步会走向何方呢会是Serverless吗我们拭目以待。
Service Mesh还有一些遗留的问题没有解决或者说比较薄弱的功能
- 分布式应用的调试,可以参考[squash](https://github.com/solo-io/squash)
- 服务拓扑和状态图,可以参考[kiali](https://github.com/kiali/kiali)和[vistio](https://github.com/nmnellis/vistio)
- 多租户和多集群的支持
- 白盒监控、支持APM
- 加强负载测试工具slow_cooker、fortio、lago等
- 更高级的fallback路径支持
- 可拔插的证书授权组建支持外部的CA
下面是采纳Service Mesh之前需要考虑的因素。
| 因素 | 可以考虑使用Service Mesh | 强烈建议使用Service Mesh |
| --------- | ------------------------------------------------------ | ------------------------------------------------------------ |
| 服务通信 | 基本无需跨服务间的通讯 | 十分要求服务间通讯 |
| 可观察性 | 只关注边缘的指标即可 | 内部服务和边缘指标都要考虑以更好的了解服务的行为 |
| 客户关注 | 主要关注外部API的体验内外用户是隔离的 | 内部外部用户没有区别体验一致 |
| API的界限 | API主要是作为客户端为客户提供内部的API与外部是分离的 | API即产品API就是你的产品能力 |
| 安全模型 | 通过边缘、防火墙可信内部网络的方式控制安全 | 所有的服务都需要认证和鉴权、服务间要加密、zero-trust安全观念 |
在考虑完上述因素后,尽量选择开源的平台和解决方案,还要想好开源软件的边界在哪里,哪些能力将是企业版才会提供的。