微服务适用于开发运维（DevOps），可是这些架构依赖的服务到服务通信在生产环境下运行和管理起来很复杂。这时候Service Mesh闪亮登场了：这是企业扩展、保护和监控应用程序的最佳方式。

Service Mesh是一个专用的软件基础设施层，用于控制和监控微服务应用程序中服务到服务的内部通信，让服务到服务通信变得快速、安全和可靠。它通常表现为“数据平面”和“控制平面”。在这种模式下，开发者（“服务所有者”）并不意识到Service Mesh的存在，而运营者（“平台工程师”）被赋予一套新的工具，以确保可靠性、安全性和可见性。如果你在构建云本地应用程序，就需要Service Mesh。

不妨把Service Mesh看成是用路由器和交换机互联的设备组成的网络，只不过在这里，网络存在于应用层（第7层），节点是服务，路由、交付及其他任务卸载给Service Mesh。目的在于，面对这个微服务Mesh，以一种可靠、安全、及时的方式获得请求。这通常是使用“代理”以拦截所有进出的网络流量来实现的。Service Mesh架构中的代理是使用边车（sidecar）模式来实施的：边车在概念上附属于主（或父）应用程序，提供平台功能以补充该父应用程序。借助这种模式，你的微服务就可以将边车用作同一个微服务容器里面的一组进程，也可以用作其自个容器中的边车，充分利用平台功能，比如路由、负载均衡、弹性、深度监控和访问控制。

与开发团队和运维团队交流后，这一点很明显：微服务有助于加快开发速度，但是这种架构面临的复杂性和风险在于微服务依赖的服务到服务通信。Service Mesh是一种应用程序优先的方法，它为微服务提供了一种通信结构（fabric），为DevOps团队提供了它们所需的灵活性和自主性，同时为运维团队提供了生产级应用程序方面所需的策略、可见性和洞察力，以便深入了解微服务环境。

Service Mesh提供了一种强大的微服务通信结构，为扩展容器化应用程序提供了最佳途径，无论应用程序在数据中心还是在云（或两者兼而有之）。最近还兴起了企业级Mesh，以满足企业生产环境的需求，应对其复杂性。Service Mesh不仅需要扩展应用程序，还需要监控和保护应用程序。一套受到支持的基础设施让DevOps团队拥有所需的灵活性和自主性，同时为运维团队提供了生产级应用程序方面所需的策略、可见性和洞察力，以便深入了解微服务。

Service Mesh的优点

不妨考虑一下贵企业在微服务方面的计划。也许贵企业打算在Kubernetes集群中运行10个服务、50个服务、100个服务或1000个服务。那么如何以一种高效而统一的方式在新的微服务和容器环境中管理所有那些服务？

你知道哪个服务在跟哪个服务联系、是否允许它们这样？这种通信是否安全？出现故障时，你如何来调试某个服务？如何在不影响所有应用程序的情况下添加跟踪或日志功能？你知道发布其中一个服务的新版本对上下游服务的性能或质量有何影响吗？

Service Mesh有助于回答那些问题。作为插入在微服务和网络之间的一个透明的基础设施层，它为你在应用程序的通信路径中提供了单一点，以便插入服务、收集遥测数据。你无需更改应用程序就可以做到这一点。

2018年：Service Mesh元年

Service Mesh是个比较新的概念。实际上，在2017年12月的KubeCon大会上宣布2018年是“ServiceMesh元年”之前，大多数人从来没有听说过Service Mesh这个概念。现在市面上有几种开源产品，几家公司在完善受到支持的Mesh，以便减轻管理微服务的负担。Service Mesh如何让企业组织能够进一步利用容器和微服务值得拭目以待。

欢迎加入行业交流群，群主微信：junfhu201（备注任职单位+职位，否则不予通过）

本文分享自微信公众号 - 架构师智库（beijing-tmt）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。