一、解决什么问题
首先,通过一个例子告诉你服务治理解决了什么问题。
我的系统包含两个微服务(服务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的节点,发起服务调用。