讯享网

 <p id="1Q54T1SD">Nacos 生态</p><p id="1Q54T1SE">Nacos 几乎支持所有主流语言， 其中 Java/Golang/Python 已经支持 Nacos 2.0 长链接协议， 能最大限度发挥 Nacos 性能。 阿里微服务 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel） **实践， 是 Java 微服务生态**解决方案； 除此之外， Nacos 也对微服务生态活跃的技术做了无缝的支持， 如目前比较流行的 Envoy、 Dapr 等， 能让用户更加标准获取微服务能力。生态仓库： https://github.com/nacos-group</p><p id="1Q54T1SF">Nacos 优势</p><p id="1Q54T1SG">易?： 简单的数据模型， 标准的 restfulAPI， 易用的控制台， 丰富的使用文档。稳定： 99.9% 高可用， 脱胎于历经阿里巴巴 10 年生产验证的内部产品， 支持具有数百万服务的大规模场景， 具备企业级 SLA 的开源产品。实时： 数据变更毫秒级推送生效； 1w 级， SLA 承诺 1w 实例上下线 1s， 99.9% 推送完成； 10w级， SLA 承诺 1w 实例上下线 3s， 99.9% 推送完成； 100w 级别， SLA 承诺 1w 实例上下线 9s99.9% 推送完成。规模： 十万级服务/配置， 百万级连接， 具备强大扩展性。</p><p id="1Q54T1SH">设计原则</p><p id="1Q54T1SI">极简原则， 简单才好用， 简单才稳定， 简单才易协作。</p><p id="1Q54T1SJ">架构?致性， ?套架构要能适应开源、 内部、 商业化（公有云及专有云） 3 个场景。</p><p id="1Q54T1SK">扩展性， 以开源为内核， 商业化做基础， 充分扩展， 方便用户扩展。</p><p id="1Q54T1SL">模块化， 将通用部分抽象下沉， 提升代码复用和健壮性。</p><p id="1Q54T1SM">长期主义， 不是要?个能支撑未来 3 年的架构， 而是要能够支撑 10 年的架构。</p><p id="1Q54T1SN">开放性， 设计和讨论保持社区互动和透明， 方便大家协作。</p><p id="1Q54T1SO">架构图整体架构分为用户层、 业务层、 内核层和插件， 用户层主要解决用户使用的易用性问题， 业务层主要解决服务发现和配置管理的功能问题， 内核层解决分布式系统?致性、 存储、 高可用等核心问题，插件解决扩展性问题。</p><p id="1Q54T1SP">用户层</p><p id="1Q54T1SQ">OpenAPI： 暴露标准 Rest 风格 HTTP 接口， 简单易用， 方便多语言集成。</p><p id="1Q54T1SR">Console： 易用控制台， 做服务管理、 配置管理等操作。</p><p id="1Q54T1SS">SDK： 多语言 SDK， 目前几乎支持所有主流编程语言。</p><p id="1Q54T1ST">Agent： Sidecar 模式运行， 通过标准 DNS 协议与业务解耦。</p><p id="1Q54T1SU">CLI： 命令行对产品进行轻量化管理， 像 git ?样好用。</p><p id="1Q54T1SV">业务层</p><p id="1Q54T1T0">服务管理： 实现服务 CRUD， 域名 CRUD， 服务健康状态检查， 服务权重管理等功能。</p><p id="1Q54T1T1">配置管理： 实现配置管 CRUD， 版本管理， 灰度管理， 监听管理， 推送轨迹， 聚合数据等功能。</p><p id="1Q54T1T2">元数据管理： 提供元数据 CURD 和打标能力， 为实现上层流量和服务灰度非常关键</p><p id="1Q54T1T3">内核层</p><p id="1Q54T1T4">插件机制： 实现三个模块可分可合能力， 实现扩展点 SPI 机制， 用于扩展自己公司定制。</p><p id="1Q54T1T5">事件机制： 实现异步化事件通知， SDK 数据变化异步通知等逻辑， 是 Nacos 高性能的关键部分。</p><p id="1Q54T1T6">日志模块： 管理日志分类， 日志级别， 日志可移植性（尤其避免冲突） ， 日志格式， 异常码+帮助文档。</p><p id="1Q54T1T7">回调机制： SDK 通知数据， 通过统?的模式回调用户处理。 接口和数据结构需要具备可扩展性。</p><p id="1Q54T1T8">寻址模式： 解决 Server IP 直连， 域名访问， Nameserver 寻址、 广播等多种寻址模式， 需要可扩展。</p><p id="1Q54T1T9">推送通道： 解决 Server 与存储、 Server 间、 Server 与 SDK 间高效通信问题。</p><p id="1Q54T1TA">容量管理： 管理每个租户， 分组下的容量， 防止存储被写爆， 影响服务可用性。</p><p id="1Q54T1TB">流量管理： 按照租户， 分组等多个维度对请求频率， 长链接个数， 报文大小， 请求流控进行控制。</p><p id="1Q54T1TC">缓存机制： 容灾目录， 本地缓存， Server 缓存机制， 是 Nacos 高可用的关键。</p><p id="1Q54T1TD">启动模式： 按照单机模式， 配置模式， 服务模式， DNS 模式模式， 启动不同的模块。</p><p id="1Q54T1TE">?致性协议： 解决不同数据， 不同?致性要求情况下， 不同?致性要求， 是 Nacos 做到 AP 协议的关键。</p><p id="1Q54T1TF">存储模块： 解决数据持久化、 非持久化存储， 解决数据分片问题。</p><p id="1Q54T1TG">插件</p><p id="1Q54T1TH">Nameserver： 解决 Namespace 到 ClusterID 的路由问题， 解决用户环境与 Nacos 物理环境映射问题。</p><p id="1Q54T1TI">CMDB： 解决元数据存储， 与三方 CMDB 系统对接问题， 解决应用， 人， 资源关系。</p><p id="1Q54T1TJ">Metrics： 暴露标准 Metrics 数据， 方便与三方监控系统打通。</p><p id="1Q54T1TK">Trace： 暴露标准 Trace， 方便与 SLA 系统打通， 日志白平化， 推送轨迹等能力， 并且可以和计量计费系统打通。</p><p id="1Q54T1TL">接入管理： 相当于阿里云开通服务， 分配身份、 容量、 权限过程。</p><p id="1Q54T1TM">用户管理： 解决用户管理， 登录， SSO 等问题。</p><p id="1Q54T1TN">权限管理： 解决身份识别， 访问控制， 角色管理等问题</p><p id="1Q54T1TO">配置(Configuration)</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2023%2F0520%2F2922f334j00ruxkke000cd000hs00c3p.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="1Q54T1TQ">配置资源模型</p><p id="1Q54T1TR">Namespace 的设计就是用来进行资源隔离的， 我们在进行配置资源的时候可以从以下两个角度来看： 从单个租户的角度来看， 我们要配置多套环境的配置， 可以根据不同的环境来创建 Namespace 。比如开发环境、 测试环境、 线上环境， 我们就创建对应的 Namespace（dev、 test、 prod） ，Nacos 会自动生成对应的 Namespace Id 。 如果同?个环境内想配置相同的配置， 可以通过Group 来区分。 如下图所示：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2023%2F0520%2F90d937c2j00ruxkkg000nd000hs00a9p.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="1Q54T1TT">从多个租户的角度来看， 每个租户都可以有自己的命名空间。 我们可以为每个用户创建?个命名空间， 并给用户分配对应的权限， 比如多个租户（zhangsan、 lisi、 wangwu） ， 每个租户都想有?套自己的多环境配置， 也就是每个租户都想配置多套环境。 那么可以给每个租户创建?个 Namespace （zhangsan、 lisi、 wangwu） 。 同样会生成对应的 Namespace Id。 然后使用 Group 来区分不同环境的配置。 如下图所示：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2023%2F0520%2Ff9680d61j00ruxkkh000nd000hs009op.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="1Q54T1TV">Nacos 存储配置有几个比较重要的表分别是:</p><p id="1Q54T1U0">config_info 存储配置信息的主表， 里面包含 dataId、 groupId、 content、 tenantId、 encryptedDataKey 等数据。config_info_beta 灰度测试的配置信息表， 存储的内容和 config_info 基本相似。 有?个 beta_ips 字段用于客户端请求配置时判断是否是灰度的 ip。config_tags_relation 配置的标签表， 在发布配置的时候如果指定了标签， 那么会把标签和配置的关联信息存储在该表中。his_config_info 配置的历史信息表， 在配置的发布、 更新、 删除等操作都会记录?条数据， 可以做多版本管理和快速回滚。</p><p id="1Q54T1U1">Nacos服务发现模块设计</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2023%2F0520%2Fe2e8a448j00ruxkkj000md000hs00hep.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="1Q54T1U3">Nacos 提供了四层的数据逻辑隔离模型， 用户账号对应的可能是?个企业或者独立的个体， 这个数据?般情况下不会透传到服务注册中心。 ?个用户账号可以新建多个命名空间， 每个命名空间对应?个客户端实例， 这个命名空间对应的注册中心物理集群是可以根据规则进行路由的， 这样可以让注册中心内部的升级和迁移对用户是无感知的， 同时可以根据用户的级别， 为用户提供不同服务级别的物理集群。 再往下是服务分组和服务名组成的二维服务标识， 可以满足接口级别的服务隔离</p><p id="1Q54T1U4">数据?致性</p><p id="1Q54T1U5">Nacos 因为要支持多种服务类型的注册， 并能够具有机房容灾、 集群扩展等必不可少的能力， 在1.0.0 正式支持 AP 和 CP 两种?致性协议并存。 1.0.0 重构了数据的读写和同步逻辑， 将与业务相关的 CRUD 与底层的?致性同步逻辑进行了分层隔离。 然后将业务的读写（主要是写， 因为读会直接使用业务层的缓存） 抽象为 Nacos 定义的数据类型， 调用?致***进行数据同步。 在决定使用 CP 还是 AP ?致性时， 使用?个代理， 通过可控制的规则进行转发。</p><p id="1Q54T1U6">负载均衡在 Nacos 0.7.0 版本中， 我们除了提供基于健康检查和权重的负载均衡方式外， 还新提供了基于第三方 CMDB 的标签负载均衡器， 具体可以参考 CMDB 功能介绍文章。 使用基于标签的负载均衡器，目前可以实现同标签优先访问的流量调度策略， 实际的应用场景中， 可以用来实现服务的就近访问，当您的服务部署在多个地域时， 这非常有用。 使用这个标签负载均衡器， 可以支持非常多的场景，这不是本文要详细介绍的。 虽然目前 Nacos 里支持的标签表达式并不丰富， 不过我们会逐步扩展它支持的语法。 除此以外， Nacos 定义了 Selector， 作为负载均衡的统?抽象。</p><p id="1Q54T1U7">健康检查Nacos 目前支持临时实例使用心跳上报方式维持活性， 发送心跳的周期默认是 5 秒， Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康， 在 30 秒没收到心跳时将这个临时实例摘除。Nacos 既支持客户端的健康检查， 也支持服务端的健康检查， 同?个服务可以切换健康检查模式。我们认为这种健康检查方式的多样性非常重要， 这样可以支持各种类型的服务， 让这些服务都可以使用到 Nacos 的负载均衡能力。 Nacos 下?步要做的是实现健康检查方式的用户扩展机制， 不管Nacos 架构 &lt; 74是服务端探测还是客户端探测。 这样可以支持用户传入?条业务语义的请求， 然后由 Nacos 去执行， 做到健康检查的定制</p><p id="1Q54T1U8">高可用设计</p><p id="1Q54T1U9">数据多级容灾：Nacos 持久化存储做了主备容灾， 而且底层存储数据多副本高可用保障。Nacos Server 有全量缓存数据， 即使存储挂或者不可用， 只影响写， 核心的读服务不受影响。Nacos SDK 有所需服务和配置缓存， Server 即使全挂， 走本地缓存， 保证核心业务调用不受影响。</p><p id="1Q54T1UA">同城容灾Nacos 本身是采用 AP 的?致性模式， 同 Region 多个可用区部署， 任何?个可用区出问题， 剩下部分继续工作。很多人问为什么不是三个可用区呢？ 因为业务都部署三个可用区从理论上是可用性最好的， 但是成本会大幅增加， 因此?般公司只选择两个可用区。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2023%2F0520%2F3d2303d0j00ruxkkk000ld000hs009yp.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="1Q54T1UC">大家好，我是Doker品牌的Sinbad,欢迎点赞和评论,您的鼓励是我们持续更新的动力！更多资料请前往</p><p id="1Q54T1UD">Doker 多克</p>