Service Mesh真的是云原生应用的绝配吗

Richard Li

随着愈来愈多企业开始落地微服务架构，Service Mesh和相关的解决方案在社区内的讨论热度开始逐渐上涨。Service Mesh所提倡的“全栈可观察性”、透明安全性、系统弹性等特性使人着迷，但它真的是云原生应用的绝配吗？本文将对Service Mesh什么时候make sense、什么时候不那么make sense做出一些思考。

作好微服务架构可让咱们更敏捷

当下来看，产品和服务的“time to market”决定了企业的竞争力，可以对市场和客户需求快速反应的公司想不成功都难。微服务架构为软件敏捷性和整个工做流的“速度”提供了强有力的支持，经过受权不一样团队分别处理应用的不一样部分，决策是“去中心化”的。

“去中心化”的决策带来了两个关键结果。首先，软件团队能够在架构、发布、测试等方面做出“本地化”的最优决策，不须要依赖全局标准。举个例子，每一个团队都有本身的发布工具，而不是单一的标准化应用发布。第二，团队能够更快进行决策，传统模式下韵味、架构等等集中功能之上的阻碍减小了。

微服务架构不是“免费”的——带来了新的失败模式

采用微服务对您的组织、流程和体系结构具备深远的影响。微服务架构自己是一个分布式系统，在基于微服务架构的应用中，业务逻辑分布在经过网络相互通讯的多个服务之间，而分布式系统有更多的故障模式（failure mode）。

考虑到这些失败模式，有一个体系结构和过程来防止小的失败变成大的失败是很是重要的。当咱们很“快”的时候，失败是不可避免的，例如服务更新时引入了错误，服务在负载下崩溃等等。

随着应用变得愈来愈复杂，对于失败管理的需求也愈来愈迫切。当应用由少许微服务组城市，故障还比较容易隔离和排除，但想象数十个、上百个微服务，以及分布在各地的团队，咱们的失败管理体系须要与应用一块儿“伸缩”。

管理失败

咱们通常会采起三种失败管理策略：主动测试（proactive testing）、缓解（mitigation）、快速想用（rapid response）。

• 主动测试：利用流程和系统来测试应用或服务，以便尽早发现故障。QA一般包含在这一方法中，虽然传统测试团队专一于预发布测试，但如今常常扩展到生产测试。
• 缓解：实施特定策略以便在特定故障发生时减小影响和损失。例如，取保服务多个实例间的负载均衡，当单个实例失败，整个服务仍然能够相应
• 快速反应：经过流程和系统快速识别和处理特定故障

Service mesh

当服务失败时，会对其上游和下游服务产生影响。经过正确管理服务之间的通讯，能够极大地减轻失败服务的影响。这就是Service Mesh的用武之地。

Service Mesh管理服务级别(例如7层代理)通讯，提供了强大的原语，可用于全部三种失败管理策略：

• 动态路由，可用于不一样的发布和测试策略，如金丝雀路由、流量阴影或蓝绿部署
• 弹性，经过诸如断路和速率限制等策略来减轻故障的影响
• 可观察性，经过收集度量标准，为服务间通讯添加context(例如跟踪数据)来提升响应时间

Service Mesh以一种对应用开发人员很是透明的方式添加这些特性。

Service Mesh能够帮助咱们更快构建应用吗？

决定Service Mesh对于咱们的企业是否有益，首先要思考两个关键问题：

• 服务拓扑结构有多复杂?
• 如何将Service Mesh集成到软件开发生命周期中?

服务拓扑

若是只是单个微服务，Service Mesh的好处是有限的。增量版本也能够经过现有的基础设施(如Kubernetes或API网关)来完成。

然而随着服务拓扑结构愈来愈复杂，Service Mesh将发挥巨大威力。须要考虑的关键约束是服务调用链的深度。若是您有一个浅层的拓扑结构，您的monolith直接调用了十几种微服务，那么Service Mesh的好处仍然是有限的。当您引入更多的服务到服务的通讯时，服务A调用服务B调用服务C，Service Mesh就变得十分重要了。

将您的服务网格集成到您的SDLC中

Service Mesh对于服务是同名的，它是一个丰富的7层网络，微服务不须要任何的代码修改。

然而部署Service Mesh并不会自动加速应用的速率和敏捷性。咱们须要将Service Mesh集成到开发过程当中。

将实现故障管理策略做为SDLC的一部分

Service Mesh为故障管理提供了强大的原语，接下来咱们将讨论各个失败管理策略以及如何应用到SDLC中。

主动测试

微服务应用的测试策略应该尽量贴近真实状况。考虑到多服务应用的复杂性，当前的测试策略强调在生产中进行测试(或使用生产数据)。

Service Mesh经过控制L7传输到服务的流量来在生产环境中进行测试。例如，服务网格能够将1%的流量路由到服务的v1.1版本, 99%的流量路由到v1.0(金丝雀部署)。这些功能经过声明式路由规则(例如linkerd dtab或Istio路由规则)公开。

Service Mesh不是主动测试的惟一方法。其余补充策略包括使用容器调度器(如Kubernetes)进行滚动更新、能够进行金丝雀部署的API网关或chaos engineering。

有了全部这些策略，谁管理测试工做流的问题就变得很明显了。在Service Mesh中，路由规则能够由管理网格的同一团队集中管理。

缓解

因为各类缘由，服务可能会失败：代码错误、资源不足、硬件故障。限制失败服务的爆炸半径对于整个应用程序继续运行(尽管处于降级状态)很是重要。

Service Mesh经过负载平衡、断路器和服务到服务通讯的速率限制等弹性模式来减轻故障的影响。例如在重载下的服务能够限制速率，以便仍然处理某些响应，而不会致使整个服务在负载下崩溃。

减轻失败的其余策略包括使用智能RPC库(例如Hystrix)或依赖容器调度程序。像Kubernetes这样的容器调度器支持健康检查、自动扩展和对不响应健康检查的服务的动态路由。

当为给定的服务适当地配置这些缓解策略时，它们是最有效的。例如，不一样的服务能够处理不一样数量的请求，须要不一样的速率限制。如何制定利率限制等政策？Netflix已经实现了一些自动配置算法来设置这些值。其余方法是将这些功能公开给服务做者，他们能够正确配置服务。

可观察性

失败是不可避免的。实现可观察性——跨越监控、警报/可视化、分布式跟踪和日志记录——对于将响应时间最小化到给定的故障是很是重要的。

Service Mesh自动收集关于服务到服务通讯的详细指标，包括吞吐量、延迟和可用性的数据。此外，服务网格能够注入必要的headers来支持分布式跟踪。注意，这些headers仍然须要由服务自己传播。

收集相似度量的其余方法包括使用监视代理、经过statsd收集度量以及经过库实现跟踪(例如，Jaeger工具库)。

可观察性的一个重要组成部分是向服务做者公开警报和可视化。收集度量只是第一步，考虑您的服务做者如何建立适合于给定服务的警报和可视化对于关闭可观察性循环很是重要。

---

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性，主要特色包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、经过插件式扩展来实现治理功能等。

• 开源PaaS Rainbond v3.6.0正式发布，Service Mesh开箱即用
• 解读Rainbond ServiceMesh微服务架构
• Rainbond插件体系设计简介