如何打造创新特色的服务治理体验？(上)

导读	本文将包括以下内容：经典微服务架构的特点及问题、微服务计算平台的设计思想与抽象模型、打造微服务计算的基础三件事、总结。

张真，宜信技术研发中心高级架构师，负责基础系统架构演进与优化、服务治理、监控平台、微服务建设、DevOps平台、自动化测试框架及电子签约、短信、邮件等应用系统。早年就职于IBM中国研发中心，负责IBM WebSphere应用服务器的设计与开发。目前主要关注微服务架构实施，微智能设计思想应用，虚拟化技术应用，共识计算研究。

经典的微服务架构一般包含两个部分：API网关，一组微服务。API网关是唯一的请求入口，它还要负责负载均衡，路由编排，失效切换等工作。

经典的微服务架构图(来源网络):

关于经典微服务架构的文章很多，这里重点想分享一些我们实践经典微服务架构的一些问题：

1. “笨重”的API网关，由于它要负责各种核心功能，不能灵活扩展，比如负载均衡策略，也许每个微服务类型需求都不一样，它很难灵活变更;随着对接的微服务越来越多，每个API网关也集成大量的功能。
2. API网关自身需要高可用保证，经典架构并不提供，随着后端接的微服务越来越多，也会造成很多稳定性问题，它与微服务也需要两套运维办法，给运维带来额外成本。
3. 服务注册与发现还是传统模式，不能级联代理，长连接也有限制，不能很好解决跨大网段，跨机房，跨IDC中心的问题。
4. 心跳机制比较单一，只是从连接层面考虑，没有上下文以及服务本身的监控，需要依赖第三方实现。
5. 失效切换机制单一，只能是联通性检查，对业务异常无感知，意味着不能根据业务异常切换。
6. 没有自动高效的重试机制，需要考虑对API网关的改造。
7. 几乎没有隔离机制，需要采用第三方技术解决。
8. 微服务实现没有统一的技术栈支持，还处于原则规定阶段。
9. 服务编排依靠人工，没有动态编排能力。

整体看来，经典微服务架构还不够“聪明和智能”，于是我们设计并着手研发新一代微服务计算平台，希望能够让其充分发挥微服务架构的优势和特性。

“微智能”这个概念起源于智能家居，是目前智能硬件领域的一股创新思想。在提到“智能”这个词，通常是相对人而言，智能家居通过“智”的体现，更好的服务人的生活。于是，我们就思考是否系统或者服务也能体现“智”，如果与微服务相结合，让其更加“聪明”的工作?

1)自动发现：即真实的反映现实世界，尽可能利用“自动化”手段捕获现实情况并提取有效”信息”。微服务实际上对原有的单体系统或”重”服务进行了拆分，意味着服务种类以及服务实例个数会成倍增加，依靠人工整理或编排的手段变得笨重滞后。自动发现实现了微服务生命周期管理初始环节的自动化。

2)自我维护：即形成“闭环”反馈回路，将“输入”或“中间”或“结果”信息再反馈到系统中，合并成新的“输入”或“中间”或“结果”信息。真实世界的信息变化很快，为了尽量趋近真实，需要不停的迭代。微服务架构除了更多的服务实例个数(规模增长)，也意味着更加“多变复杂”的服务更迭(变更频率增长)，自我维护实现了微服务生命周期管理更迭的自动化。

3)自动适应(适配)：自动适应拓展了自动发现+自我维护的思想外延，是“智”的体现。根据自动发现的信息适配相应的处理(初次适应);根据自我维护的反馈，不断调整(迭代适应)。比如服务降级的阀值，其实不同时间不同资源使用情况下这个阀值是动态变化的，在数百服务实例的级别都已无法依靠人工来进行调整，而需要每个服务实例依据上下文的环境以及历史状态的分析自主的调节。

所以微智能设计思想的三个核心原则正是构建“智”的微服务计算平台的基础指导思想。

有了微智能的思想，我们还需要重新认识“服务”。什么是微服务，社群里有很多文章都分享了相关的内容。我们理解服务的“微”体现在：

• 细粒度的服务能力：某个服务实例只完成一种或某几种业务，或说只具备某一种或几种能力。
• 完全独立的部署结构：每个服务实例都能独立部署
• 服务能力可以编排：不同的服务实例之间需要协作才能完成“更大”的业务
• 更多同类型实例：业务种类决定了服务种类，而业务负载的大小决定了某种服务类型的实例数量，当然这可能也意味着更加稳定的服务输出。

这里引入一个很有意思的思考：社会是由人(个体)构成的相互协作的群体，每个人都可能具备几种技能，并使用这些技能参与到社会分工协作中去。具备同种技能的人可以一起协作来提高生产效率和提供可靠性高的生产输出;具备不同技能的人可以在某一件事情上进行分工协作，形成生产流水线。

其实可以发现微服务的特性跟人类社会的运作方式很像。服务实例就是个体，服务能力就是技能，允许服务实例具备几种服务能力，具备相同服务能力的实例可以看做同类型的实例，多个同类型实例构成的集群可以实现负载均衡和高可用，不同类型实例可以被编排在一起完成业务流程。我们把这种分布式设计称为“拟社会化”。

“拟社会化”分布式设计抽象图：

“拟社会化”分布式设计的特点：

1. 服务计算节点与服务能力之间没有必然联系，这是与传统分布式设计的重要区别。服务计算节点是运行资源的载体，服务能力是业务逻辑的载体。
2. 服务计算节点允许多个服务能力。
3. 服务能力有两种状态：激活(可以使用)，非激活(存在但不可用)。
4. 服务能力是独立的，可装配的。
5. 服务集群实际是服务能力的集群，这也是区别传统单体架构集群或SOA服务集群的关键。
6. 服务的协作过程实际是服务能力的协作过程，而不是服务计算节点的协作过程。
7. 由于协作过程因为服务能力的可变性，使得可以动态定义服务能力集群，即软件定义服务集群(SDSC)。

这里可能有个疑问：为什么允许某个服务计算节点有多个服务能力，这是不是一种“倒退”，不符合微服务的原则?其实主要有两个方面的原因：

• 资源使用方面：在实际实施过程中，难以保证每个服务能力都能独享服务计算节点，而且事实上如此实施会过于极端了。微服务的服务实例数量会比传统架构的增长几倍甚至几十倍，难以依靠单纯增加资源投入的方式来满足部署需求。
• 服务编排的需要：这是更重要的一点，服务输出是体现在服务能力上(再次强调不是服务计算节点)，这也是“微”的体现。由于服务能力可以激活也可以“休眠”，那么某个复合能力节点就具备了服务能力输出的多样可能性。比如某个服务计算节点可能在一段时间属于某个服务能力集群，在另一段时间属于另外一个服务能力集群，通过这种方式实现计算资源的最大化利用。

这里举两个例子对“拟社会化”分布式设计的应用加以说明。

实践实例一：短信系统是常见的高并发系统，在互联网环境下可能因为各种营销活动引起Peaktime，常规的做法是增加资源，但现实是资源池是有限的，而且多数时候Peaktime会波及整个营销活动链条的系统，这些系统都需要增加资源，很快资源池就分光了。在“拟社会化”的分布式设计下，可以通过服务能力的快速切换，把一些业务休眠或在当前时间段体量小的服务能力的计算资源向Peaktime的服务能力集中，在Peaktime过去以后，又能快速的恢复原集群。同时，可以发现另一个特性的体现：软件定义集群。这个特性会在以后的分享专题中专门说明。

实践实例二：在P2P业务中，线下签约通常是白天进行而晚上无业务，而签约数据的统计工作是T+1的模式，是在晚上进行。传统方式是部署两个完全独立的系统，而“拟社会化”的分布式系统通过复合能力节点，以服务能力切换的方式实现同一套计算资源的复用。

计算节点抽象模型

接下来，就是把微智能思想和拟社会化分布式设计统一起来，构建微服务计算平台的计算节点抽象模型。它遵循以下原则：

• 服务能力是实现业务逻辑的唯一方式，每种能力只包含一种业务逻辑
• 服务能力的实现方式遵守同一套技术实现框架，只有业务逻辑的差别，而运行机制，运维机制完全相同
• 每个计算节点是对等的，只有计算资源占用的差别，而运行机制，运维机制等完全相同
• 计算节点的分工由服务能力决定，部署的计算节点至少包含一种服务能力
• 计算节点的实现遵守同一套技术实现框架，且这套实现框架提供运行服务能力的容器
• 计算节点集群的构建方式是自动发现的，集群元数据的维护是由计算节点集群自我维护的
• 服务能力的发现方式是自动发现的，服务调用元数据的维护是由计算节点集群自我维护的
• 服务调用过程应具备自适应能力，尽最大可能保证服务调用通畅，在面对风险时，能够有一定的自主处理能力
• 允许服务能力的集成与编排，服务编排后的运行过程具备应对异常或风险的自适应性。

计算节点抽象模型：

服务能力是一种计算能力，分为基础服务能力和业务服务能力。

1. 基础服务能力是构建计算平台的前提，也提供了对计算平台服务调用，监控，运维的支持。基础服务能力实际上是整个计算平台的基石，会在以后的分享专题中逐个展开说明。
2. 业务服务能力是根据实际业务需求实现的服务能力

按照以上原则，服务计算节点还提供了三类基础支持：

• 服务能力的生命周期管理：

值得注意的是，服务能力可以被装配或卸载，这个过程分为Soft模式和Hard模式。Soft模式是通过配置的方式，服务能力的实现(例如jar包)还存在;Hard模式就是配置与实现一起装配或卸载。实际应用中，Soft模式更加灵活，服务能力实现的变更可以交给节点升级来做。

• 服务能力实现框架：为实现业务逻辑提供一套统一的编程和运行框架。

1. 组件化管理支持：服务能力在业务层面是原子，但在实现层面可以分解为组件，组件是具备特定逻辑又具备通用逻辑的代码。
2. 常用的编程组件的支持：保持统一的，标准的技术栈，也加速服务能力的开发。一般包括：定时任务，HTTP服务端，HTTP客户端，内存队列异步处理，多线程或并行编程支持。当然通讯层面是根据实际选型来定，我们以HTTP作为标准通信。

• 计算节点自身管理：为了实际运行和运维需要而提供的支持。

1. 元数据管理：比如每个计算节点需要一个唯一的ID来标识自己(就像人的身份证)，通过它第一次运行来创建，且持久化起来以便再次运行时能够保持ID不变;有些服务能力运行是会产生临时文件，这就需要计算节点提供一个“场所”(临时目录)供其施展。
2. 节点自动升级/回滚：这个是所有分布式系统中最重要的特性之一，它能大大提升变更大规模节点的效率，在微服务架构下尤其适合。这个变更过程包含两个方面：计算节点配置以及实现的变更，服务能力配置以及实现的变更。
3. 节点的配置管理：负责提供实际的配置读取/改写接口，以及将自身和服务能力的运行时的配置持久化等。

当然计算节点自身管理包含工作有很多扩展，要根据实际需求定义。

微服务计算平台实现服务治理首先要解决三个基础：服务注册与发现，服务监控，服务调用控制。

1)服务注册

经典的服务注册方法有以下两种：

• 显式配置：人工将服务的接口信息(服务名，服务URI等)配置到服务注册中心。WebService UDDI就是这种模式。它的问题是需要人工收集服务接口信息，这个过程可能产生滞后或者错误的信息，运维代价大。
• 代码实现：调用服务注册中心客户端发送服务的接口信息到服务注册中心。典型用例是基于Zookeeper服务注册。它的优势是服务接口的URI可能是通过代码收集出来的，较人工收集更加自动化。

但它也有如下问题：

• 需要编写专门的代码埋点，与服务注册中心客户端的紧耦合：如果使用Zookeeper，需要依赖它的jar包。
• 服务注册代码与服务接口代码上下文紧耦合：必须在特定位置去使用服务注册的代码，而且可能还会包含特定服务的信息，这些信息可能是人工编排进去的。
• 由于不同系统是由不同团队开发的，需要行政制度，“TopDown”规定服务注册的编程，一旦有“不按套路出牌”的情况就会出现各种运维问题。
• 基于前文的计算节点模型，我们的微服务注册过程如下：
• 以HTTP方式对外暴露功能的服务能力(如图Http服务能力A)基于计算节点提供的Http服务框架实现。统一技术栈的目的之一，也是为服务注册做准备。
• 在Http服务能力A装配时，基础服务能力“服务能力画像”会对其进行画像。画像的过程实际是对编程模型的解析过程。提取的信息包括IP，Context路径，服务接口的URL，服务接口对应的实现方法，方法输入参数的Pattern等等。这个过程就实现了服务的自动发现。
• 服务能力画像完成画像后会将画像数据转交给基础服务能力“心跳客户端”。
• 心跳客户端通过心跳上行将服务接口数据发送到服务注册中心。

我们的服务注册过程是以心跳系统为基础的，服务注册是心跳事务中的一种。实际上服务注册中心是基础服务能力“心跳服务端”的功能，而它的载体是另一个计算节点(如图服务计算节点B)，这也是计算节点的对等性体现，因为任何一个具备心跳服务端能力的计算节点都可以作为服务注册中心。

服务注册：常规模式

服务注册：“心跳级联代理”模式

在大规模部署服务计算节点时，往往还会遇到跨大网段，跨机房，跨IDC中心，白名单IP策略等问题。所以心跳系统还支持“心跳级联代理”模式，其作用是允许建立多级的心跳群，每个群由若干“代理”心跳服务端组成，它们只负责转发心跳信息，所以服务注册信息也依靠这个过程进行转发到服务注册中心。

服务注册：多级服务注册中心模式

在某些特殊业务场景下，对服务注册信息更新延迟容忍度较低，这时，让心跳级联的计算节点也作为服务注册中心。如下图，节点B是1级服务注册中心(以下简称1级中心)，节点C是2级服务注册中心(以下简称2级中心)。1级中心会存储向自己提交的服务注册信息，也会把这些信息转发到上级服务注册中心。2级中心上可见所有下级中心的服务注册信息。这种模式可以获得更快的服务发现，因为同级的节点发现其他节点服务能力只需经过本级服务注册中心即可，下文会结合服务发现做详细解释。

服务注册中心依靠TTL的方式对服务接口注册信息进行生命周期管理。我们定义生命状态如下：

1. 存活(Alive)：服务接口健康，可被查询
2. 可疑死亡(Dying)：由于网络延迟等原因的假死状态，服务接口健康状态存疑，可被查询。有可能经过1~2个生命周期收到上行心跳，可恢复至Alive状态
3. 死亡(Dead)：超过了较大的TTL，基本认为服务接口死亡，其接口信息被隔离不能查询
4. 消失(Disappear)：超过了一个铁定死亡的TTL，认为服务接口可以抹去，最终会从服务中心消息掉，其接口信息被隔离不能查询

另一个关键点是服务接口名的定义，它应该是全局唯一的命名，因为在多个服务能力之间互相调用时是以服务接口名为目标的。在服务画像时，会自动生成服务接口名，它提取以下三类信息：

1. 计算节点类型名(服务计算节点相关)：计算节点的类型由业务语义决定，比如MonitoAgent，SMSGateway，HealthManager等等
2. Http服务组件类型名(服务能力相关)：对外提供Http服务组件的简写类名，比如MDFListenServer，NodeOperHandleServer，DigitSignServer等等
3. Context路径(服务接口相关)：相对Http服务根的路径，比如/ma/put/mdf，/hm/cache/q，/rtntf/oper等等。

它们共同构成服务接口名，例如：

1. healthmanager-HealthMangerServerWorker-/hm/cache/q
2. runtimenotify-RuntimeNotifyServerWorker-/rtntf/oper
3. hbserveragent-HeartBeatServerListenWorker-/heartbeat

2)服务发现

服务发现的本质是通过服务接口名查询服务注册中心，服务注册中心基于某些策略返回服务接口可用地址列表，服务调用方也可以基于某些策略来使用地址列表。

微服务计算平台的服务发现过程如下：

• 业务服务能力X以服务接口名为参数，调用组件API(每个服务能力组件都具备)。
• 组件API内部是调用心跳客户端向服务注册中心查询该服务接口。值得注意的是，除了第一次获取某服务接口信息外，出于性能考虑，这个过程是独立的，心跳客户端可以通过下行心跳不停更新已经用过的服务接口信息，通过TTL机制自动过期哪些长时间不使用的服务接口信息。
• 服务注册中心根据某种策略(授权访问策略，隔离策略等等)返回地址列表
• 业务服务能力X获取服务接口地址列表后，可按照某种轮询策略(Round Robin，权重等)使用。

在心跳级联代理模式下的服务发现与常规模式类似，这里不做详述。

多级服务中心模式下的服务发现：

上文提到在多级服务注册中心模式下，可以获得更快的服务发现。从心跳客户端的角度来看，其实没有差别，但是如果是查询同级的服务接口，在1级中心立刻查到，无须去2级中心;对于查询跨级的服务接口，则需要从2级中心获取，并会在1级中心缓存，从而加快跨级查询。有一点注意，1级中心的缓存也是TTL的，并且生存周期要短于2级中心，这是性能和时效性的互相适应的结果。因为从1级查缓存虽然快，但是1级中心无法判断跨级服务的存活，所以长时间的缓存可能是错误的信息，缩短TTL时长是为了更快更新跨级服务的地址信息。

服务接口失效的快速反馈：

当业务服务能力X调用Http服务能力A遇到异常时，服务能力实现框架会自动捕获异常信息，并将系统性异常(Timeout，SocketException等等)以及某些业务异常(基于策略)提交到服务注册中心，这个过程不必等到心跳周期到达而是立即触发的，从而服务注册中心可以实现对这些服务接口的快速隔离。而其他打算调用该服务接口的其他服务能力，通过心跳下行获得地址列表更新。这样的方式可以弥补TTL机制可能的延迟。

另外说明一下为什么没有使用Zookeeper类似的长连接(尽管时效性更好)，主要有如下原因：

1. 长连接对服务注册中心的压力大，长连接意味着要支持大量的连接，常规的PC服务器能够支持数千个长连接已经是极限了，在微服务架构下，如果实例个数在这个数量级尚可接受，但是如果是万级实例，对硬件的配置要求太高，而且系统层面大量的长连接也存在管理问题。
2. 长连接难以实现跨大网段，跨机房，甚至跨IDC中心，甚至由于某些IP安全策略(隔离)会变得不可用。
3. 长连接的超时机制难以把控，太短会造成“中断”假象，太长会造成”假存活”，而且受网络层影响很大。
4. 长连接也无法支持级联来实现扩展服务规模的能力。