> For the complete documentation index, see [llms.txt](https://doc.cncf.vip/kubernetes-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.cncf.vip/kubernetes-handbook/fu-wu-wang-ge/the-enterprise-path-to-service-mesh-architectures/service-mesh-conclusion.md).

# 总结

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

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

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

* 分布式应用的调试，可以参考 [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

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

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

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