分布式服务框架
随着业务的扩展，应用规模不断扩大，系统内部巨无霸应用越来越多，常规的垂直应用架构无法应对复杂业务带来的各种挑战。通过将业务公告能力抽象成原子服务，对复杂应用进行水平拆分合垂直拆分，实现服务消费者和生产者的解耦，降低重复模块开发的人力成本和时间成本。
框架功能
尽管不同的分布式框架实现细节略有差别，功能特性也不近相同，但是都具有以下基本特性。
-
服务订阅与发布 ：
- 配置化发布和引用服务： 客户端通过xml文件配置进行服务的引用，服务端通过xml文件配置进行服务的发布，降低代码的侵入性；
- 服务自动发现机制： 支持服务试试自我发现，注册中心推送服务的上线下线或者地址变更，对于客户端来说服务透明化，降低消费者和服务者耦合性。
-
服务在线注册和去注册： 支持运行态服务的上下线，对于消费端来说，具有消息通知机制保证服务状态的更新。
-
服务路由：
- 支持默认路由： 例如随机,轮询，权重路由策略。
-
路由定制: 支持用户个性化路由策略定制。
-
集群容错：
- FailOver机制: 失败自动切换，当出现失败，重试其他服务器，通常用于读操作
- Failback机制： 失败自动回复，日志记录失败请求，定时重发，通常用于写操作
-
Failfast机制： 快速失败，只发起一次调用，失败立即报错。
-
服务调用：
- 同步调用： 消费者发起服务调用后，阻塞等待服务端响应。
- 异步调用： 消费者发起调用以后，不阻塞立即返回，由服务端返回应答异步通知消费端。
-
并行调用： 消费者同时对多个服务发起调用。
- 多协议支持：
- 支持公有协议：
-
支持私有协议:
- 序列化：
- 二进制序列化： 支持Thrift, Protocol buff等二进制协议，提升序列化性能
- 文本序列化： 支持json,xml等文本类型的序列化方式，提升通用性和可读性。
- 统一配置管理：
- 本地静态配置： 安装部署修改一次，运行态不修改的配置，可以存放在本地配置文件中。
- 基于配置中心动态配置： 运行太需要调整的参数，统一放到哦欸之中心(服务注册中心)，修改之后同意下发，即时生效
系统可靠性
服务由单机应用扩展为多机集群甚至多机房调用，由于机器/网络故障等原因，都由可能导致服务调用失败，导致业务失败率增加，分布式服务框架需要具备很强的可靠性，具体措施如下：
- 服务注册中心：
- 服务健康状态检测： 注册中心通过心跳检测服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。
- 故障切换： 注册中心对等集群，任意一台宕机，将自动切换到另一台
- 高可用： 注册中心全部当掉，消费者和服务者仍能通过本地缓存进行通信。
- 消除单点故障：
- 服务无状态：
- 服务避免全局吗变量，人员一台宕机，不影响使用
- 服务集群容错：只要就能中一台服务提供者可用，业务就不会中断。
- 网络链路健壮性：
- 心跳检测： 网络链路空闲时没有业务消息，通过定时心跳检测链路是否可用。
- 断连重连机制： 链路意外断连后，根据客户端配置的重连策略定时重连，重连 成功自谦消息不会路由到服务提供者上。
性能要求
应用分布式化以后，由原来的本地API调用变成跨进程/跨机器、甚至跨区域调用，网络通信、消息序列化和反序列化、反射调用和动态代理等都会导致性能损耗，了如果服务框架性能比较差，时延将会被方法数十倍，因此，分布式服务框架的性能指标非常重要。
| 指标 | 说明 |
|---|---|
| 高性能 | 在同等资源占用情况下，但服务提供者TPS尽量要高。 |
| 低时延 | 在同等资源占用情况下，服务调用时延要尽量低 |
| 性能线性增长 | 扩展服务提供者，性能要能够线性增长 |
注：
