一、解决什么问题
首先,通过一个例子告诉你服务治理解决了什么问题。
我的系统包含两个微服务(服务A和服务B),每一个微服务有10个虚拟节点,两个服务组成了一个20台虚拟机的微服务集群。如果此时微服务A想要调用微服务B,我们怎么来发起这个调用呢?
一种通用做法是:在服务A的配置文件中添加一个指向服务B的地址,但这个地址并不直接指向任何一台服务B集群中的节点,而是指向一个VIP(虚拟IP地址)或者是一个网关。这个VIP或网关背后维护了B集群的服务节点列表,VIP层通过负载均衡策略再将请求转到后面配置的某一台服务器。一幅图来描述这个服务调用过程。

服务A与服务B之间互相不直接通信,服务调用完全依靠VIP作为中间人来完成。我们如果想要为服务集群扩容或缩容,必须将服务器配置到对应的VIP地址上。如果你的应用是一个由数百个微服务组成的大型应用,光是管理这些VIP Pool的人力成本就够网络运维团队喝上一壶了。
二、微服务生命周期
首先,服务B集群向注册中心发起了注册,将自己的地址信息上报到注册中心,这个过程就是服务注册。接下来,每隔一段时间,服务A就会从服务中心获取服务B集群的服务列表,或者由服务中心将服务列表的变动推送给服务A,这个过程叫做服务发现;最后,服务A根据本地负载均衡策略,从服务列表中选取某一个服务B的节点,发起服务调用。

三、Nacos体系架构
Nacos有三个核心知识点:领域模型、数据模型和基本架构,这是我们整体把握Nacos架构的关键。
领域模型
Nacos领域模型描述了服务与实例之间的边界和层级关系。Nacos的服务领域模型是以“服务”为维度构建起来的,这个服务并不是指集群中的单个服务器,而是指微服务的服务名。
“服务”是Nacos中位于最上层的概念,在服务之下,还有集群和实例的概念。

从上面的图中你可以看出,Nacos的服务领域模型从上到下分为了服务、集群和实例三层。
服务
在服务这个层级上我们可以配置元数据和服务保护阈值等信息。服务阈值是一个0~1之间的数字,当服务的健康实例数与总实例的比例小于这个阈值的时候,说明能提供服务的机器已经没多少了。这时候Nacos会开启服务保护模式,不再主动剔除服务实例,同时还会将不健康的实例也返回给消费者。尽管这样做可能造成请求失败,但间接保证了最低限度的服务可用性。
集群
一个服务由很多服务实例组成,在每个服务实例启动的时候,我们可以设置它所属的集群,在集群这个层级上,我们也可以配置元数据。除此之外,我们还可以为持久化节点设置健康检查模式。
所谓持久化节点,是一种会保存到Nacos服务端的实例,即便该实例的客户端进程没有在运行,实例也不会被服务端删除,只不过Nacos会将这个持久化节点状态标记为不健康,Nacos可以采用一种“主动探活”的方式来对持久化节点做健康检查。
除了持久化节点以外,大部分服务节点在Nacos中以“临时节点”的方式存在,它是默认的服务注册方式,从名字中我们就可以看出,这种节点不会被持久化保存在Nacos服务器,临时节点通过主动发送heartbeat请求向服务器报送自己的状态。
实例
这里所说的实例就是指服务节点,我们可以在Nacos控制台查看每个实例的IP地址和端口、编辑实例的元数据信息、修改它的上线/下线状态或者配置路由权重等等。
你会发现,在这三个层级上都有“元数据”这一数据结构,你可以把它理解为一组包含了服务描述信息(如服务版本等)和自定义标签的数据集合。Client端通过服务发现技术可以获取到每个服务实例的元数据,你可以将自定义的属性加入到元数据并在Client端实现某些定制化的业务场景。
了解了领域模型之后,你知道服务调用的发起方是如何定位到领域模型中的服务实例的吗?这就要说起Nacos的数据模型了。
数据模型
Nacos的数据模型有三个层次结构,分别是Namespace、Group和Service/DataId,我画了一幅图,帮你理解这三个层次之间的包含关系:

从上图中你可以看出,Namespace、Group和Service/DataId是一个依次包含的结构,我分别对每一层做一个简单介绍。
- Namespace:即命名空间,它是最顶层的数据结构,我们可以用它来区分开发环境、生产环境等不同环境。默认情况下,所有服务都部署到一个叫做“public”的公共命名空间;
- Group:在命名空间之下有一个分组结构,默认情况下所有微服务都属于“DEFAULT_GROUP”这个分组,不同分组间的微服务是相互隔离的;
- Service/DataID:在Group分组之下,就是具体的微服务了,比如订单服务、商品服务等等。
通过Namespace + Group + Service/DataID,我们就可以精准定位到一个具体的微服务。比如,我想调用生产环境下A分组的订单服务,那么对应的服务寻址的Key就是类似Production.A.orderService的组合。
Nacos基本架构
Nacos的核心功能有两个,一个是 Naming Service,也就我们用来做服务发现的模块;另一个是 Config Service,用来提供配置项管理、动态更新配置和元数据的功能。
Nacos社区的基本架构图来作为示例,看一下Nacos在功能模块层面的基本架构。

本文介绍了服务治理的重要性和Nacos在微服务生态中的作用。详细讲解了服务注册与发现的过程,包括服务A如何通过VIP调用服务B,微服务的生命周期,以及Nacos的领域模型和数据模型。Nacos的架构由Naming Service和Config Service构成,提供服务发现和配置管理功能。
3567

被折叠的 条评论
为什么被折叠?



