# 總結 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 最后是對全書的總結，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安全觀念 | 在考慮完上述因素后，盡量選擇開源的平臺和解決方案，還要想好開源軟件的邊界在哪里，哪些能力將是企業版才會提供的。