1. 服务
服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC | Dubbo RPC Service 或者 Spring Cloud RESTful Service。
名字服务
服务映射，例如 ServiceName -> Endpoints Info，Distributed Lock Name -> Lock Owner/Status Info， DNS Domain Name -> IP List，服务发现和 DNS 就是名字服务的2大场景。
2. 注册中心
服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
3. 元数据
Service Metadata
服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
4. Provider / Consumer
提供可复用和可调用服务的应用方 / 会发起对某个服务调用的应用方。
5. 配置中心
配置及管理 在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。配置变更是调整系统运行时的行为的有效手段之一。系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。
6. 逻辑架构
Console易用控制台，做服务管理、配置管理等操作。SDK多语言sdk。Agentdns-f类似模式，或者与mesh等方案集成。CLI命令行对产品进行轻量化管理，像git一样好用。OpenAPI暴露标准Rest风格HTTP接口，简单易用，方便多语言集成。服务管理实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能。配置管理实现配置管CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能。元数据管理提供元数据CURD 和打标能力。Nameserver解决namespace到clusterid的路由问题，解决用户环境与nacos物理环境映射问题。CMDB解决元数据存储，与三方cmdb系统对接问题，解决应用，人，资源关系。Metrics暴露标准metrics数据，方便与三方监控系统打通。Trace暴露标准trace，方便与SLA系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通。接入管理相当于阿里云开通服务，分配身份、容量、权限过程。用户管理解决用户管理，登录，sso等问题。权限管理解决身份识别，访问控制，角色管理等问题。审计系统扩展接口方便与不同公司审计系统打通。通知系统核心数据变更，或者操作，方便通过SMS系统打通，通知到对应人数据变更。插件机制实现三个模块可分可合能力，实现扩展点SPI机制。事件机制实现异步化事件通知，sdk数据变化异步通知等逻辑。日志模块管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档。回调机制sdk通知数据，通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性。寻址模式解决ip，域名，nameserver、广播等多种寻址模式，需要可扩展。推送通道解决server与存储、server间、server与sdk间推送性能问题。容量管理管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性。流量管理按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制。缓存机制容灾目录，本地缓存，server缓存机制。容灾目录使用需要工具。启动模式按照单机模式，配置模式，服务模式，dns模式，或者all模式，启动不同的程序+UI。一致性协议解决不同数据，不同一致性要求情况下，不同一致性机制。存储模块解决数据持久化、非持久化存储，解决数据分片问题。
7. 数据模型
Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。
SDK 类视图
8. Nacos 2.X
gRPC Rsocket 长连接RPC调用和推送能力
- 通信层统一到
gRPC协议，同时完善了客户端和服务端的流量控制和负载均衡能力，提升的整体吞吐。 - 将存储和一致性模型做了充分抽象分层，架构更简单清晰，性能更加强悍。
- 设计了可拓展的接口，提升了集成能力，如让用户扩展实现各自的安全机制。
8.1. 服务发现升级
一致性模型 Nacos2架构下的服务发现，客户端通过 gRPC ，发起注册服务或订阅服务的请求。服务端使用 Client 对象来记录该客户端使用 gRPC 连接发布了哪些服务，又订阅了哪些服务，并将该 Client 进行服务间同步。由于实际的使用习惯是服务到客户端的映射，即服务下有哪些客户端实例；因此2.0的服务端会通过构建索引和元数据，快速生成类似 1.X 中的 Service 信息，并将 Service 的数据通过 Grpc Stream 进行推送。
8.2. 配置管理升级
通讯机制 配置管理之前用 Http1.1 Keep Alive 模式30s发一个心跳模拟长链接，内存消耗大，推送性能弱。2.0 gRPC 彻底解决这些问题，内存消耗大量降低。
8.3. 总结
- 客户端不再需要定时发送实例心跳，只需要有一个维持连接可用keepalive消息即可。重复TPS可以大幅降低。
- TCP连接断开可以被快速感知到，提升反应速度。
- 长连接的流式推送，比UDP更加可靠；nio的机制具有更高的吞吐量，而且由于可靠推送，可以加长客户端用于对账服务列表的时间，甚至删除相关的请求。重复的无效QPS可以大幅降低。
- 长连接避免频繁连接开销，可以大幅缓解TIME_ WAIT问题。
- 真实的长连接，解决配置模块GC问题。
- 更细粒度的同步内容，减少服务节点间的通信压力。
