能不能，每篇文章做个总结，比如微服务和服务网格的区别，他们的优势，劣势，解决了什么问题，适合什么规模的业务，他们的相同点，不同点，感觉文章讲的有点模糊

最后一段的意思是，服务网格和API网关可以结合使用的，两种技术并不互相冲突吧。服务网格自己本身是完全去中心化的，给每个微服务运行期实例都加了个壳，两者是一荣俱荣一损俱损的关系，所以往往部署上也应该是在一个容器或VM上的。 目前linkerd是比较成熟而功能完备的，奈何JVM本身不小，打包到容器中就会额外多几十乃至上百MB，运行期也要吃掉很多内存。 lstio的数据面是用的C++，性能优势明显所以buoyant作为linkerd背后公司才不得已自己用另外一门无GC的静态语言重写了。他们也想过优化JVM，但只是优化了部分启动时间便放弃了改良路线决定起炉重造了，毕竟优化JVM太难了。

在k8s上，如果我们强制每一个服务发布时候，都必须在pod里面绑定一个nginx或者envoy，负责流控，熔断，通信等等功能，然后利用k8s的service服务发现，那我们也可得到一个很基础的服务网格。

servise mess其实就是将控制组件云化，实现业务系统只管业务？

谢谢。sidecar的稳定性是必须谨慎的地方

边车模式进一步发展，就出现了服务网格，服务网格单独作为一个集群部署，解决服务之间的流控，熔断，重试等服务通信的问题，类似于网络协议中的传输层。使用服务网格将业务逻辑和服务通讯的控制隔离开来，让分布式服务开发更简单容易

服务网格的劣势： 多一层通信，响应上比微服务稍逊一筹 服务网格的优势： 1.业务代码无侵入，服务跨语言； 2.将管理与业务逻辑分离，开发只需专注业务代码实现，开发成本更低； 传统微服务的优势： 快； 劣势： 治理方案不统一； 语言相关性

大神，所有文章我看了，没有讲到安全呀……能不能讲下安全……

DDD战术设计中的防腐层看起来一定程度上起到的就是sidecar的作用，虽然说是从不同的角度看这个问题。

Service Mesh 就是一个 Sidecar 集群？ A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. The service mesh is a critical component of the cloud native stack. 感觉类似于 service mesh 类的分布式基础技术，对我来说有点像是“屠龙之技”，虽然我也没有完全掌握，但是至少目前来看完全没有应用场景。这些底层技术，也许会逐步和 PaaS 或者 IaaS 平台绑定，对我来说应该是能够理解就可以。 The safest way to handle distribution has been to avoid it as much as possible, even if that meant duplicated logic and data across various systems. 在 Pattern: Service Mesh 那篇文章里面，对于历史脉络梳理的很清楚，软件或者说架构的发展历程，就是不断抽象的过程。先看一遍专栏，然后再看英文原文，可以方便理解。 因为看到留言里面，说 Istio 的架构有所变化，所以去看了一眼官网上的介绍，确实没有明显的标记出 mixer 的模块，同样的 Pilot 和 Istio-Auth 也没有画出来，感觉应该还是会有，只是不在突出说明。Istio 基本上就是 Service Mesh 的开源实现，官网上强调 Traffic management，Observability 和 Security capabilities 三个方面。