微服务架构中，根据业务的不同，会存在或多或少的服务系统，这些服务系统串联组成逻辑链路对外提供业务服务。
业务流程的完成不在依托于单体应用，而是分散为若干个高内聚的子系统，随着系统数量的增加，服务间的通讯变得至关重要，即所谓的服务治理。
服务治理主要功能就是当服务上下线能够快速的让调用方快速发现，实现动态变更。
服务治理框架实现有两种比较直观的方法
- 注册中心主动访问所有的服务节点
- 服务主动向注册中心发起请求
如果采用主动收集服务信息设计服务治理框架，会在几个问题
- 1、服务治理框架主动广播收集服务信息，会造成网络消耗。
- 2、服务治理除了收集服务信息，还需要处理来自服务注册方的访问，服务压力增大。
对比主动收集，通常来说会采用被动收集的方式，由注册方主动上报的方式实现服务治理框架。
服务治理框架需要提供基本功能有
- 服务注册功能：服务提供方主动注册服务信息
- 服务发现功能：服务消费方主动拉去已有的注册表
- 服务下线功能：服务提供发主动告知服务下线
- 服务心跳检测、续约、剔除：服务治理框架通过和服务提供方配合交互，针对租约到期存活的服务信息进行续约，针对未继续续约等服务从注册表中剔除。
- 服务治理框架高可用：服务间的通讯表由服务治理框架维护，服务治理框架高可用保证单节点服务治理down机的时候，能够正常提供服务发现能力。
围绕上述几点，服务治理框架总的来说需要解决几个大方向问题
- 服务生命周期管理
即：服务从上线到下线等状态管理 - 分布式调用
根据不同的网络分区实现复杂网络环境下的服务治理 - 高可用
提供高可用解决方案，解决单机问题 - 主动健康检查
服务注册表由服务提供发主动上报，而服务治理框架需要主动检查服务提供方服务健康，在业务允许的时间范围内剔除已过期的服务注册信息。
服务治理框架选择需要考虑的几个方面
注册中心的业界方案有很多，如：Eureka、Consul、Nacos、Zookeeper、Etcd 等。
结合上图，通常来说注册中心的选择需要考虑的有几个方面
- 可用性和一致性的抉择
通常来说，对于注册中心选择高可用多于一致性。由于网络抖动等原因，可能存在短时间内的服务续租问题，在高可用场景下，允许数据短时间内的不一致。 - 落地成本
包括学习曲线，团队学习曲线，部署成本等。假若项目已经存在某注册中心，非特殊原因，不进行替换。
以成本为前提，而非因为技术而选择。
若有收获，就点个赞吧
0 人点赞
