阿里开源出来的，在微服务世界，nacos可提供配置管理、服务注册、服务发现，服务是nacos世界的一等公民。
和携程开源的apollo比较类似，但成熟度没有apollo好，但阿里开源的中间件稳定性还是可圈可点的。
可以解决我们常遇到的问题如：
- 有效的密码管理，开发不碰触密码配置，运维人员和架构团队统一管理避免泄露；
- 多项目下的配置绝对统一性，不会出现配置写错导致的BUG
- 对于配置的编辑、存储、分发、变更管理、历史版本管理、变更审计有完善的能力
- 配置分组和灰度发布
- 有好处当然也有坏处，相对于使用配置文件我们还需要解决如下问题：
- 配置中心异常情况下服务怎么保障可用（SDK提供Cache功能当中心服务不可用会使用上一次加载的缓存配置）
- 配置变更后的程序生效逻辑（SDK提供配置变动订阅逻辑可以订阅配置变动编写处理逻辑）
- 开发过程中的配置文件调试（需要框架进行设计）
- 对于部分语言来说（PHP）配置中心性能的问题（Nacos的吞吐量8C16G 15K并发）
-
Nacos地图
特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求
- 架构大图：通过清晰架构，让您快速进入 Nacos 世界
- 业务大图：利用当前特性可以支持的业务场景，及其最佳实践
- 生态大图：系统梳理 Nacos 和主流技术生态的关系
- 优势大图：展示 Nacos 核心竞争力
-
Nacos 生态图
逻辑架构及其组件介绍
服务管理：实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能
- 配置管理：实现配置管CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能
- 元数据管理：提供元数据CURD 和打标能力
- 插件机制：实现三个模块可分可合能力，实现扩展点SPI机制
- 事件机制：实现异步化事件通知，sdk数据变化异步通知等逻辑
- 日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档
- 回调机制：sdk通知数据，通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性
- 寻址模式：解决ip，域名，nameserver、广播等多种寻址模式，需要可扩展
- 推送通道：解决server与存储、server间、server与sdk间推送性能问题
- 容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性
- 流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制
- 缓存机制：容灾目录，本地缓存，server缓存机制。容灾目录使用需要工具
- 启动模式：按照单机模式，配置模式，服务模式，dns模式，或者all模式，启动不同的程序+UI
- 一致性协议：解决不同数据，不同一致性要求情况下，不同一致性机制
- 存储模块：解决数据持久化、非持久化存储，解决数据分片问题
- Nameserver：解决namespace到clusterid的路由问题，解决用户环境与nacos物理环境映射问题
- CMDB：解决元数据存储，与三方cmdb系统对接问题，解决应用，人，资源关系
- Metrics：暴露标准metrics数据，方便与三方监控系统打通
- Trace：暴露标准trace，方便与SLA系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通
- 接入管理：相当于阿里云开通服务，分配身份、容量、权限过程
- 用户管理：解决用户管理，登录，sso等问题
- 权限管理：解决身份识别，访问控制，角色管理等问题
- 审计系统：扩展接口方便与不同公司审计系统打通
- 通知系统：核心数据变更，或者操作，方便通过SMS系统打通，通知到对应人数据变更
- OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成
- Console：易用控制台，做服务管理、配置管理等操作
- SDK：多语言sdk
- Agent：dns-f类似模式，或者与mesh等方案集成
- CLI：命令行对产品进行轻量化管理，像git一样好用
若有收获，就点个赞吧
0 人点赞
