微服务架构下，如何打造别具一格的服务治理体验？(上)

一、经典微服务架构的特点以及问题

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

二、微服务计算平台的设计思想与抽象模型

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

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

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

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

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

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

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

三、打造微服务计算的基础三件事

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

• 需要编写专门的代码埋点,与服务注册中心客户端的紧耦合：如果使用Zookeeper,需要依赖它的jar包.
• 服务注册代码与服务接口代码上下文紧耦合：必须在特定位置去使用服务注册的代码,而且可能还会包含特定服务的信息,这些信息可能是人工编排进去的.
• 由于不同系统是由不同团队开发的,需要行政制度,“TopDown”规定服务注册的编程,一旦有“不按套路出牌”的情况就会出现各种运维问题.

• 以HTTP方式对外暴露功能的服务能力(如图Http服务能力A)基于计算节点提供的Http服务框架实现.统一技术栈的目的之一,也是为服务注册做准备.
• 在Http服务能力A装配时,基础服务能力“服务能力画像”会对其进行画像.画像的过程实际是对编程模型的解析过程.提取的信息包括IP,Context路径,服务接口的URL,服务接口对应的实现方法,方法输入参数的Pattern等等.这个过程就实现了服务的自动发现.
• 服务能力画像完成画像后会将画像数据转交给基础服务能力“心跳客户端”.
• 心跳客户端通过心跳上行将服务接口数据发送到服务注册中心.

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等等.

runtimenotify-RuntimeNotifyServerWorker-/rtntf/oper

hbserveragent-HeartBeatServerListenWorker-/heartbeat

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

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