为什么说Service Mesh是大势所趋?
技术
作者:Robert Whiteley
译者:Sam
2018-07-19 02:45

重构和更新应用是具有很大挑战的。为适用于现代环境而更新更多的应用,复杂度也随之增加。使应用运行在容器平台,并且互相通信和连接,是通向模块化和有弹性的微服务架构的必要的一步。与此同时,微服务的灵活性也是复杂的。这就是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你的团队能够跟踪问题,确保服务的可用性,以及维护正确的路由表。

原文链接:https://thenewstack.io/why-you-should-care-about-a-service-mesh/

429 comCount 0