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

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

　　

　　做好微服务架构可让我们更敏捷

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

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

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

　　采取微服务对您的组织、流程和体系结构具有深远的作用。微服务架构本身是一个散布式系统，在基于微服务架构的利用中，业务逻辑散布在经过网络相互通讯的多个服务之间，而散布式系统有更多的故障模式(failure mode)。

　　斟酌到这些失败模式，有一个体系结构和进程来避免小的失败变成大的失败是非常重要的。当我们很“快”的时候，失败是难以避免的，例如服务更新时引入了毛病，服务在负载下崩溃等等。

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

　　管理失败

　　我们一般会采取3种失败管理策略：主动测试(proactive testing)、减缓(mitigation)、快捷想用(rapid response)。

　　主动测试：利用流程和系统来测试利用或服务，以便尽早发现故障。QA通常包括在这一方法中，虽然传统测试团队专注于预发布测试，但现在常常扩大到生产测试。

　　减缓：实行特定策略以便在特定故障产生时减少作用和损耗。举例来看，取保服务多个实例间的负载均衡，当单个实例失败，全部服务依然可以相应

　　快捷反应：经过流程和系统快捷辨认和处理特定故障

　　Service mesh

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

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

　　动态路由，可用于不同的发布和测试策略，如金丝雀路由、流量阴影或蓝绿部署

　　弹性，经过诸如断路和速率限制等策略来减轻故障的作用

　　可视察性，经过搜集度量标准，为服务间通讯添加context(例如跟踪数据)来提高响应时间

　　Service Mesh以一种对利用开发人员非常透明的方式添加这些特质。

　　Service Mesh可以帮助我们更快构造利用吗?

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

　　服务拓扑结构有多复杂?

　　如何将Service Mesh集成到软件开产生命周期中?

　　服务拓扑

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

　　但是随着服务拓扑结构愈来愈复杂，Service Mesh将发挥巨大威力。需要斟酌的关键束缚是服务调用链的深度。如果您有一个浅层的拓扑结构，您的monolith直接调用了10几种微服务，那末Service Mesh的好处依然是有限的。当您引入更多的服务到服务的通讯时，服务A调用服务B调用服务C，Service Mesh就变得10分重要了。

　　将您的服务网格集成到您的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工具库)。

　　可视察性的一个重要组成部份是向服务作者公然警报和可视化。搜集度量只是第一步，斟酌您的服务作者如何创建合适于给定服务的警报和可视化对关闭可视察性循环非常重要。

免责声明：
本网址（www.yingxiongyun.com）发布的材料主要源于独立创作和网友匿名投稿。此处提供的所有信息仅供参考之用。我们致力于提供准确且可信的信息，但不对材料的完整性或真实性作出任何保证。用户应自行验证相关信息的正确性，并对其决策承担全部责任。对于由于信息的错误、不准确或遗漏所造成的任何损失，本网址不承担任何法律责任。

本网站所展示的所有内容，如文字、图像、标志、音频、视频、软件和程序等的版权均属于原创作者。

如果任何组织或个人认为网站内容可能侵犯其知识产权，或包含不准确之处，请即刻联系我们进行相应处理。