Nacos - 服务发现

笔记翻译出处：黑马Nacos

---

一、单体架构和微服务

1、单体架构

将所有功能模块使用同一个数据库，同时，它还提供API或者UI访问的Web模块等，最终会打包并部署为单体式应用，这种将所有功能都部署在一个Web容器中运行的系统叫做单体架构

优点
1	开发效率高
2	容易测试
3	容易部署
缺点
1	复杂性逐渐变高，可维护性巨剑变差
2	版本跌倒速度逐渐变慢
3	阻碍技术创新
4	无法按需伸缩

2、微服务

        每一个业务模块都使用独立的服务完成，这种微服务架构模式也影响了应用和数据库之间的关系，不像传统多个业务模块共享一个数据库，微服务架构每个服务都有自己的数据库。

好处
1	分而治之，职责单一；易于开发、理解和维护、方便团队的拆分和管理；
2	可伸缩；能够单独的对指定的服务进行伸缩；
3	局部所以修改，容易替换，容易部署，有利于持续集成和快速迭代
4	不会受限于任何技术栈

二、服务发现

        在微服务中，各服务之间协作来实现业务目标。微服务中也需要进行服务间的远程调用，那么就需要知道服务的网络位置【IP和端口号】，那么就要实现以下内容。

        ①、在每个服务启动时需要向服务发现中心上报自己的网络位置。

        ②、服务发现客户端会定期从服务发现中心同步服务注册表，并缓存在客户端

        ③、当需要对某服务进行请求时，服务实例通过该注册表，定位目标服务网络地址。若目标服务存在多个网络地址，则使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。

        总结：微服务中，由于服务运行实例的网络地址是不断变化的，服务实例数量的动态变化，因此无法使用固定的配置文件来记录提供方的网络地址，必须使用动态的服务发现机制用于实现微服务之间的相互感知。各服务实例会上报自己的网络地址，这样服务中心就形成了一个完整的服务注册表，各服务实例会通过服务发现中心来获取访问目标服务的网络地址，从而实现服务发现的机制。 

三、主流服务发现与配置中心对比

对比项目	Nacos	Eureka	Consul	Zookeeper
一致性协议	支持AP和CP模型	AP模型	CP模型	CP模型
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Keep Alive
负载均衡策略	权重/metadata/Selector	Ribbon	Fabil	-
雪崩保护	有	有	无	无
自动注销实例	支持	支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
监听支持	支持	支持	支持	支持
多数据中心	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	不支持
SpringCloud集成	支持	支持	支持	不支持
Dubbo集成	支持	不支持	不支持	支持
k8s集成	支持	不支持	支持	不支持

四、Spring Cloud服务协作流程