一 Nacos 是什么
不再赘述太多的名词解释，详细的解释移步至 Nacos 官网
简而言之，Nacos是一个以服务作为服务对象的中间件，致力于服务的服务管理、动态发现、负载均衡以及服务的配置项的配置管理。
当前可支持服务对象包括：
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
可以说，目前微服务技术架构方案下的流行的服务实现，都能够很好地适配支持。
Nacos 关键特性：
服务发现和服务健康监测
动态配置服务
动态 DNS 服务
服务及其元数据管理
二 业务场景最佳实践
业务背景
源于数字化转型，需要将更多的实际司内业务场景数字化，需要底层的技术架构升级。
某一模块的平台功能架构设计如下图所示：
因为业务场景比较复杂，所以拆分的微服务的管理成了比较大的问题。另外，对于传统的网络环境，由于安全需要，K8S的容器化还没有足够好的适应生产环境，所以暂时是没有采用的。
某一模块的平台技术架构设计如下图所示：
可以说是，非常复杂的业务需要。需要一款中间件，支撑服务动态发现、服务配置管理。
技术选型
需求明确了，然后根据当前市面上流行的中间件，进行选型，从而判断选择或者自研。
了解了像Eureka、Apollo、Nacos、Zookeeper、ETCD、Consul等多款中间件，着重对比了，Eureka、Apollo、Nacos。
Nacos 生态图
服务注册中心 Eureka vs Nacos
- CAP模型
CAP 理论，相信很多人都听过，它是指： 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
衡量分布式系统的健壮，很好地模型就是CAP模型
Nacos 支持AP和CP模型 Eureka支持AP模型
客户端服务发现
Nacos 客户端使用监听模式push/pull拉取更新服务信息
Eureka 客户端定时轮询服务端获取其他服务ip信息并对比，导致Eureka服务端压力较大
Nacos更符合实际生产使用。
伸缩性
对于一致性算法，Nacos 采用Raft作为选举算法，性能、可用性、容错性均比较好，新加入节点无需与所有节点互相广播同步信息
Eureka采用广播同步信息方式，集群规模太大，压力较大
健康检查模式
Nacos 比较灵活，支持服务端/客户端/关闭检查模式，检查方式包括有tcp、http、sql同时支持自定义健康检查器
Eureka 采用客户端向服务端发送http心跳方式
负载均衡
Nacos 采用DNS方式等多方式支持负载均衡
Eureka 通过软负载方式支持负载均衡
服务上下线
Nacos 有操作控制台UI页面，通过控制台页面和API方式实现快速服务上下线
Eureka 只能通过调用API
跨中心同步
Nacos 通过NacosSync，使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在3s,8C16G的单机能够支持6K的同步任务
Eureka 当前不支持
k8s集成
容器编排势必未来要进一步改造，所以考虑Kubernetes支持是必要的。
Nacos生态比较完整，支持云原生时代的技术发展趋势
Eureka不支持
分组
因为服务量过大，同时，平台功能模块过多，需要分组方式管理服务
Nacos 可用根据业务和环境进行分组管理
Eureka 不支持
服务权重
Nacos 默认提供权重设置功能，调整承载流量压力
Eureka 不支持
社区生态
Nacos 当前作为阿里巴巴主开源的项目，社区活跃，生态链完整
Eureka 官方虽然在积极地维护Eureka 1.x，但是社区目前相较来讲，不够活跃。2.x好久了，也没有孵化出来。
服务配置中心 Apollo vs Nacos
Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
性能方面，Nacos读写tps比apollo稍强一些
综合分析，选择Nacos作为服务注册中心、服务配置中心。
实践问题
问题描述
在整个服务集群，采用Nacos之后，线上经常会出现网关服务掉线的情况，排查之后，发现会产生OOM的错误。
使用Arthas 采集监控日志，NacosServiceManger 不断产成新的进程，导致内存溢出。
问题解决
排查代码发现，在写自定义的服务负载时，采用了不断New去操作NacosServiceManager，导致问题出现
经过了解Nacos源码 发现，是有注入到容器内的，因此采用容器注入方式，解决了当前问题。
开源需求
文档完善
目前，开源生态不断地进行完善，但是希望能够建立当前开源反馈问题的分类梳理。
权限管控
目前，对于Nacos的本身功能上，已经满足现有需要。控制台的权限管控力度，感觉可以进行加强。
控制台自定义
对于控制台，虽说是开发者的控制台，但是不够精细化。如果可以链接通知告警平台，同时，添加待办模块，就能够更好地管理运维服务对象
三 MSE-Nacos 产品体验测评
相较开源版Nacos 来讲，MSE-Nacos 对其在功能上，做了进一步的加强、优化。
Nacos引擎每个版本类型根据其开源特性又推出了开源核心版本和MSE优化版本。
- 开源核心版本：Nacos引擎的开源版本，会随着开源版本一起更新。
- MSE优化版本：MSE基于开源核心版本进行优化后，提供的能力更强并且可以实现快速迭代的版本。
产品文档
整体文档库，是阿里的文档统一风格，个人感觉，整体来讲，补充下MSE-Nacos的 优化特性技术点更加好。 更加晓得，开源版在技术上做了哪些升级。
对于，文档目录，希望以使用的角度，去从服务管理、配置管理到之后的编写。更加连贯。
功能升级
微服务引擎 MSE 面向业界主流开源微服务项目， 提供注册配置中心和分布式协调（原生支持 Nacos/ZooKeeper/Eureka ）、云原生网关（原生支持Higress/Nginx/Envoy，遵循Ingress标准）、微服务治理（原生支持 Spring Cloud/Dubbo/Sentinel，遵循 OpenSergo 服务治理规范）能力。
对于Nacos等注册配置中心，可以快速部署、集成，减少了运维的复杂性。
底层优化
Alibaba Dragonwell 是一款免费的, 生产就绪型Open JDK 发行版，提供长期支持，包括性能增强和安全修复。
MSE-Nacos 基于 Alibaba Dragonwell 进行构建，JVM 参数深度调优，TPS 和 QPS 性能具有明显提升。
Alibaba Dragonwell在保证兼容性基础上对java原生序列化进行了优化，通过缓存大幅提高了性能。通过分析发现, 原生序列化瓶颈大多在于大量的class 查找，如在反序列化时需要获取对端类定义的元信息等。引入了一层通过类全限定名和类加载器映射到java类对象的缓存，减少了大量Class.forName的调用。
推空保护
当注册中心变更或遇到突发情况时，可能导致订阅列表异常从而收到空的实例列表，推空保护可以有效保护业务调用，增加业务可靠性。
推送轨迹
查询注册中心服务的推送和配置中心的配置变更发布和推送，清晰观测推送功能的履约情况，从而提高问题的排查效率。
