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

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等等.这个过程就实现了服务的自动发现.
• 服务能力画像完成画像后会将画像数据转交给基础服务能力“心跳客户端”.
• 心跳客户端通过心跳上行将服务接口数据发送到服务注册中心.