更新 ServiceMesh

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,6 +1,6 @@
 # 8.5 服务网格的未来
 
-使用服务网格的架构，在大规模线上部署的时候逐渐遇到了以下两个主要问题：
+Sidecar 本质上是一个服务代理，通过劫持发送到应用容器的流量从而实现对流量的控制，随着服务网格落地实践，Sidecar 的缺点也逐渐被暴露：
 
 - **延迟问题**：Sidecar 常规的做法是使用 iptbales 实现请求的拦截，当原来本来是A->B，现在变成A->iptables+sidecar->iptables+sidecar->B，那必然会带来性能损耗。尽管从一些产品的 benchmark 结果来看，Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务场景，来说，延迟损耗成为了放弃服务网格的最主要原因。
 - **资源占用问题**：Sidecar 作为一个独立的容器必然会占用一定的系统资源，对于超大规模集群（如数万个 Pod）来说，巨大的基数也使得资源总量变成了不小的数目，同时，这类集群的网络通信拓扑也更加复杂，配置下发的规模也会让 Sidecar 的内存出现剧烈的增长。

ServiceMesh/conclusion.md

@@ -2,7 +2,7 @@
 
 服务网格从概念诞生，尽管到现在已经发展接近八年的时间，但从目前的应用状况看，服务网格种种特性（无侵入治理、可观测等等）更多还是作用于云商宣传手段。
 
-一方面服务网格技术本身过于复杂（比传统侵入式框架还要复杂），包括 ambient mesh Cilium ServiceMesh，另一方面服务网格属于锦上添花的一种方案，而不是雪中送炭，所以业务运行良好，传统框架生态成熟的情况下大家没什么动力去折腾。所以，想要成熟的落地、大规模在互联网公司中应用，还是需要一段时间。
+一方面服务网格技术本身过于复杂（比传统侵入式框架还要复杂），包括 ambient mesh Cilium ServiceMesh，另一方面服务网格属于锦上添花的一种方案，而不是雪中送炭，所以业务运行良好，传统框架生态成熟的情况下大家没什么动力去折腾。预期很美好，但要大规模的落地，还是需要一段时间。
 
 参考