作者：行云创新 Synuwxy

背景

随着业务需求的日渐复杂以及产品迭代节奏的不断加快，业务开发部门面临着前所未有的压力。为了抢占先机，用最快的速度准确把握用户需求的变化，优化开发出来的业务产品，微服务(MicroServices)架构技术在各大企业不断生根发芽。

微服务架构可以极大的降低业务的复杂性。开发和部署相对大单体架构而言更加简单，单个微服务的功能可以更快地更改，启动和调试单个微服务的时间成本相比于单体应用也大大减少。微服务治理也成为了困扰各大企业的难题。

普遍而言，微服务架构具备以下优点：

· 将业务分而治之，降低业务复杂性，让业务易于理解、修改和维护

· 模块化部署，修改代价小，迭代速度快，有很好的扩展性

· 更好的容错性，业务服务各司其职，单点故障不易影响全局

然而微服务架构并非没有代价，就如软件工程中没有真正的银弹。

原来在单体架构时，所有的逻辑都在一个服务内处理，方法和方法之间是进程内部的调度方式，然而采用微服务架构之后，服务与服务之间需要通过网络相互沟通，一个业务的实现往往是多个服务的共同作用下完成，由此，微服务治理带来了一系列的问题。

企业微服务治理面临的挑战

海量的微服务加大了故障排查的难度

随着业务的发展，微服务之间的沟通关系开始变得复杂，一个业务的实现往往是途径了很多个微服务，然而冗长的调用链带来的是数倍增长的排错难度。

举个例子：一个业务需要经过10个微服务的逻辑处理才能返回最终结果，某一个时间段依据用户反馈，这个业务已经无法正常运转，此时研发人员需要地毯式排查每一个经过的业务服务，才能准确的知道故障源。

故障定位一直以来都是一件麻烦事，在微服务架构下排错更是需要支付高昂的成本。

微服务架构在部署环境中的故障难以复现

微服务架构下的服务调度错综复杂，一个业务故障的产生往往与其上下游的服务有很大的关系。有时我们在本地测试一切正常，但放到环境当中运行时却会引发故障，其原因或许是部署的环境有问题，亦或许是下游服务给予了一些意外的参数，亦或许是上游服务响应的结果不符合预期，此类种种都是我们在离开了部署环境时很难预料到的变故，并且在微服务架构的掩盖下，复现故障十分困难。

目前主流的微服务治理解决思路

以SDK为主要表现形式的研发侧解决思路

通过编码的方式，让我们的业务代码直接具备解决问题的手段，这是目前最主流的也是发展时间最长的一种解决问题的思路。

研发的思维十分纯粹且直白，既然需要服务治理的能力，那就直接将这种能力写在代码上。通过日积月累沉淀出一些好用的SDK，代码只需要引入这些SDK即可获得服务治理能力。

在这条思路上最出名的开源库是SpringCloud。作为微服务治理框架的集合，SpringCloud的核心库封装了包括服务发现、流量访问、网关路由、熔断器、链路追踪等能力。

使用SDK解决服务治理的思路优势是：研发可以完全的掌握服务治理的所有能力，能够根据实际需求进行定制化，使其更加适配企业的实际情况。并且经过经年累月的打磨，部分语言的治理框架已经比较完善，为研发后续的开发打下了坚实的基础。

缺点是：研发掌握了一切，一旦SDK内部逻辑出现故障，或者是需要升级，就必须让研发介入重新编译打包，并且由于大部分服务都接入了服务治理SDK，所以一次升级可能需要涉及到很大范围的重新部署，这样做风险很大。SDK具备语言相关的属性，虽然部分语言的治理框架相对完善，但仍有很多流行的编程语言缺少完善的治理库，如果企业内部语言较多，为了平衡各类治理框架的差异，做统一管理，就需要投入额外的开发成本。

以SDK与Sidecar同时存在为主要表现形式的解决思路

在云原生理念的推动下，业界又诞生了一种新的解决思路，它融合了SDK和Sidecar这2种解决问题的想法，并且期望实现完全的云原生，这就是Dapr。

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到今年2月正式发布 V1.0 版本。在不到一年半的时间内，Github star 数达到了1.2 万，发展势头迅猛，Dapr 这个词是是「Distributed Application runtime」的首字母缩写：dapr是一个为应用提供分布式能力的运行时。

准确来说Dapr并不单单解决服务治理问题，而是完全基于云原生理念诞生的产物，Dapr希望将一切都抽象成云资源，代码通过对云资源的依赖来实现相应的业务。为了让各种语言都有统一的实现规范，Dapr给很多流行的语言提供了SDK，又结合了Sidecar思想，将真正实现逻辑的部分都封装在Sidecar当中，此时的Sidecar就是Dapr的运行时，有多个Sidecar，那就会出现多个运行时。业务代码会先通过SDK沟通Sidecar，再历经各个Sidecar的相互作用来实现具体需求，其中就包含了服务治理能力。

这种解决问题的办法有一个重要的优势：Dapr不仅可以动态的添加包含服务治理能力在内的各项公共能力，还可以基于抽象的云资源实现对底层实现的替换，比如将MongoDB替换成Redis等。

然而这种方式的缺陷也十分明显：Dapr几乎包含了SDK模式和Sidecar模式的大多缺点，SDK如果无法匹配Sidecar的版本时同样面临着SDK升级困难问题。由于多运行时共同作用，在路由上流量每经过一个服务，可能多了不止一跳，同样面临着性能问题。由于逻辑都封装在Sidecar上，也避免不了Sidecar本身故障时无法正常访问，并且由于多运行时，当故障出现很难准确定位故障。

使用服务网格解决微服务治理问题是当下代价最小的解决方案

服务网格（Service Mesh）是Sidecar模式的代表型技术之一，是处理服务间通信的基础设施层，在实践中，服务网格通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起。作为云原生的网络基础设施，它把微服务调度中有关网络的公共能力下沉到代理，实现了在无任何代码侵入的情况下提供可观察性、流量管理和安全性等能力。

相比SDK和Dapr这种需要研发深度介入的解决问题思路，服务网格的使用代价相对最小，这取决于Sidecar模式带来的结构优势：

· 零侵入，业务无感知，不需要支付额外的研发成本。

· 语言无关，无论使用任何编程语言都可以享受统一的服务治理能力。

· 升级便利，作为独立第三方服务，服务网格的升级迭代并不会影响业务的正常运行。

服务网格即插即用的特质对于企业十分友好，特别是针对组织架构相对复杂的企业，越少的部门关联意味着越少的沟通成本，而部门之间的沟通几乎是企业成本最大的地方。

综上所述，使用服务网格解决企业微服务治理是现阶段代价最小的选择，也是最推荐的解决方案。

------------------------------------------------------

高效可视化微服务治理平台  立即免费试用（www.cloudtogo.cn）