分布式服务框架原理与实践

传统垂直应用架构：MVC架构(Spring+Struts+Hibernate/iBatis+Tomcat)、LAMP架构（linux+Apache+PHP+MySQL）
    MVC 
        1.视图展示层
        2.调度控制层：接受请求，调用相应模型组件处理请求，调用相应视图显示模型的数据
        3.应用模型层：应用程序主体部分，模型代表了业务数据和业务执行逻辑
    标准MVC不包含数据访问层，实际开发中使用ORM

    业务组网：小规模应用通常做双热机，服务端监听浮动IP，通过Watch 
    Dog监测应用进程，判断应用宕机后切换到备用机中然后尝试重新拉起主机。

    在高并发、大流量应用中，需要做集群通过 F5等负载均衡器做7层负载均衡，
    后端做对等集群部署。

缺点：1.维护成本变高，部署效率降低，某个功能(编译、测试)出错，需要重新打包
     2.团队效率差，部分公共功能重复开发
     3.系统可靠性变差，某个节点故障会导致分摊到其它节点的流量陡增，引起“雪崩效应”
       垂直框架将所有模块部署到一个进程中，某个应用接口故障，导致整个节点宕机，
       由于对等集群部署，因此其它节点也有类似问题，宕机可能此起彼伏，严重影响业务运行
     4.维护与定制困难，业务代码不断膨胀，功能复杂，无法拆分，代码修改一发动全身。
     5.新功能上线周期变长  一是公共API变更  二是新特性无法独立部署

RPC  remote procedure call 远程服务调用
    负责屏蔽底层传输方式(TCP,UPD)、序列化方式(XML,JSON,二进制)和通信细节。

微服务（MSA）
    特征： 1.原子服务，高内聚低耦合，专注于做一件事情
           2.高密度部署：重要的服务可以独立进程部署，非核心服务可以独立打包，合设到一个进程中
            物理机可以一台机器多个服务实例进程，云部署可以利用Docker实现容器级部署，提高利用率
           3.敏捷交付：小团队负责整个生命周期支持！
           4.微自治：服务足够小，功能单一，可以独立打包部署升级回滚弹性伸缩，不依赖其它服务，
                局部自治。实现

横向：分角色拆分，客户域，产品域，订单域
纵向：将系统公共模块拆分出来，即服务，然后业务调用服务完成事务
      前台一个集群，service一个，数据访问服务一个  独立集群

服务治理
    1.生命周期管理，服务上线随意。下线困难，上线审批测试发布，服务下线通知机制需要规范化
    2.服务容量规划：
    3.运行期治理：核心服务流量压力大，非核心服务采取降级、限流。数据库方面，可以调大服务调用超时
       时间保证成功率。
    4.服务安全：敏感数据服务化后，如何对消费者授权，防止非法数据访问，以及不同消费者不同权限等

SOA服务治理周期： 
    1.计划：确定服务治理的重点。
    2.定义：定义服务治理模型。
    3.启用：实现并实施治理模型。
    4.度量：根据实施效果，改进治理模型。

Dubbo工作原理   注册中心使用Zookeeper
    1.轻量级Java容器通过main函数初始化Spring上下文，根据服务提供者配置的XML文件将服务按照指定协
      议发布完成服务初始化工作。
    2.服务提供者根据配置服务注册中心地址链接服务注册中心，将服务提供者信息发布到服务注册中心。
    3.消费者根据服务消费者XML配置文件的服务引用信息，链接注册中心，获取指定服务地址等路由信息。
    4.服务注册中心根据服务订阅关系，动态向指定消费者推送服务地址消息。
    5.消费者调用远程服务时，根据路由策略，从本地缓存服务器地址列表选出一个服务提供者，然后根据
      协议类型建立链路，跨进程调用服务提供者(非本地路由优先策略时)。

主要质量属性如下：
    1.连通性，
            ①注册中心负责服务地址注册、查找，相当于目录服务，不转发请求，压力小
            ②监控中心负责统计服务调用次数，时间等，统计汇总后定时发送到监控中心服务器
            ③服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，
             同时汇报调用时间到监控中心。
            ④注册中心、服务提供者、消费者之间为长连接，监控中心除外
            ⑤注册中心通过长连接感知服务提供者存在，服务宕机，立刻通知消费者
            ⑥注册中心、监控中心宕机，不影响已运行的提供者和消费者，消费者有缓存服务者地址
            ⑦注册中心、监控中心可选，服务、消费者可以直连。
    2.健壮性
            ①监控中心宕机不影响使用，只是丢掉部分采样数据
            ②注册中心数据库宕机，注册中心仍能够通过缓存提供服务列表查询，但不能注册新服务
            ③注册中心对等集群，任一台宕机，自动切换另外一台
            ④注册中心全部宕机，服务提供者、消费者能通过本地缓存的地址通信
            ⑤服务提供者无状态，任一台宕机，不影响使用
            ⑥服务提供者全都宕机，消费者无法使用，重连等待恢复

    3.伸缩性
            ①注册中心为对等集群，可动态增加机器部署，客户端自动发现新的注册中心
            ②服务提供者提供无状态，可动态增加机器，注册中心将推送新的服务器信息给消费者

    4。扩展性
            ①微内核+插件式设计，平等对待三方
            ②管道式通知方式，服务调用前后提供拦截面，可用于功能扩展，基于Filter
            ③原子化扩展点，最大化复用和扩展，扩展点是功能的抽象，只负责完成一件事情

淘宝HSF       注册中心使用基于数据库的ConfigServer
    1.配置化开发，对业务代码低侵入
    2.插件管理体系：平台与应用分开部署，运行期依赖，外部采用独立的ClassLoader隔离，内部OSGI
    3.异步NIO，通信框架采用Mina封装的TB-Remoting，支持java序列化，Hession，C与P长连接通信
    4.灵活路由能力：客户端软负载，随机、轮询等多种路由策略，支持容灾和失效恢复
    5.多协议支持WebService、Hession、PB（Protocol buffer）
    6.服务治理：支持多维度服务治理策略，包括服务监控、服务分组、限流降级、服务授权等

架构原理： service 、Filter Chain、RPC。三层

性能特征： 
    1.高性能：同等资源TPS尽量高
    2。低资源，同等资源，服务调用延迟尽量低
    3.性能线性增长，增加服务器，性能线性增长。

通信框架

长连接：1.多消息复用一条链路，省资源，短连接每次发送消息都要创建链路、发起握手认证、关闭
       2.远程通信是常态，调用时延是关键指标，网络时延远远大于一次简单服务调用时不可接受的

#同步异步关注点是你问内核数据有没有准备好，还是内核主动通知你数据有没有准备好。

BIO 同步阻塞IO 一个连接一个线程  1：1----> 使用线程池优化为 伪异步 M：N  N可以大于M

NIO    同步非阻塞，提交I/O请求，然后做别的事情，定时轮询是否完成
               同步体现在 selector 仍然要去轮循判断 channel 是否准备好
               非阻塞体现在这个过程中处理线程不会一直在等待，可以去做其他的事情。

//通信层面NIO相对BIO而言，是异步的，所以有很多人习惯说NIO是异步非阻塞IO
//通信层面而言是异步的，服务调用的异步没必然联系，传统的BIO也可以实现异步服务调用
//例如利用java的FutureTask来实现异步服务调用。

AIO 异步非阻塞IO  一个请求一个线程，Client传数据以后做别的事情，Server完成通知Client
                                 （NonBlockingIO）
客户端个数：IO线程个数    BIO     伪异步              NIO        AIO 
                       1：1     M：N N可以大于M     M:1      M：0 系统帮忙完成
IO类型                   同步    同步            同步(IO复用)    异步
调试难度               简单      简单              复杂          复杂
可靠性                  极差     差                高            高
吞吐量                  低        中              高            高

Reactor模式
Proactor模式

链路有效性检测
    心跳检测机制
        1.TCP层心跳检测，Keep-Alive机制，作用域整个TCP协议栈。
        2.协议层，主要存在于长连接协议中，例如SMPP协议
        3.应用层，主要由各业务产品通过约定方式定时给对方发送心跳消息实现。
    目的：确认当前链路可用。
    Netty心跳机制类型
        1.Ping-Pong型：由通信一方定时发送Ping消息，对方接收到后立刻返回pong应答
        2.ping-ping：不区分心跳请求和应答，由通信双方约定定时向对方发送心跳ping
          消息，属于双向心跳。
    心跳策略：
        1.连续N次心跳检测没有收到对方pong应答消息，或ping请求消息，则认为链路已经
          发生逻辑失效，称为心跳超时。
        2.读取和发送心跳消息的时候如果发生了IO异常，说明链路已经失效，被认为心跳失败
    无论是超时还是失败，都需要关闭链路，由客户端重新发起重连操作，保证链路恢复正常。
    Netty心跳检测实际上利用链路空闲机制
        1.读空闲，链路持续时间t没有读取到任何消息
        2.写空闲，
        3.读写空闲，   此时空闲机制是发生超时异常，关闭连接，可以定制超时实现机制。
          如：关闭链路，重连，警告，打印日志等
    
断线重连机制，当发生如下异常的时候，客户端需要释放资源，重新发起连接。
        1.服务因为某种原因，主动关闭连接，客户端检测到链路被正常关闭。
        2.客户端因为宕机，强制关闭连接，客户端检测到链路被Rest掉。
        3.心跳检测超时，客户端主动关闭连接
        4.客户端因为其他原因(如解码失败)，强制关闭。
        5.网络故障，丢包，超时，单通等。
    中断后客户端等待INTERVAL时间重连，循环尝试，直到成功。

消息缓存重发
    调用消息发送接口，消息没有真正写入Socket中，而是放入NIO通信框架的消息
    队列中，由Reactor线程扫描待发送的消息队列，异步地发送给通信对端，若消息
    队列积压信息，此时中断，Netty提供了在调用ChannelHanlerContext.write()
    的时候，返回ChannelFuture对象可以在这个上面注册监听Listener，在Listener
    的operationComplete()中判断操作结果，若不成功，将其添加到重发队列。重连
    以后根据策略，将缓存队列中消息重发给通信对端。

性能差的原因
    1.网络传输问题。传统RPC框架或者基于RMI等方式的远程服务，采用同步阻塞IO，
      当客户端的并发压力或者网络时延增大，效率降低。
    2.序列化性能差，java序列化不支持其它语言反序列化，码流大，序列化性能差
      占用系统资源。
    3.线程模型问题，线程资源在JVM中有限，阻塞IO导致线程无法及时释放系统性能
      急剧下降。
通信性能原则
    1.传输：BIO，NIO，AIO决定了通信的性能
    2.协议：采用什么通信协议，公有HTTP，或私有
    3.线程：数据吧如何读取，读取以后编解码在哪个线程进行，解码后消息如何派发
      Reactor线程模型不同对性能的影响也非常大。
Netty高性能的总结
    1.异步非阻塞通信
    2.高效IO线程模型：Reactor单线程模型、Reactor多线程模型、主从Reactor多线程模型
    3.高性能序列化框架：默认提供了Protobuf二进制序列化框架，可以基于Netty提供的编解码
      框架扩展实现。
客户端线程池通常根据客户端连接数，评估IO数，创建一个大的线程池NioEventLoopGroup，所有
客户端连接公用，或者创建一个包含NioEventLoopGroup数组，将客户端连接按照Hash算法分组，
所有连接均匀打散在NioEventLoopGroup中，优点是降低锁竞争，提升处理效率。

序列化(编码)与反序列化(解码)：对象序列化为字节数组，用于网络传输、数据持久化等
    通信协议与序列化是解码的，同一种协议有多种序列化方式。
    文本类：XML、JSON等   二进制：PB(Protocol Buffer)、Thrift、Hession
    核心要求：
        1.数据结构种类，接口是否友好、简洁、可读性
        2.跨语言支持
        3.兼容性：接口的兼容(定义，输入参数，返回值)
                 业务的逻辑兼容，接口兼容是前提，内部实现的业务逻辑也要向前兼容
                 ，例如根据新增字段判断新老流程，老的业务消息没有携带扩展的字段就
                 走老流程，新的走新的流程。
                 数据的兼容性：包括但不限于关系型数据库、菲关系型数据ku，表、索引等
        4.性能：
                序列化后的码流的大小
                序列化反序列化的速度
                资源占用主要是CPU和堆内存

扩展性设计
    Netty内置的序列化反序列化功能类http、PB、base64、JBoss、spdy等

反序列化扩展
    分布式服务框架中反序列化扩展包含两部分
        1.业务发布服务的时候，可以指定协议类型和承载数据的序列化方式。
        2.序列化类库能够以插件的格式插入到通信调用链中，实现序列化格式的扩展
          这个过程需要考虑TCP的粘包和拆包等底层相关的技术细节。
    半包处理，在反序列化之前需要保证调用解码方法传递的是完整的数据包。否则会
    解码失败。

TCP的粘包和拆包
    TCP数据包的一个数据包包含两个数据包 接收端不知道这两个数据包的界限所
    以对于接收端来说很难处理，或者接收端收到了两个数据包但是这两个数据包要么
    是不完整的，要么就是多出来一块。
发生TCP粘包或拆包有很多原因，现列出常见的几点，可能不全面，欢迎补充，
    1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
    2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
    3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送‘’出去，将会发生粘包。
    4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
    等等。
    解决办法
        1.发送端给每个数据包添加包首部
        2、发送端将每个数据包封装为固定长度，不足补0。
        3、可以在数据包之间设置边界，如添加回车、添加特殊符号。

Netty提供了4种反序列化工具类
    LineBasedFrameDecoder       回车换行解码器
    DelimiterBasedFrameDecoder  分隔符解码器
    FixedLengthFrameDecoder     固定长度解码器
    LengthFieldBasedFrameDecoder  通用半包解码器(即带首部)

序列化扩展只需要继承MessageToByteEncoder类实现encode()

序列化调用全局锁，性能下降严重，可以每一个线程聚合一个序列化反序列化类库，避免竞争。

协议栈：不同服务在性能上适用不同协议进行传输，如：对接异构第三方通常用HTTP、Restful
等公有协议，对于内部不同模块之间的服务调用，用性能高的私有二进制私有协议。
    WSDL：服务提供者通过这个协议向注册中心提供服务接口描述。
    UDDI：注册中心通过此协议发布服务提供者的服务。
    SOAP：消费者通过此协议调用服务提供者，实现服务远程调用。 XML序列化 
    (PS:HTTP、WebService等公有协议缺少服务描述文件、服务注册中心和服务订阅发布机制)

内部长连接采用IP地址的安全认证机制，对握手请求IP地址做合法性校验
第三方非信任域则需要采用如:基于密匙和AES加密的用户名+密码验证合法性，用SSL/TSL安全传输

若涉及到大的不兼容修改，建议升级协议版本号，新增部分特性的话，可以用消息头的Map扩展

服务路由
    基于服务注册中心的订阅发布
        消费者只需要知道当前系统发布了哪些服务，而不需要知道服务具体在什么位置，这就是
        透明化路由，例如使用Zookeeper

    负载均衡
        一.随机
        采用随机算法进行负载均衡，通常在对等集群组网中，随机路由算法消息分发还是比较均匀
        缺点如下：
                 1.在一个截面上碰撞的概率比较高。
                 2.非对等集群组网，或者配置差异较大，会导致节点负载不均匀。
        通常实现会采用JDK的Random或SecureRandom

        二.轮询
        按公约后的权重设置轮询比率，达到边界以后，继续绕接，缺点是存在慢的提供者累积请
        求问题，如：第二台机器比较慢，没宕机，请求调到第二台时就卡那，久而久之所有请求
        都卡在调到第二台上。

        三.服务调用时延
        消费者缓存所有服务提供者的服务调用时延，周期性计算服务调用平均时延，然后计算
        每个服务提供者调用时延与平均时延的差值，根据差值大小动态调整权重，保证服务时
        延大的服务提供者接受更少的消息，防止消息堆积。特点是使所有服务提供者服务调用
        时延接近平均值，实现负载均衡。

        四.一致性hash
        相同参数的请求总是发送到同一个服务提供者，当某一台服务提供者宕机时，原本发往该
        提供者的请求，基于虚拟节点平摊到其它提供者，不会引起剧烈变动，平台提供的默认虚
        拟节点数可通过配置参数调整。

        五.粘滞连接
        用于有状态服务，尽可能让客户端总是向同一个服务提供者发起服务调用，除非该机器宕机
        再连接另外一台。

    本地路由优先策略                                                                       1.injvm模式
        优先寻找本JNM内的服务提供者。

        2.innative模式
        如果物理机或虚拟机配置好，多个应用进程会合设，消费者、服务者可能被部署
        在同一台机器上，服务路由时优先选择本机的服务提供者，找不到再远程调用。
            首先在本进程JVM上找，找不到下一步
            选择服务提供者IP地址与本机相同的本地合设的服务提供者，找不到下一步
            远程找
        优点，通信流量走本地网卡回环，不占用网络带宽，可靠性更强，服务调用时延低，
        节省带宽。

    路由规则
        条件路由规则
            1.通过IP条件表达式进行黑名单控制 例如：consumerIP!=192.168.1.1
            2.流量引导，只暴露部分服务提供者，防止其他服务提供者受影响
              providerIP=192.168.3*
            3.读写分离：method=find*，list*，get*，query*=>providerIP=x.x.x.*
            4.前后台分离:app=web*=>providerIP=192.168.1.*,app=java*=>providerIP
              =192.168.2.*。
            5.灰度升级，将Web前台应用路由到新的服务版本上：app=web*=>providerIP=
              192.168.1.*;

        脚本路由规则
            特点是通常支持动态编译，修改后可以实时生效，不需要重启系统。

    路由策略定制
        应用场景如下：
        1.灰度升级，用户需要按照业务规则进行灰度路由：例如按照用户省份、来源终端(PC
            IOSAndroid)、手机号段、app版本等，不同用户按照不同的规则路由到相应的集群。
        2.服务器故障、业务高峰期导流：将异常峰值流量导流到几台或一台服务器上，防止整个
          集群崩溃。
        3.与业务领域强相关的非通用路由定制需求。

        扩展策略如下：
            1.平台提供路由接口供用户实现。
            2.平台提供路由配置XML Schema定义，支持用户扩展
            3.业务发布自定义路由策略，对于通过Spring Bean方式的服务发布，用户定义扩展
              路由Bean，然后在服务提供者配置路由规则的时候，引用相关扩展的Bean

集群容错
    通信链路故障
        1.一方宕机
        2.解码失败
        3.IO异常
        4.网络故障、交换机
        5.心跳超时
        6.FULL GC导致链路中断
    服务调用超时
        1.IO阻塞或执行长周期任务
        2.服务端处理速度慢
        3.服务器长时间GC，服务无应答

    服务调用失败
        1.解码失败
        2.消息队列满了，系统拥堵
        3.动态流量控制
        4.权限校验失败
    容错策略
        failover 失败自动切换重新选路，一般重试3次
        failback 不再重试，直接将RPC异常通知给消费者
        failcache 失败自动恢复的一种，应用场景：服务有状态，等待一定时间重试
                  对时延不敏感的，调用失败通常是链路不可用、流控、GC，稍等重试
        failfast  业务高峰期，非核心服务希望只调用一次，获取异常后仅仅记录日志

    容错策略扩展    
        1.容错接口开放
        2.屏蔽底层细节，用户定制简单
        3.配置应该天生支持扩展，不应让用户扩展服务框架Schema

服务调用(解决串行调用效率低)  
    一、异步调用 将服务调用时间串行优化为并行  
      同步为T = t1+t2+...    异步为：T=Max(t1,t2,....)
                        (PS某些关键服务出故障，可用来防止故障扩散)
      异步有两种方式
            1. Future-Listener 更好，但是有局限性
          2. Future-get

    二、并行服务调用
          串行服务调用链，调用简单，采用并行服务调用来降低时延
                 多个服务逻辑上不存在互相依赖关系，可并行
              长流程业务，调用多个服务，时延敏感，部分不存互相依赖服务可并行
       目标：降低时延、提升系统吞吐量

    实现可采用Fork-Join，但是会开启多个线程来分解任务，在服务器框架中会导致线程
    上下文传递的变量丢失、线程膨胀等不可控问题，因此一般框架自己实现。get会等所有
    并行任务结束，获取所有结果。

    泛化调用：
        1.泛化引用：用于客户端没有APi接口以及数据模型的情况
        2.泛化实现：用于服务端没有APi接口以及数据模型的情况
    参数、返回值中所有POJO都用Map表示通常用于框架集成测试、上线后的回声测试等

服务注册中心
    客户端连接注册中心以后，需要对服务注册中心数据进行操作CRUD接口
        增删改查

    安全加固：链路安全性、数据安全性。 基于IP或usrname，pwd
            数据权限控制。
    订阅发布机制
    可靠性

基于Zookeeper的服务中心设计(任一台宕机不影响客户端使用)
    集群2n+1  通常n+1可用，会选举leader根据事务id(zxid)确定同步点，
    原子广播Zab协议：恢复模式(集群启动、leader崩溃)、广播模式  
                   保证leader、server系统状态相同。
    follower服务Client请求 ，对改变系统状态的更新操作leader来进行提议投票
    超半数通过返回结果给Client

服务发布设计
    发布方式
        1.XML 代码零侵入、扩展修改方便、不需要重新编译代码
        2.注解  对业务代码低侵入、扩展修改方便、但是需要重新编译代码
        3.API调用  侵入性强、容易与某种具体服务框架绑定、需重新编译
    灰度发布

参数传递
    业务内部参数传递
        1.通过方法调用显示传参
        2.通过ThreadLocal   优点，不需要通过参数引用传参。局限性，只能在本线程

    服务框架内部参数传递
        一般采用通过消息上下文进行消息传递，例如在业务请求参数中定义Map<String,Obj>
        扩展参数，用于跨线程的参数传递

外部传参
    1.服务框架自身的参数传递，如：分布式事务中的事务上下文信息传递
    2.业务之间的参数传递，如：业务调用链ID的传递，用于唯一标识某个完成业务流程。
通信协议支持
    最好的是使用Map<String,byte[]>     RPCContext.set(key,value);
    框架需要提供传参接口 如 RPCContext，用户按照规则把参数设置到平台上下文中

PS：防止服务框架系统参数、业务参数相互覆盖(使用的Map)
    参数应该进程生命周期管理，防止内存泄漏。

服务版本号
    主版本号：表示重大特性或功能改变，接口或者功能可能不兼容
    此版本号：发送了少部分功能变更，新增了一些功能。
    微版本号：主要用于修复BUG，对应常见的SP补丁包
  通常每个服务都加上版本号，不利于管理，因此将经常升级的服务单独拿出来打包，不经常
  升级的一起打包，其中一个升级就修改全局版本号

基于版本号的服务路由，没找到就抛异常

服务热升级
    1.升级的节点需要重启，但是由于分布式服务框架具备服务的健康检测和自动发现机制，停机
      升级的节点被自动隔离，停机并不会中断业务。
    2.服务路由规则的定制：如果是滚动式灰度发布，在相当长的一段时间内线上都会存在多个服
      务版本。由路由判定用户的版本。也可以用户配置自定义的路由规则来支持灵活路由策略。
    3.滚动升级回退机制：无论预发布环境中测试多么充分，真实生产环境中仍可能出BUG，此时
      需要热回退。为了降低服务热升级对业务的影响，同时考虑可靠性，滚动升级，分批次进行
      服务热升级，这样可以及时发现问题，更敏捷地进行特性交付。

OSGi 用Maven+分布式服务框架自身的服务接口导入导出功能解决了模块化开发和精细化依赖管理
     难题，完全可以替代OSGi

流量控制
    传统静态流控 ：达到流控阀值后拒绝新的请求消息接入，但是不拒绝后续的应答消息。
    加入新机器需要手动调整，机器宕机导致分流不均，云服务弹性伸缩特性决定了
    传统方案行不通。

    动态配额分配制
        服务注册中心以流量周期T为单位，动态推送每个节点分配的流控QPS，服务节点变更
        会触发注册中心重新计算每个节点配额，然后进行推送。
    
动态流控
    动态流控因子
        系统资源：CPU、内存
        应用资源：JVM堆内存、消息队列积压率、会话积压率(可选)

    分级流控(一级拒绝1/8  二级1/4)
        流控阀值需要支持在线修改和动态生效。

并发控制
    针对线程的并发执行数，本质是限制某个服务或者服务的方法过度消费，影响其它服务。
        1.针对服务提供者的全局控制
        2.针对消费者的局部控制

    服务端bean 的 executes参数指定数量(支持方法级别)
    客户端         actives指定(支持方法级别)

连接控制
    服务端连接数流控<xxx:protocol name="xxx" accepts="50"/>
    客户端   <xxx:reference interface="com.neu.xxService" connections="50"/>
    限制xxService的消费者连接数

并发和连接数控制算法
    基于Pipeline，AOP拦截器，
    服务端：在切面拦截，从上下文获取当前并发执行数，小于放行，计数++，大于抛出异常，
            服务调用完成后，获取上下文，并发数--
    客户端：从上下文获取，大于则wait()；，小于则计数++,放行，若有服务调用完成计数--

服务降级
    需要服务发布模型中支持降级属性 force:return null    force:throw Exception
       <xxx:service interface="edu.neu.xxService" ref="xxService" 
           mock="force:execute Bean:xxServiceMock"/>//执行本地模拟接口实现类

容错降级
    当服务提供者不可用时，让消费者执行业务放通 这里Mock接口会放在客户端
    fail:throw Exception将异常转义   fail:execute Bean:beanName
  在消费者配置<xxx:reference interface="edu.neu.xxService" id="xxService" 
           mock="fail:execute Bean:xxServiceMock"/>

服务优先级调度
    服务优先级调度策略
        1.基于线程调度器优先级 根据用户的优先级配置策略
        2.基于优先级队列(不允许null元素，无界)
        3.基于加权配置
        4.基于服务迁入迁出

服务迁入迁出
    1.系统资源紧张的时候，通过服务治理Portal管理界面将低优先级服务部分迁出，动态
    去注册

性能KPI指标
    QPS
    调用时延
    调用成功率
    基础资源使用情况

故障隔离
    进程级别
    vm级别
    物理机级别
    机房级别

最后

以上就是个性汉堡为你收集整理的分布式服务框架原理与实践的全部内容，希望文章能够帮你解决分布式服务框架原理与实践所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。