企业微服务治理的解决思路

背景

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

微服务架构可以极大的降低业务的复杂性。开发和部署相对大单体架构而言更加简单，单个微服务的功能可以更快地更改，启动和调试单个微服务的时间成本相比于单体应用也大大减少。普遍而言，微服务架构具备以下优点：

将业务分而治之，降低业务复杂性，让业务易于理解、修改和维护
模块化部署，修改代价小，迭代速度快，有很好的扩展性
更好的容错性，业务服务各司其职，单点故障不易影响全局

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

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

企业微服务化面临的挑战

复杂的网络通信提升了故障出现的概率

在微服务架构体系中，服务与服务之间需要通过网络相互沟通，意味着研发人员在原本的业务逻辑之外，还需要额外考虑网络通信相关的问题。比如服务在向其上游服务发起请求时需要对上游服务的各种意外响应做出处理，常见的有401错误，404错误，500错误，503错误等。此外还涉及到对网络延迟，网络故障等环境问题做出处理。

一旦研发人员不能妥善处理这些网络通信带来的意外情况，随着微服务数量的不断变多，故障的风险概率将会随之增大，进而影响系统的整体稳定性。

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

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

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

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

当故障出现时难以确定影响范围

虽然在微服务架构下，单点故障难以对系统造成整体上的破坏，但业务从来都不是独立完成的，各服务之间存在各式各样的依赖关系，这就导致故障出现时往往会级联影响到下游业务，甚至引发其他业务的连锁故障，此时业务最终呈现的现象往往会干扰研发人员对其故障范围的判断。

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

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

总结

微服务架构是解决业务复杂度的一个很好的方法，也是目前企业实践中最常用的办法。但是由于微服务架构的复杂性，企业想要管理好基于微服务架构的应用，也需要具备更高的能力。如果微服务治理得不恰当，反而有可能适得其反，不仅不能享受到微服务架构带来的好处，反而会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进⽽影响开发迭代的速度，甚至影响系统的整体稳定性。

综上所述，企业对微服务治理的需求是十分明确的，就是想知道当下环境当中，特别是在数量庞大的微服务相互沟通的过程中，到底发生了什么，当故障发生时，故障的影响范围，故障的根本原因，最后是需要解决或缓解故障对业务影响的手段。

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

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

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

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

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

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

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

以Sidecar为主要表现形式的运维侧解决思路

随着技术的快速发展，DevOps理念开始流行，一种以Sidecar为主要表现形式的运维侧解决思路开始出现。研发只需要关注自身的业务部分，服务治理能力通过其他工具插入到正在运行的业务服务当中。

Sidecar模式，指单独将能力封装在另一个程序当中与业务共同运行，以此来增强业务服务的能力。服务网格（Service Mesh）技术就大量的使用了Sidecar模式，其中最为著名的开源库是Istio。

使用Sidecar模式解决服务治理的思路优势是：Sidecar作为基础设施可以由运维人员完全掌控，它与编程语言无关，并且完美的规避了SDK升级带来的重新编译部署的烦恼，并且由于Sidecar完全独立于业务服务，这就赋予业务在任何时间接入和任何时间退出的权利，即插即用。

与之相对的是Sidecar模式的缺陷：Sidecar必须劫持流量才可以做到对业务服务的能力增强，这就意味着在业务调度的过程中产生了一个新的不确定因素，一旦Sidecar本身出现故障，它将影响业务的正常运转。其次，在路由中每个服务都多了一跳，这就导致Sidecar必然带来性能的损耗。

以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本身故障时无法正常访问，并且由于多运行时，当故障出现很难准确定位故障。

如何抉择

SDK的方式和企业业务最贴合，完全的自主可控，可是需要付出巨大的研发和维护代价，去实现服务治理相应的功能。

Dapr的理念十分前卫，它能提供更多的想象空间，但是如果使用Dapr结构，研发需要放弃经营已久的开发框架去适配Dapr，相当于把底层框架几乎换掉，这个代价不是大多数企业能够承受的。

从企业成本付出来看，服务网格或许是现阶段最适合的解决方案。

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

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

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

零侵入，业务无感知，不需要支付额外的研发成本。
语言无关，无论使用任何编程语言都可以享受统一的服务治理能力。
升级便利，作为独立第三方服务，服务网格的升级迭代并不会影响业务的正常运行。

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

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