服务治理主要针对于当前分布式架构下多服务、微服务等。
服务是分布式系统下的一个不大不小的部分，有了服务的组成，整个系统才能活起来。
随着业务的增长，服务不能一味地随之增长，需要管理、治理。没有服务治理的分布式系统不一定会失败，但是随着业务的增长，这个系统一定会很痛苦。
服务治理的目标
服务治理严格意义上应该划分为三个阶段，包含了服务的整个生命周期。
其中服务设计期主要针对于服务的设计期、开发期，而服务运行期主要针对于服务上线后等运行情况，最后服务持续治理则是坚持了“分久必合”的理念，将淘汰制进行到底。
下面讲讲三个时期需要完整的工作：
服务设计期：
- 方案评审、开发测试审查、签发认证、服务可发现
- 策略管理
- 合约定义、商谈
- 标准化服务质量协议
服务运行期：
- 系统记录：记录交换的信息
- 服务管理系统：控管、配置服务以及运行阶段的组件，根据异常状况重新配置环境
- 服务监控系统：采集数据，可视化，提供变配证据
- 服务质量保证系统：增强通讯中的消息和运行阶段策略、安全性、可靠性、事务性、稽核等
服务持续治理：
- 服务资产管理：评估、分析服务仓库，识别服务可重用的机率、协助进行资产整合、减少冗余的服务功能
根据上述目标，我们可以确定：
- 服务治理贯穿了服务的整个生命周期，包括开发前的设计、开发以及测试、运行、以及后续管理。
- 服务设计期主要针对于服务的设计评审以及标准的制定。
- 服务治理运行期的重点放在管理和监控，为了运行良好的目标，通过数据分析运行状况，通过自动化消除异常、变配等。
- 服务治理后期的重点放在消除冗余。
服务治理平台设计
结合现在大多架构的注册中心、监控中心，可构设出大概的架构图：
结合Dubbo分析
在服务治理平台的开发过程中，开发难点和设计服务复杂度应该放在了服务注册、服务监控上。
Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。
问题分析
随着业务不断增长，为了追求更高的性能支撑业务，集群的引入使得服务架构的复杂度大大提升。庞大的集群容易出现各种各样的问题：
- 过多的服务URL配置困难
- 负载均衡分配节点压力过大的情况下也需要部署集群
- 服务依赖混乱，启动顺序不清晰
- 过多服务导致性能指标分析难度较大，需要监控
架构分析
Dubbo注册中心和监控中心的引入是服务治理的关键。
注册中心的关键点：
- 服务提供者向注册中心注册其提供的服务
- 服务消费者向注册中心获取服务提供者地址列表，同时加上负载均衡的算法选择服务提供者
监控中心的关键点：
- 服务消费者和提供者累计调用次数和调用时间，定时发送统计数据到监控中心
业务引入架构后，必须要保证的是，对当前业务的稳定性的影响只能是正面影响或者无影响，不能是负面影响。
考虑该架构对稳定性的影响：
- 注册中心宕机情况下，消费者在本地缓存了提供者列表，业务暂时不受影响，但是不能再注册新的服务
- 监控中心宕机情况下，不影响服务，只影响部分采样数据
- 服务提供方宕机后，通过负载均衡算法可将请求往别的同服务的提供方发送，对健壮性起正面作用
注册中心和监控中心的引入在很大程度上提高了运行期的稳定性，对应了服务治理的工作。
考虑架构对其他方面的影响：
- 可动态增加服务，由注册中心统一动态分配
- 可动态增加消费方，由注册中心统一动态分配
由此可见注册中心的引入提高了伸缩性，对应了服务治理运行期所需工作。
而监控中心的引入，数据的采集和分析得到的收益也是明显的，对应的是服务治理运行期的服务监控以及服务治理持续治理下的服务资产管理。
先这样吧
若有错误之处请指出，更多地关注煎鱼。
