分布式系统怎么做服务治理
服务治理框架。 SOA（面向服务的框架）
| 名称 | 所属公司 | 是否开源 | 资料文档 | 备注 |
| Dubbo | 阿里巴巴 | 是 | 多 | |
| HSF | 阿里巴巴 | 否 | 中 | 目前已作为阿里云产品EDAS其中的套件开放使用 |
| Tars | 腾讯 | 是 | 中 | 已作为腾讯云应用框架对外提供使用 |
| JSF | 京东 | 否 | 少 | |
| Linkerd | CNCF | 是 | 少 | 原型是Twitter所构建的一个基于scala的可扩展RPC系统Finagle |
| Motan | 新浪微博 | 是 | 中 | |
| istio | 谷歌、IBM、Lyft | 是 | 少 |
相关资料文档较为丰富的只有一个Dubbo。下面先罗列一下这些解决方案的架构设计（点击图片可跳转到图片出处）。
大部分方案的设计风格非常相似，都是通过库的方式在调用客户端做的服务发现。那么除了实际的RPC调用之外，主要多了这3个动作：注册、订阅、变更下发。除了这3个核心动作之外，其它的辅助操作还有统计上报、鉴权等等，这也是我们搭建一个服务治理框架需要实现的功能。从MVP的角度来说，注册、订阅、变更下发是最基础的核心功能。
JSF
引入服务治理是为了对整体的RPC调用进行集中化管理。对我们来说其核心价值在于，减少重复劳动、避免手动配置物理文件产生的问题、降低开发人员的技术运用成本。下面针对其中的功能点进行分别讲解。
服务的自动注册：
这是一个服务治理框架的基础功能。大家运用WCF的时候应该感受更加明显，我们要配置一个WCF服务端的时候需要在config文件中做很多配置，甚至大部分公司其实配置都是一模一样的到处复制黏贴，整个这个过程其实是价值较低的重复性劳动。
解决这个问题需要通过动态的感知到服务端的地址信息，然后针对该地址信息进行自动化配置或者模板化配置，让其快速可用。那么这些额外的信息保存在哪，就需要引入一个注册中心的概念来进行集中化管理。
客户端的自动发现：
当我们在config文件中指定具体的IP和端口来定义远程服务的地址，或者直接在程序里硬编码远程服务地址时，本身就是一个端到端的访问方式。无法灵活的在程序运行过程中去增加或减少后端的服务节点。
解决这个问题需要和服务注册的实现方式配套。还可以针对于不同类型的应用制定一些负载均衡的策略进行切换。
变更下发：
客户端的自动发现就依赖于此下发的数据，需要及时把提供服务的节点信息变化下发到各个客户端。它面向的场景如：当我们进行一个发布的时候，先将需要发布的节点从负载均衡列表中移除，然后再进行更新，最后再添加到负载均衡列表中。这个时候避免了访问到正在发布中的程序。
当然这点也可以基于状态检测模块去做，这样可以对服务节点的健康状态感知能力得到更好的加强。