CAP理论
CAP理论是分布式架构中重要理论
一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
关于P,在整个系统中某个部分,挂掉了,或者宕机了,并不影响整个系统的运作或者说使用,而可用性是,某个系统的某个节点挂了,但是并不影响系统的接受或者发出请求,CAP 不可能都取,只能取其中2个
原因是:
如果C是第一需求的话,那么会影响A的性能,因为要数据同步,不然请求结果会有差异,但是数据同步会消耗时间,期间可用性就会降低。
如果A是第一需求,那么只要有一个服务在,就能正常接受请求,但是对与返回结果变不能保证,原因是,在分布式部署的时候,数据一致的过程不可能想切线路那么快。
再如果,同事满足一致性和可用性,那么分区容错就很难保证了,也就是单点,也是分布式的基本核心,好了,明白这些理论,就可以在相应的场景选取服务注册与发现了
一、Nacos简介
Nacos是以服务为主要服务对象的中间件,Nacos支持所有主流的服务发现、配置和管理。
Nacos主要提供以下四大功能:
-
服务发现与服务健康检查
Nacos使服务更容易注册自己并通过DNS或HTTP接口发现其他服务。Nacos还提供服务的实时健康检查,以防止向不健康的主机或服务实例发送请求。
-
动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序和服务的需要,这使配置更改更加高效和灵活。
-
动态DNS服务
Nacos支持加权路由,使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡,灵活的路由策略,流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现,并防止应用程序耦合到特定于供应商的服务发现API。
4.服务和元数据管理
Nacos提供易于使用的服务仪表板,可帮助您管理服务元数据,配置,kubernetes DNS,服务运行状况和指标统计。
二、注册中心与配置中心横向对比
2.1 Nacos与eureka注册中心对比
对比项目\注册中心 | Spring Cloud Nacos | Spring Cloud Eureka |
---|---|---|
CAP模型 | 支持AP和CP模型 | AP模型 |
客户端更新服务信息 | 使用注册+DNS-f+健康检查模式。 DNS-F客户端使用监听模式push/pull拉取更新信息 | 客户端定时轮询服务端获取其他服务ip信息并对比,相比之下服务端压力较大、延迟较大 |
伸缩性 | 使用Raft选举算法性能、可用性、容错性均比较好,新加入节点无需与所有节点互相广播同步信息 | 由于使用广播同步信息,集群超过1000台机器后对eureka集群压力很大 |
健康检查模式/方式 | 支持服务端/客户端/关闭检查模式,检查方式有tcp、http、sql。支持自己构建健康检查器 | 客户端向服务端发送http心跳 |
负载均衡 | 支持 | 支持 |
手动上下线服务方式 | 通过控制台页面和API | 通过调用API |
跨中心同步 | 支持 | 不支持 |
k8s集成 | 支持 | 不支持 |
分组 | Nacos可用根据业务和环境进行分组管理 | 不支持 |
权重 | Nacos默认提供权重设置功能,调整承载流量压力 | 不支持 |
厂商 | 阿里巴巴 | Netflix |
2.2服务配置中心对比
对比项目/配置中心 | apollo | nacos |
---|---|---|
开源时间 | 2016.5 | 2018.6 |
配置实时推送 | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
版本管理 | 自动管理 | 自动管理 |
配置回滚 | 支持 | 支持 |
权限管理 | 支持 | 待支持 |
多集群多环境 | 支持 | 支持 |
监听查询 | 支持 | 支持 |
多语言 | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI |
分布式高可用最小集群数量 | Config2+Admin3+Portal*2+Mysql=8 | Nacos*3+MySql=4 |
配置格式校验 | 支持 | 支持 |
通信协议 | HTTP | HTTP |
数据一致性 | 数据库模拟消息队列,Apollo定时读消息 | HTTP异步通知 |
单机读(tps) | 9000 | 15000 |
单机写(tps) | 1100 | 1800 |
nacos具有Apollo大部分功能,最重要的是配置中心与注册中心打通,可以省去我们在微服务治理方面 的一些投入(比如通过动态配置来启停线程池等操作)。
2.3 初步选型结论
初步结论为:使用Nacos代替Eureka和apollo,主要理由为:
相比与Eureka:
(1)Nacos具备服务优雅上下线和流量管理(API+后台管理页面),而Eureka的后台页面仅供展示,需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看,Nacos整合了注册中心、配置中心功能,把原来两套集群整合成一套,简化了部署维护
(3)从长远来看,Eureka开源工作已停止,后续不再有更新和维护,而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合,填补 2 者的鸿沟,在两套体系下可以采用同一套服务发现和配置管理的解决方案,这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh,是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步,而Eureka不支持,且在伸缩扩容方面,Nacos比Eureka更优(nacos支持大数量级的集群)。
(5)Nacos具有分组隔离功能,一套Nacos集群可以支撑多项目、多环境。
相比于apollo
(1) Nacos部署简化,Nacos整合了注册中心、配置中心功能,且部署相比apollo简单,方便管理和监控。
(2) apollo容器化较困难,Nacos有官网的镜像可以直接部署,总体来说,Nacos比apollo更符合KISS原则
(3)性能方面,Nacos读写tps比apollo稍强一些
结论:使用Nacos代替Eureka和apollo
三、Nacos其他特性
3.1 Nacos Sync的价值
- NacosSync是一个支持多种注册中心的同步组件,基于Spring boot开发框架,数据层采用Spring Data JPA,遵循了标准的JPA访问规范,支持多种数据源存储,默认使用Hibernate实现,更加方便的支持表的自动创建更新
- 使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在3s,8C16G的单机能够支持6K的同步任务
- NacosSync除了单机部署,也提供了高可用的集群部署模式,NacosSync是无状态设计,将任务等状态数据迁移到了数据库,使得集群扩展非常方便
- 抽象出了Sync组件核心接口,通过注解对同步类型进行区分,使得开发者可以很容易的根据自己需求,去扩展不同注册中心,目前已支持的同步类型:
- Nacos数据同步到Nacos
- Zookeeper数据同步到Nacos
- Nacos数据同步到Zookeeper
- Eureka数据同步到Nacos
- Consul数据同步到Nacos
3.2 DNS - F 的技术价值
Nacos提供DNS-F功能
DNS-F落地的技术价值
- 填补了内部微服务业务没有全局动态调度能力的空白
- 解决了服务端棉铃挑战:时延大、解析不准、故障牵引慢
- 支持服务端多种调度需要
- 加速外部域名解析
- 服务故障牵引秒级生效
-
提供专线流量牵引能力