分布式服务架构解决方案.docx

分布式服务架构解决方案
V1.0

2016年4月
北京天禾元创股份有限公司

目录
1 引言 5
1.1 编写目的 5
1.2 服务化架构演进 5
2 架构设计 6
2.1 设计原则 6
2.2 架构原理 7
2.3 功能特性 8
2.4 性能特性 9
2.5 可靠性 9
2.6 服务治理 10
3 架构组成 11
3.1 架构图 11
3.2 服务路由 13
3.2.1 透明化路由 13
3.2.2 负载均衡 13
3.2.3 本地优先策略 14
3.2.4 路由规则 14
3.2.5 路由策略定制 14
3.2.6 配置化路由 14
3.3 注册中心 15
3.3.1 特性设计 15
3.4 发布和引用 16
3.4.1 发布设计 16
3.4.2 引用设计 18
3.4.3 灰度发布 19
3.5 优先级调度 19
3.6 服务治理 19
3.6.1 治理定位 20
3.6.2 治理对象 20
3.6.3 治理策略 20
3.6.4 治理目标 20
3.6.5 架构设计 21
3.6.6 运行态功能设计 22
3.6.7 线下治理 22
3.6.8 安全和权限管理 24
3.7 中间聚合层 24
4 微服务架构 25
4.1 带来的变革 25
4.1.1 应用解耦 25
4.1.2 分而治之 26
4.1.3 敏捷交付 27
4.2 架构解析 27
5 集成ESB 28
6 提供的服务 28
6.1 用户和组织机构 28
6.2 权限管理 28
6.3 单点登录 28
6.4 通信服务 29
6.5 业务提醒 29
6.6 待办工作 29
6.7 工作流服务 29
6.7.1 流程定义 30
6.7.2 流程测试 32
6.7.3 数据清理 32
6.7.4 流程审批 33
6.7.5 流程部署 33
6.7.6 流程升级/注销 33
6.7.7 调用接口 33

1 引言
1.1 编写目的
本文档的编写目的是为xxx烟草信息中心提供分布式服务架构的解决方案，随着企业内部业务的发展和应用规模的不断扩大，系统内部的应用越来越多，常规的垂直应用架构已经无法应对复杂业务带来的各种挑战。通过将业务公共能力抽象成原子服务，对复杂应用进行水平拆分和服务化，实现服务消费者和提供者的解耦。
1.2 服务化架构演进
传统软件的垂直架构改造的核心就是要对应用做服务化的改造，服务化改造使用到的核心技术架构就是分布式服务架构。
服务化架构演进图如下图所示：

图1服务化架构演化图
1、 单一应用架构：当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本；此时，用于简化增删改查工作量的数据访问框架(ORM) 是关键。
2、 垂直应用架构：当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率；此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
3、 分布式服务架构：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求；此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
4、 流动计算架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率，此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
5、 微服务架构：随着云计算、移动互联网、Docker容器等技术的快速发展和应用，微服务架构（Micro Service Architecture）这一全新的架构风格越来越受到大家的关注，也有越来越多的企业和平台服务提供商在实践中尝试并使用它来解决具体业务问题，微服务架构的流行已经成为未来技术发展的趋势之一。
2 架构设计
2.1 设计原则
面向服务的架构设计原则主要包括如下内容。
1、 服务可复用：不管是否存在即时的复用机会，服务均被设计为支持潜在的可复用性。
2、 服务共享一个标准契约：为了与服务提供者交互，消费者需要导入服务提供者的服务契约，这个契约可以是一个IDL文件、Java接口定义、WSDL文件，甚至是一个接口文档。
3、 服务是松耦合的：服务被设计为功能相对独立、尽量不依赖其他服务的独立提供者。
4、 服务是底层逻辑的抽象：只有经服务契约所暴露的服务对外部世界可见，契约之外底层的实现逻辑是不可见的。
5、 服务是可组合、可编排的：多个服务可能被编排组合成一个新的服务，这允许不同逻辑抽象的自由组合，促进服务的复用。
6、 服务是自治的：逻辑由服务所控制，并位于一个清晰的边界内，服务已经在边界内被控制，不依赖于其他服务。
7、 服务是无状态的：服务应当不需要管理状态信息，因此能够维持松耦合性。服务应当被设计成无状态，即便这意味着要将状态管理移至他处。
8、 服务是可以被自动发现的：服务发布上线后，允许被其他消费者自动发现；当服务提供者下线后，允许消费者接收服务下线通知。
2.2 架构原理
分布式服务架构核心逻辑架构图如下图所示：

图2分布式服务框架的逻辑架构图
通常分布式服务架构可以抽线为三层：
1、 RPC层：包括底层通信框架（例如NIO框架的封装、公有协议的封装等）、序列化和发序列化框架、用于屏蔽底层通信协议细节和序列化方式的差异的Remoting框架。
2、 Filter Chain层：服务调用职责链，提供多种服务调用切面供框架自身和使用者扩展，例如负载均衡、服务调用性能统计、服务调用完成通知机制、失败重发等。
3、 Service层：主要包括Java动态代理，消费者使用，主要用于将服务提供者的接口封装成远程服务调用：Java反射，服务提供者使用，根据消费者请求消息中的接口名、方法名、参数列表反射调用服务者提供的接口本地实现。再向上就是业务的服务接口定义和实现类，对于使用spring配置化开发的就是Spring Bean，服务由业务来实现，平台负责将业务接口发布成远程服务。
2.3 功能特性
分布式服务框架必须实现一些公共功能，这些公共功能见下表：
表1功能特性
特性名
功能名
说明
服务订阅发布
配置化发布和引用服务
支持通过XML配置的方式发布和导入服务，降低对业务代码的侵入
服务自动发现机制
支持服务实现自动发现，由注册中心推送服务地址，消费者不需要配置服务提供者的地址，服务地址透明化
服务在线注册和去注册
支持运行态注册新服务，也支持运行态取消某个服务的注册
服务路由
默认提供随机路由、轮询、基于权重的路由策略等
默认提供常用的路由策略，避免每个框架使用者都重复开发
粘滞链接
总是向同一个提供方发起请求，除非此提供方挂掉，再切换到另外一台
路由定制
支持用户自定义路由策略，扩展平台的功能
集群容错
Failover
失败自动切换，当出现失败，重试其他服务，通常用于读操作，也可以用于幂等性的写操作
Failback
失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作
Failfast
快速失败，只发起一次调用，失败立即报错，通常用于非幂等性的写操作
服务调用
同步调用
消费者发起服务调用之后，同步阻塞等待服务端响应
异步调用
消费者发起服务调用之后，不阻塞立即返回，由服务端返回应答后异步通知消费者
并行调用
消费者同时对多个服务提供者批量发起服务调用请求，批量发起请求后，集中等待应答
多协议
私有协议
支持二进制等私有协议，支持私有协议定制和扩展
公有协议
提供WebService等公有协议，用于外部服务对接
序列化方式
二进制类序列化
支持Thrigt、Protocol Buffer等二进制协议，提升序列化性能
文本类序列化
支持JSON,XML等文本类型的序列化方式，提升通用性和可读性
统一配置
本地静态配置
安装部署修改一次，运行态不修改的配置可以本地配置文件中
基于配置中心的动态配置
运行态需要调整的参数，统一放到配置中心(服务注册中心)，修改后统一下发，实时生效
2.4 性能特性
应用服务化以后，由原来的本地API调用变成跨进程的远程调用，网络通信、消息序列化和发序列化、发射调用和动态代理等都会导致性能损耗、时延增加。因此，分布式服务框架的性能指标非常重要，性能特性总结如表所示：
表2性能特性
线性特性
说明
高性能
在同等资源占用的情况下，单服务提供者的TPS要尽量提高
低时延
在同等资源占用情况下，服务调用时延要尽量低
性能线性增长
扩展服务提供者，性能要能够线性增长
2.5 可靠性
应用由单机调用演进到分布式部署之后，由于网络故障、服务提供者故障等因素，会导致业务失败率增加，分布式服务框架要具备很强的可靠性，来保证业务的成功率，可靠性总结如下表所示：
表3可靠性
特性名
功能名
说明
服务注册中心
服务健康状态检测
注册中心通过心跳检测服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
故障切换
注册中心对等集群，任意一台宕机后，将自动切换到另一台
高HA
注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通信
消除单点故障
服务无状态
服务提供者无状态，任意一台宕机后，不影响使用
服务集群容错
只要集群中有一台机器的服务提供者可用，业务就不会中断
链路健壮性
心跳检测
链路空闲时没有业务消息，通过定时心跳检测链路是否可用
断连重连机制
链路段连之后，根据客户端配置的重连策略定时重连，重连成功之前消息不会路由到段连的服务提供者上
2.6 服务治理
服务治理是分布式服务架构重要的特性，如下表所示：
表4服务治理
特性名
功能名
说明
服务运行态管控
服务路由
业务高峰期，通过动态修改路由策略实现导流
服务限流
资源成为瓶颈时，服务端和消费者的动态流控
服务迁入迁出
实现资源动态分配
服务降级
服务提供者故障时或者业务高峰期，进行服务强制或者容错降级，执行本地降级逻辑，保证系统平稳运行
服务超时控制
动态调整超时时间，在业务高峰期保证业务调用成功率
服务监控
性能统计
统计项包括服务调用时延、成功率、调用次数等
统计报表
提供多维度、实时和历史数据报表，同比、环比等性能对比数据，供运维、运营等使用
告警
指标异常、根据告警策略发送告警，包括但不限于短信，E-mail、记录日志等
服务生命周期管理
上线审批
服务提供者不能随意线上发布服务，需要通过正规的审批流程批准后才能上线
下线通知
服务提供者在下线某个服务之前一段时间，需要根据SLA策略，通知消费者
服务灰度发布
灰度环境划分原则，接口前向兼容性策略，以及消费者如何路由，都需要灰度发布引擎负责管理
故障快速定界定位
分布式日志采集
支持在大规模分布式环境中实时采集容器、中间件和应用的各种日志
海量日志在线检索
支持分布式环境海量日志的在线检索，支持多维度索引和模糊查询
调用链接可视化展示
通过分布式消息跟踪系统输出调用链，可视化快速地进行故障定界
运行日志故障定位
通过调用链的故障关键字，在日志检索界面快速检索故障日志，用于故障的精确定位
服务安全
敏感服务的授权策略
敏感服务如何授权，防止恶意调用
链路的安全防护
消费者和服务者之间的长连接，需要增加安全防护。例如基于Token的安全认证机制
3 架构组成
3.1 架构图
分布式服务架构的架构图如下图所示：

图3分布式服务架构图
节点角色说明
l 提供者：暴露服务的服务提供方。
l 消费者：调用远程服务的服务消费方。
l 服务注册中心：服务注册与发现的注册中心。
l 服务监控中心：统计服务的调用次调和调用时间的监控中心。
l 服务容器：服务运行容器。
调用关系说明
l 0.开始：服务容器负责启动，加载，运行服务提供者。
l 1.注册：服务提供者在启动时，向注册中心注册自己提供的服务。
l 1.0.审核：管理员对服务提供者注册的服务进行审核。
l 2.订阅：服务消费者在启动时，向注册中心订阅自己所需的服务。
l 3.通报：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
l 4.调用：服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
l 5.统计：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
3.2 服务路由
分布式服务框架上线运行时都是集群组网，这意味着集群中存在某个服务的多实例部署，消费者如何从服务列表中选择合适的服务提供者进行调用，这就涉及到服务路由。分布式服务框架要能够满足用户灵活的路由需求。
3.2.1 透明化路由
很多开源的RPC框架调用者需要配置服务提供者的地址信息，尽管可以通过读取数据库的服务地址列表等方式避免硬编码地址信息，但是消费者依然要感知服务提供者的地址信息，这就违反了透明化路由的原则。
基于服务注册中心的订阅发布，在分布式服务框架中，服务注册中心用于存储服务提供者的地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不需要像之前那样在代码中硬编码服务提供者的地址信息。消费者只需要知道当前系统发布了哪些服务，而不需要知道服务具体存在什么位置，这就是透明化路由。
消费者缓存服务提供者的地址，消费者调用服务提供者时，不需要每次调用都去服务注册中心查询服务提供者地址列表。消费者客户端从本地缓存的服务提供者路由表中查询地址信息，根据路由策略进行路由选择。
3.2.2 负载均衡
负载均衡策略是服务重要的属性，分布式服务框架通常会提供多种负载均衡的策略，同时支持用户扩展负载均衡的策略。
1、 采用随机算法进行负载均衡。
2、 轮循，按公约后的权重设置轮循比率。
3、 服务调用时延，消费者缓存所有服务提供者的服务调用时延，周期性的计算服务调用平均时延，然后计算每个服务提供者服务调用时延于平均时延的差值，根据差值大小动态调整权重。
4、 一致性哈希，相同参数的请求总是发到同一个服务提供者，当某台提供者宕机时，原本发往该提供者的请求，基于虚拟节点平摊到其他提供者，不会引起剧烈变动。
5、 粘滞链接，用于有状态的服务，尽可能让客户端总是向同一台提供者发起服务调用，除非该提供者宕机再连接另一台。
3.2.3 本地优先策略
在一些业务场景中，本地JVM内部也发布了需要消费的服务，优先调用本JVM内部发布的服务提供者，这种模式成为injvm模式。
如果物理机或者VM配置比较好，多个应用进程往往会选择合设。服务消费者和服务提供者可能会被部署到同一台机器上。服务路由时优先选择本机的服务提供者，如果找不到再重新发起远程服务调用，该模式成为innative模式。
3.2.4 路由规则
负载均衡、本地路由优先等路由通常可以满足大部分业务的线上需求，但是在一些场景中需要对路由策略设置一些过滤条件，比较常用的是基于表达式的条件路由和脚本路由。
3.2.5 路由策略定制
平台除了提供默认的路由策略之外，在架构上还需要支持业务扩展路由算法，实现业务定义路由。
3.2.6 配置化路由
路由配置的优先级：客户端配置>服务端配置>全局配置。配置策略的设计如下：
1、 本地配置：包括服务提供者和服务消费者、默认全局配置三种。
2、 统一注册管理：无论是服务提供者还是消费者，本地配置的路由策略统一注册到服务注册中心，进行集中化配置管理。
3、 动态下发：运维人员通过服务治理Portal修改路由规则，更新后的路由规则被持久化到服务注册中心。服务注册中心将变更后的服务路由策略或者规则下发给服务提供者和消费者。
3.3 注册中心
对于服务提供者，它需要发布服务；对于服务消费者，它最关心的如何获取它所需要的服务。对于服务提供方和服务消费方来说，它们还有可能兼具这两种角色。
如何有效地管理服务订阅/发布，避免硬编码地址信息是分布式服务框架需要解决的问题之一。通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理，服务注册中心就是专门来管理服务订阅/发布的配置管理节点。
3.3.1 特性设计
服务注册中心的工作原理图如下图所示：

图4注册中心工作原理图
1、 服务提供者在启动时，根据服务发布文件中配置的服务发布信息向注册中心注册自己提供的服务。
2、 服务消费者在启动时，根据消费者配置文件中配置的服务消费信息向注册中心订阅自己所需要的服务，消费者刷新本地缓存的路由表。
3、 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心主动推送变更数据给消费者，消费者刷新本地缓存的路由表。
4、 服务消费者从本地缓存的服务提供者地址列表中，基于负载均衡算法选择一台服务器提供者进行调用。
注册中心的功能设计特性主要包括：
1、 对等集群：注册中心某一个或者多个服务注册中心进程宕机，不会导致服务注册中心集群功能不可用。对于客户端，无论服务注册中心配置多少个进程，客户端只需要连接其中一个即可。
2、 提供CRUD接口。
3、 安全加固：主要涉及链路的安全性和数据的安全性。
4、 订阅发布机制。
5、 可靠性。
3.4 发布和引用
服务提供者需要支持配置、注解、API调用等方式，把本地接口发布成远程服务；对于消费者，可以通过对等的方式引用远程服务提供者，实现服务的发布和引用。
3.4.1 发布设计
消费者导入服务提供者的接口API定义，配置服务引用信息，即可在代码中直接调用远程服务，流程设计如下图所示：

图5服务发布流程图
1、 服务发布的方式：XML配置化的方式、注解、API调用，其中XML配置的方式具有很多优点，服务框架对业务代码零侵入、扩展和修改方便、修改配置不需要重新编译代码等。例如：<bean id=”echoService” class=”edu.neu.EchoServiceImpl” /><xxx:service interface=”edu.neu.EchoService” ref=”echoService”/>。
2、 代理：本地实现封装成代理，对于服务提供者将本地实现类封装成代理对象不是必须的；也可以利用一系列工具类解析服务提供者信息，然后将服务提供者的地址信息注册到服务注册中心。
3、 发布成指定协议：根据服务配置的属性信息，将服务发布成指定协议。需要指出的是，同一个服务允许发布成多种协议，例如：<bean id=”echoService” class=”edu.neu.EchoServiceImpl” /> <xxx:service interface=”edu.neu.EchoService” ref=”echoService” protocol=”HTTP,thrift” />
4、 服务提供者信息注册：将服务按照指定协议发布之后，需要将服务发布信息注册到信息中心。初始化服务注册中心客户端SDK，根据配置的注册中心地址连接注册中心，将服务提供者进行注册。
3.4.2 引用设计
消费者导入服务提供者的接口API定义，配置服务引用信息，即可在代码中直接调用远程服务，流程如下图所示：

图6服务引用流程图
1、 本地接口调用转换成远程服务调用：消费者导入服务提供者的本地API之后，在配置文件中引用远程服务提供者。例如：<xxx:reference id=”echoService” interface=”edu.neu.EchoService” /><bean class=”edu.neu.xxxAction” init-method=”start”><property name=”echoService” ref=”echoService”/></bean>
2、 服务地址本地缓存：消费者根据引用的服务名等信息，连接服务注册中心，获取已经发布的服务提供者地址等信息，缓存到本地的服务路由表中。服务路由的时候，直接从本地缓存的地址表中获取服务的地址信息，按照指定的策略进行服务路由。
3、 远程服务调用：消费者从本地缓存的服务列表中按照指定策略路由，将请求消息封装成协议消息；调用相关协议的客户端将请求发送给服务提供者，业务线程按照服务调用方式选择同步等待或者注册监听器回调。协议客户端读取到应答消息，将数据包解码成协议应答消息；在根据序列化格式将消息体反序列化成POJO对象，唤醒业务等待的线程（或者回调注册的监听器）；业务线程获得服务调用结果返回。如果消费者调用超时，按照集群容错策略执行Failover、Failcache等重试策略，来保证服务调用成功。
3.4.3 灰度发布
灰度发布是指在黑于白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式：让一部分用户继续用A，一部分用户开始用B；如果用户对B没有反对意见，那么逐步扩大范围，把所有用户都迁移到B上来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
3.5 优先级调度
当系统资源非常有限时，为了保证高优先级的服务能够正常运行，保障服务SLA，需要降低一些非核心服务的调度频次，释放部分资源占用，保障系统的整体运行平稳。支持服务发布时设置优先级策略，并在资源成为瓶颈时按照用户配置的优先级策略调度执行服务。
3.6 服务治理
随着业务的发展，服务越来越多，如何协调线上运行的各个服务，保障服务的SLA（Service-Level-Agreement服务等级协议），对服务架构和运维人员。是一个很大的挑战。线上业务发生故障时，需要对故障业务做服务降级流量控制、流量迁移等，快速恢复业务。为了规范服务的上线和下线，在服务发布前，需要走服务预发布流程，由架构师或者项目经理对需要上线的服务做发布审核，审核通过后才能上线。
服务治理框架就是为了满足用户以上的需求，对服务进行有效管控，保障服务的高效、健康的运行。服务治理的体系图如下图所示：

图7服务治理体系图
3.6.1 治理定位
面向物联网业务的服务治理，聚焦在对内采用统一服务框架服务化的业务运行态、细粒度的敏捷治理体系。
3.6.2 治理对象
基于统一分布式框架开发的业务服务，于协议本身无关，治理的可以是SOA服务，也可以是基于内部服务框架私有协议开发的各种服务。
3.6.3 治理策略
针对互联网服务的特点，例如突发的流量高峰、网络延时、机房故障等，重点对大规模跨机房的海量服务进行运行态的治理，保障线上服务的SLA，满足用户体验。常用的治理策略包括服务的限流降级、服务迁入迁出、服务动态路由和灰度发布等。
3.6.4 治理目标
1、 防止业务服务架构的腐化：通过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链分析，梳理不合理的依赖和调用路径，优化服务框架，防止代码腐化。
2、 快速故障定界定位：通过分布式日志采集框架，实时收集服务调用链日志、服务性能KPI数据、服务接口日志等，实时汇总和在线分析，集中存储和展示，实现故障的自动发现、自动分析和在线条件检索，方便运维人员、研发人员进行实时故障诊断。
3、 服务微管控：细粒度的运行期服务治理，包括限流降级、服务迁入迁出、服务超时控制、智能路由、统一配置、优先级调度和流量迁移等，提供方法级治理和动态生效功能，通过一些列细粒度的治理策略，在故障发生时可以多管齐下，在线调整，快速恢复业务。
4、 服务生命周期管理：包括服务的上线审批、下线通知，服务的在线升级，以及线上线下服务文档库的建设。
3.6.5 架构设计
服务治理是分布式服务框架的一个可选特性，尽管从服务开发和运行角度看它不是必需的，但如果没有服务治理功能，分布式服务框架的服务SLA很难得到保障，服务化很难真正实施成功。分布式服务框架的服务治理的架构图如下图所示：

图8服务治理逻辑架构图
第一层叫做服务治理展示层，它主要由服务治理Portal组成，提供可视化的界面，方便服务运维人员进行治理操作。
第二层叫做服务治理SDK层，它主要包括服务治理元数据，服务治理实体对象，服务模型、应用模型、治理组织模型、用户权限模型等；服务治理接口，服务治理Portal调用服务治理接口实现服务治理；服务治理客户端类库，服务治理Portal需要集成分布式服务框架的客户端类库，实现服务的自动发现和调用；调用示例，客户端SDK需要提供服务治理接口的参数说明、注意事项以及给出常用的调用示例，方便前端开发人员使用；集成开发指南，指导使用者如何在开发环境中搭建、集成和使用服务治理SDK。
第三层叫做后台服务治理服务层，由一组服务治理服务组成，可以单独部署，也可以与应用组合部署。考虑到健壮性，通常选择独立集群部署。
3.6.6 运行态功能设计
运行态服务治理首先要能够做到可视，包括当前系统发布了哪些服务，这些服务部署在哪些机器上，性能KPI数据如何，指标是否正常等。除了告警，对服务健康状态和关键指标的日常巡检也非常重要。服务的发布情况和运行状态是首先需要关注的。
3.6.7 线下治理
随着服务化的推进，服务的开发者越来越多，服务之间的互相调用和依赖也日趋复杂，另外搭建一套线下的全量化境成本非常高。为了解决这个问题，需要建立服务文档中心，方便线上运维人员查看和多团队之间协作。
它的工作原理如图所示：

图9服务治理逻辑架构图
服务的上线审批、下线通知机制需要建立并完善起来，它的工作原理如下图所示：

图10服务上线审批、下线通知图
除了以上常用的治理措施，线下服务治理还包括：
1、 业务的梳理、服务划分原则和方法论。
2、 服务跨团队协作流程、准则、工具和方法论。
3、 服务的接口兼容性原则和规范。
3.6.8 安全和权限管理
分布式服务框架的安全主要涉及到两个层面，一个是服务的开放和鉴权机制；另一个是服务治理的安全和权限管理。服务治理框架需要提供角色和权限模型，用于用户定义角色并进行授权，同时要提供账号和角色关联管理功能，方便对账号进行授权。
3.7 中间聚合层
服务本身是零散化的东西，通常要接入的是中间层。实际上会在中间层做聚合，聚合层本身即可以做业务聚合，也可以做中间层的聚合，每一层的聚合都要做异步调用的设计。同时要对接口进行抽取，。这样的话才能给应用使用。因为应用。本身是没有服务发现的下，图是以服务的方式聚合中间层的架构图：

图11以服务的方式聚合中间层架构图
4 微服务架构
4.1 带来的变革
4.1.1 应用解耦
服务化之前，一个大型的应用系统通常会包含很多个子应用，不同子应用存在很多重复的公共代码，所有应用公用一套数据库。
架构图如下图所示：

图12传统应用架构图
微服务架构出现将功能服务化，应用作为消费者直接调用服务，这样就实现了对原因重复代码的收编，同时系统之间的调用关系也更加清晰。
架构图如下所示：

图13传统应用架构图
4.1.2 分而治之
当垂直应用越来越多时，应用之间的交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的底层微服务，使得前端应用能更快速的响应多变的市场需求。
4.1.3 敏捷交付
软件解决方案的敏捷性，指的是它能够快速进行变更的能力。敏捷性是微服务架构特性中最显著的一点：敏捷性的产生，是将运行中的系统解耦为一些列功能单一服务的结果。微服务架构能够对系统中其他部分的依赖加以限制，这种特性能够让基于微服务架构的应用在应对Bug或是对新特性需求时，能够快速的进行变更。
4.2 架构解析
微服务架构是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。
传统架构和微服务架构对比图如下图所示：

图14传统架构和微服务架构对比图
5 集成ESB
企业服务总线（EnterpriseServiceBus，ESB）从面向服务体系架构发展而来，是传统中间件技术与XML、Web服务等技术结合的产物。服务框架对ESB进行了集成。
ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互联互通，是一种在松散耦合的服务和应用之间标准的集成方式。
分布式服务框架虽然集成了ESB总线的功能，但是不作为框架服务的首选。因为ESB要求用户手工注册和管理服务，这样增加用户使用和维护成本。
6 提供的服务
6.1 用户和组织机构
分布式服务框架能够提供统一的用户和组织机构管理，通过建立一整套完成的、独立基础信息数据库，框架可以对外提供用户登录服务。
6.2 权限管理
分布式服务框架能够提供统一的角色权限管理，权限包括操作权限和数据权限。通过建立一整套完整的、独立的角色、映射、模块、操作、数据权限配置等基础信息数据库，框架可以对外提供权限服务。
6.3 单点登录
分布式服务矿建能够提供统一的单点登录服务，用户第一次登陆系统是，首先跳转到框架的认证中心，认证中心根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
6.4 通信服务
分布式服务框架能够提供基本的通信服务，例如集成发送短信或者微信的功能。通过框架提供的统一短信配置Portal或者微信公共账号，在某个业务工作节点给指定用户发送短信或者微信信息。
6.5 业务提醒
分布式服务框架能够提供业务提醒的功能，通过建立业务提醒数据表和发布统一的提醒服务，实现框架的业务提醒功能。各个业务应用的前台页面通过定时请求，来自动获取该业务的提醒信息，显示在前台页面中。或者采用发送短信、微信等方式提醒系统内的相关人员。
6.6 待办工作
分布式服务框架能够提供个人待办工作处理的功能，通过建立待办工作数据表和发布待办工作服务，实现个人的待办工作的处理功能。
6.7 工作流服务
首先用户的业务流程梳理是一项非常繁重的工作，往往在信息系统应用之前用户有一套完成的工作流程。在开展信息系统工作之后，又针对信息系统的特点对业务流程进行规范。不同的信息系统应用又存在不同的业务流程定义，这又增加了业务流程梳理的难度。因此在分布式服务框架产生之初，就应该对本单位系统的业务流程进行梳理和标准化。
分布式服务框架提供了统一的业务流程调用服务，其工作步骤包括流程设计、流程测试、数据清理、流程部署和流程注销等功能。
6.7.1 流程定义
分布式服务框架应提供可视化的流程设计界面，开发人员或者系统运维人员可以通过可视化的流程设计器进行业务流程设计。如下图所示：

图15流程设计图
在流程设计页面中设计人员可以采用鼠标拖拽的方式进行流程设计。生成的流程XML文件如下：
<?xml version="1.0" encoding="GBK"?>
<workflow dump="true" xmlns:c="c" xmlns:wf="wf" xmlns:demo_wf="demo_wf" alwaysAssignOwner="true">
<description>财务处子流程</description>
<config></config>
<actions>
<action id="rejectStep" forReject="true" visible="false">
<meta>
<argNames>rejectStepIds</argNames>
</meta>
</action>
<action id="start" name="启动财务流程">
<transition splitType="or">
<to-step stepId="chiefCheck">
<conditions>
<c:eval>gt(wfRt.args.cashAmount,1000)</c:eval>
</conditions>
</to-step>
<to-step stepId="record"></to-step>
</transition>
</action>
<action id="sendForRecord" name="发送会计">
<transition>
<to-step stepId="record"></to-step>
</transition>
</action>
<action id="finish" name="结束">
<transition>
<to-end />
</transition>
</action>
</actions>
<start-step>
<actions>
<common-action id="start" />
</actions>
</start-step>
<steps>
<step id="chiefCheck">
<assignment>
<role id="role_accountChief" />
</assignment>
<actions>
<common-action id="sendForRecord" />
</actions>
</step>
<step id="record">
<assignment>
<role id="role_accountRecord" />
</assignment>
<actions>
<common-action id="finish" />
</actions>
</step>
</steps>
</workflow>
6.7.2 流程测试
流程设计完成后，设计人员点击保存按钮，即完成了流程的部署。进入相应的业务模块，选择流程节点用涉及的用户、角色即可对设计完的流程进行测试。
6.7.3 数据清理
流程测试完毕后，由测试人员对测试数据进行清理。
6.7.4 流程审批
经过测试完成的流程定义，在正式上线之前必须进行流程审批。审批通过后方可允许业务部门使用。
6.7.5 流程部署
流程审批通过后，由系统运维人员或者开发人员进行流程部署上线。
6.7.6 流程升级/注销
在业务流程实施过程中，业务规则发生变化，这是要对业务流程定义进行调整或者注销。如果业务流程变化很小，则需要对原有的流程定义进行升级改造，形成该流程定义的升级版本。如果业务流程发生根本改变，则对现行的流程定义进行注销操作，重新拟制一个新的流程定义。