六、流量控制
对于服务提供方而言，集群的规模是确定的，提供的服务的容量也是有限的，如果不对消费者的调用做限流处理，当消费者的调用频次超过服务集群的承载能力时，集群就会出现不稳定甚至雪崩效应导致整个集群所有服务器崩溃，从而使整个服务挂掉。为了整个服务的高可用性，需要根据集群负载情况对服务消费者做限流，启动流量控制机制，以保护服务提供者。
比较传统的做法是根据集群节点数和每个节点能够承受的qps数计算集群承载能力，服务时，各个节点按照分配的阈值进行流量控制，对超出的阈值的请求直接拒绝服务。相比于分布式服务的动态上下线，尤其是新上线的服务，传统做法无法适应节点数变化导致的集群承载能力变化的情况。
在分布式场景中，通过注册中心动态发布服务是非常常见的事情，分布式服务框架应该处理动态增加服务引起的集群负载能力变化。比较理想的情况是每个节点定时汇报自己的负载情况和剩余处理能力，在总控节点根据各个节点统一控制。当然，实现起来难度比较大，目前更普遍的做法是目前dubbo的那种，通过控制最大并行执行请求数达到流量控制的目的，虽然这种方式粗糙了一点儿。
七、服务降级
当业务系统的运营推广或者业务高峰期时，系统压力往往是平时的几倍甚至几十倍，这种情况往往并不非常常见，把系统部署服务器数量增大的方式不经济，往往会停掉一些次要服务。另外某些服务不可用时，希望不影响整个交易流程。针对这两种常见的场景，分布式服务框架需要具备一项重要的能力：服务降级。服务降级包括容错降级和屏蔽降级两种。
屏蔽降级：针对次要的非核心服务，在第一种场景时，不真正发起远程调用，而是在调用端就返回空、抛异常或者执行特定的本地逻辑。屏蔽降级一般按照计划由运维或开发人员手工触发。当然了，当不再需要屏蔽降级时，关闭降级即可使服务恢复正常工作状态。
容错降级：在分布式服务中，业务系统依赖的服务有可能不可用，当依赖的非核心的服务不可用时，可以对故障服务做逻辑容错，放通处理。通过容错降级，保证核心服务可用，避免因为次要应用不可用影响主要服务的可用性。容错降级是服务不可用时，根据提前配置的策略触发，当服务提供方服务恢复后，容错策略失效，恢复正常的服务调用方式。

八、服务治理
随着时间的推移，业务的发展，线上的服务越来越多。公司在不断拓展新业务的同事，一些老的业务会逐渐下线，但它对应的服务未必能下线，其他服务可能调用了这个服务呢！为了安全，于是服务只上不下。随着线上各个业务相互打通，调用关系越来越复杂，导致的结果就是某个业务的调用链条变得越来越长，一旦服务响应缓慢，进行性能调优就变得非常困难，因为难以定位到底是链条中的哪一环性能差。一旦线上发生故障，首先需要在调用链条中定位是哪个环节的服务出了问题，其次，这个服务可能部署在多台机器上，查询日志，定位问题在每台机器上进行一遍，想想都让人抓狂。前面提到的流量控制和流量降级也是在服务运行期间进行操作的。服务治理是对线上服务的生命周期管理、监控、运行态管控，服务发生问题时的快速定位和解决。
服务生命周期管理：分布式服务框架如果缺乏生命周期管理的相关功能，服务上线后，当进行功能调整时出现不知道有哪些服务调用了这个服务，不敢调整的情况，下线当然就更不可能了。分布式服务框架目前提供的功能是服务调用关系图，通过调用关系图，可以知道服务间的依赖关系，进而在某个服务没有调用方时大胆下线。服务上线前也可以在调用关系图中检查是否有类似的功能，避免出现两个名称不同，功能却差不多的服务。分布式系统需要多个服务相互配合才能完成完整的功能，为服务提供生命周期管理是一项非常基础的功能。
服务监控：系统监控说多重要都不为过，分布式服务框架为正常运行的分布式系统提供调用次数，调用时延，调用成功率等指标数据，为性能优化、运营、运维提供参考依据；当指标异常或者服务出现问题时，能及时根据告警策略发送报警邮件或短信等方式，通知开发或运维相关人员及时跟进问题，迅速分析问题的原因，定位问题，解决问题。
运行态管控：前面提到的流量控制和服务降级都属于运行态管控的范围，还包括资源的动态分配，服务路由等。运行态管控基本都是针对服务正常的场景，针对业务高峰期导流，或者资源充分利用的需求，或者保障故障或业务高峰期时系统正常运行。对一个规模较大的分布式系统来说，运行态管控，为开发或者运维管理线上服务，充分利用资源提供有力的工具。
故障快速定位：当线上服务发生故障时，需要迅速定位并解决。当若干服务相互配合才能完成的一项业务，而且这些服务部署在几百台服务器上时，通过手工在这几百台服务器上定位问题是不可想象的。首先，线上的监控系统会对每个服务的运行状态进行监控，其次通过调用链分析，确定导致故障的服务。另外，服务的日志可能分布在几百台服务器上，所以需要一个统一的日志收集和检索系统。