Nacos之服务治理

服务治理

上面的例子中,是有风险的,有以下几个问题

问题1：一旦服务提供者的信息变化了,就不得不去修改服务调用者的代码
问题2：一旦服务提供者做了集群,服务调用者一方无法实现负载均衡去调用
问题3：一旦微服务变得越来越多,如何来管理服务清单就成了问题

这就需要通过注册中心动态的实现服务治理

什么是服务治理?

服务治理是微服务架构中最核心最基本的模块,用于实现各个微服务的自动化注册和发现

服务注册

  在服务治理框架中,都会构建一个注册中心,每个服务单元向注册中心登记自己提供服务的详细信息,并在注册中心形成一张服务的清单，服务注册中心需要以心跳的方式去监测清单中的服务是否可用,如果不可用,需要在服务清单中剔除不可用的服务

nacos之心跳机制
nacos的心跳机制，现有A、B两个服务调用关系 B->A，心跳步骤如下：

启动nacos服务

启动A、B服务，并向nacos发送http请求连接
连接成功后发送心跳连接，nacos记录心跳最新时间
nacos会起定时任务向AB服务发送心跳包，来验证服务是否健康
如果B调用A时，A服务挂掉，nacos这边A的最后心跳时间已经过去15s就标记A服务不健康
如果超过30s还是不健康那就直接干掉A服务

nacos与eureka的区别

1 Nacos的阈值是针对某个具体Service的，而不是针对所有服务的，但Eureka的自我保护阈值是针对所有服务的
2.Nacos支持服务列表变更的消息推送模式，服务列表更新更及时，Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。Nacos支持服务端主动检测提供者状态，临时实例采用心跳模式，非临时实例采用主动检测模式，临时实例心跳不正常会被剔除，非临时实例则不会被剔除。
3.nacos在自动或手动下线服务，使用消息机制通知客户端，服务实例的修改很快响应；Eureka只能通过任务定时剔除无效的服务。nacos可以根据namespace命名空间，DataId,Group分组，来区分不同环境（dev，test，prod），不同项目的配置

nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式（一般情况下都使用临时实例，主动检测消费的服务器资源较大，服务器压力大）
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
nacos支持服务列表变更的消息推送模式，服务列表更新及时
nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；eureka采用AP方式

服务发现

服务调用方向服务注册中心咨询服务,并获取所有服务的实例清单,实现对具体服务实例的访问

注册中心一般包含以下几个功能

1 服务发现
服务注册:保存服务提供者和调用者的信息
服务订阅:服务调用者订阅服务提供者的信息,注册中心向订阅者推送提供者的信息
2 服务配置
配置订阅:服务提供者和服务调用者订阅微服务相关的配置
配置下发:主动将配置推送给服务提供者和服务调用者
3 服务健康监测(心跳机制)
检测服务提供者的健康情况,如果发现异常执行服务剔除

常见的注册中心