本译文首发于微信号Docker(ID：dockerone)，译者Sam Zhang，滴滴云博客经授权转发。
重构和更新应用是具有很大挑战的。为适用于现代环境而更新更多的应用，复杂度也随之增加。使应用运行在容器平台，并且互相通信和连接，是通向模块化和有弹性的微服务架构的必要的一步。与此同时，微服务的灵活性也是复杂的。这就是Service Mesh所要扮演的角色。
Service Meshes 提供企业所需要的集中化的控制面板，同时仍然具有随心所欲的敏捷性和基于云的应用开发。考虑到Service Mesh作为一个专注于微服务API的7层网络，其提供了认证，授权，安全和性能服务来优化各个服务间的流量。更重要的是，使你能集中使用这些服务，而不是分别将这些代码写入到你的应用程序的业务逻辑中去。
一个简单的Service Mesh比喻
Service Mesh就像城市中得自来水管网络。你的团队控制水管，依照需求而连接它们，并且设定他们的所有流向。有了Service Mesh的支持，数据可以通过你的系统，不管是那种类型或目标，也无论应用的日新月异的需求。
这个流量管理可以集中建立规则来管理互相连接的数据流。就好像天空中的一个巨大的控制室，你可以命令灌溉加州，当那里的作物需要水；或者当迈阿密遭遇大水时，你可以排走那里的水。最重要的是，这些动作能自动地，动态的完成。
Service Mesh是通往多云（Multi-Cloud）的门票
Service Mesh是平台无关的。幸亏私有云和公有云提供商，建设了标准的Docker容器和Kubernetes编排工具。由于这些工具，在AWS构建一个Service Mesh不能避免迁移系统到Microsoft Azure，或者在vSphere私有云建立一个Mesh。
这意味着你的Service Mesh节点可以运行在任何容器架构下，系统运行甚至可以架构在不同的云上。因为Service Mesh跟踪延迟和性能指标，使跨云的能力延伸到跨云服务的交付。
Service Mesh加强了可靠性和可视性
Service Mesh提供智能的流量路径，可以自动恢复网络或者服务。这实现了全局问题的跟踪，甚至跟踪内部服务的问题。
如果一个服务器无响应，Service Mesh将会把它剔除出单个的服务或是在线的负载均衡池，并分流到另一个地址池进行观测。一旦开始恢复响应，此服务器就会被再次自动推回到在线的负载均衡池中。
Service Mesh为你的系统提供全面的服务级别的可见性，这些数据能被用来调试和优化你的系统。随着时间的推移，你的系统将被不断打造和扩展功能，以满足性能和稳定性的需求。
Service Mesh稳固了内部服务通信
当你的团队推出一个新的应用版本，或者一个应用集群到一个新的数据中心，安全团队通常需要在系统中重新发布证书和认证新的服务器。如同路障一样，这将会耗费时间和精力。
有了Service Mesh，所有服务之间的安全问题将由Mesh来处理，把那些担心抽离出应用本身。Service Mesh处理所有服务间通信的障碍，比如，哪个系统对哪个服务有权限，哪个用户可以使用哪个服务。因此，在Mesh中升级应用不需要重新配置安全策略。
这也保障你的网络和服务通信的安全独立于你的内部业务逻辑之外。如果网络中出现安全漏洞，Service Mesh即能处理这些补丁更新，而不用重新架构每个应用。这减少了大量因安全升级而引起的离线时间。
对于Service Meshes在大量微服务境下的研究
Service Mesh带来的一个（较大的）潜在弊端。其增加了一个额外的容器。大多数Service Mesh在实施时使用了sidecar代理，每个容器绑定的微服务会连接一个代理实例。但是，这样做的好处远远大于付出的成本，这也意味着Service Mesh通常不适用于小的规模。
如果你管理成百上千个离散的微服务，可以考虑Service Mesh。在这样大的规模下，Service Mesh是最后的云应用难题，它连接你所有的资产——无论是公有云，企业数据中心，或是混合云。有了Service Mesh你的团队能够跟踪问题，确保服务的可用性，以及维护正确的路由表。
译文：【链接】
原文：【链接】
