地址硬编码问题——电影微服务中将用户微服务的地址写死,如果用户微服务地址发生变化,难道要重新上线电影微服务吗?
服务发现原理初探
-
应用启动时,自动往registry表中插入一条数据,数据包括服务名称、IP、端口等信息。
-
应用停止时,自动把自己在registry表中的数据的status设为 DOWN 。
TIPS看,服务发现机制是不是很简单?程序猿给图中的”MySQL“的组件起了一个牛叉的名字叫:”注册中心“,也有的书将其称为”服务发现组件“。
-
当服务抑或所在主机突然崩溃或者进入某种不正常的情况无法提供服务(例如应用的数据库挂了)时,对应的数据理应标记DOWN,或者索性删除;
-
如果每次调用之前,都得向服务发现组件发送类似 SELECT*FROM registrywhereservice_name='user'andstatus='UP' 的语句,那么服务发现组件的压力得有多大?更重要的,这与当下流行的去中心化设计的思想相悖;
-
服务发现组件即使挂掉,也不应该影响微服务之间的调用。
服务发现原理深入
-
各个微服务在启动时,将自己的网络地址等信息注册到服务发现组件中,服务发现组件会存储这些信息;
-
服务消费者可从服务发现组件查询服务提供者的网络地址,并使用该地址调用服务提供者的接口;
-
各个微服务与服务发现组件使用一定机制(例如心跳)通信。服务发现组件如长时间无法与某微服务实例通信,就会自动注销(即:删除)该实例;
-
当微服务网络地址发生变更(例如实例增减或者IP端口发生变化等)时,会重新注册到服务发现组件;
-
客户端缓存:各个微服务将需要调用服务的地址缓存在本地,并使用一定机制更新(例如定时任务更新、事件推送更新等)。这样既能降低服务发现组件的压力,同时,即使服务发现组件出问题,也不会影响到服务之间的调用。
-
服务注册表:服务注册表是服务发现组件的核心(其实就是类似于上面的registry表),它用来记录各个微服务的信息,例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API,查询API用于查询可用的微服务实例,管理API用于服务的注册和注销;
-
服务注册与服务发现:服务注册是指微服务在启动时,将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制;
-
服务检查:服务发现组件使用一定机制定时检测已注册的服务,如发现某实例长时间无法访问,就会从服务注册表中移除该实例。
更多免费技术资料可关注:annalin1203