微服务在当今的互联网架构中的重要性我在这里就不多说了，随着微服务的大范畴利用，服务发现 这个词也变的越来越炽热。在平时的工作中，我发现当初很多人喜爱把一些很简略的事件说的很简单，比方什么 BFF 架构，这中台那中台的。其实服务发现也是一样，很多文章把这块内容写的过于妖魔化，导致很多人看起来云里雾里的感觉如同很浅近的样子，接下来就放弃这块了。其实服务发现是个很简略的过程 ，略微有点编码根底的人都能看懂。明天对此做一个总结，如果对您有用，记得 点个赞点个关注，如果有问题也能够留言，我看到了会第一工夫回复。
传统的客户端和服务端的交互模式
- 服务端 1 2 3 别离提供了一个服务的 ip 和端口号
- 这里的客户端不是咱们广义了解的客户端 app 或者前端，客户端也能够是一个服务端，比方你在一个 golang 我的项目中须要不同的服务等，那么你这个 golang 我的项目就是上图中的客户端，这一点尤其要留神。
- 如果说的精确一点，这里的客户端应该叫做 服务消费者 , 服务端应该叫做 服务提供者
下面这种传统的交互模式看着没什么问题，然而其实可用性并没那么好，首先比方你的服务端 2 挂了，然而客户端还是不晓得的，仍然会持续申请，这样可用性当然是大大的降落的，所以接下来就引发出了咱们接下来要讲的 服务发现 模式
服务发现模式
大略流程
其实所谓的服务发现，就是服务消费者在调用服务提供者提供的服务的时候，多了一层 服务中介 。服务中介中有很多 key/value 键值对，key 是 服务名称 ，value 是 服务提供者的地址列表 。 当你新增一个服务提供者的时候，就往服务中介中写入 kv 数据，这个过程叫做服务注册 当你申请一个服务的时候，间接拿着 key 去服务中介中取对应的 value，也就是服务提供者的地址列表，而后去申请就能够了。
当服务提供者节点挂掉时，要求服务可能及时勾销注册，比便及时告诉消费者从新获取服务地址。
当服务提供者新退出时，要求服务中介能及时告知服务消费者，你要不要尝试一下新的服务。
根本过程如下图
- 步骤 1: 每次新减少一个服务提供者，须要先去服务注册核心注册一个 key/value（服务名称 / 服务提供者的地址列表）
- 步骤 2: 服务调用者不间接调用服务提供者，而是拿着标记 (也就是下面注册的 key(服务名称)) 去服务注册核心查找对应的 value(服务提供者的地址列表)
- 步骤 3: 服务注册核心会通知服务调用者对应的 key(服务名称)是否有 value(服务提供者的地址列表)，有的话会把对应的 value(服务提供者的地址列表)返回给服务调用者
-
步骤 4: 服务调用者会拿着返回的 value(服务提供者的地址列表)去申请对应的服务
服务发现是否太过简略？
下面的过程看起来如同是有点太简略了，而且看起来也没解决什么问题呀，而且如同还徒增了复杂度。其实并不是这样的。
服务提供者过程如果被 kill - 9 暴力杀死，服务消费者不晓得怎么办？
这个不必放心，服务发现中引入 服务保活和查看机制 ，并更换数据结构。服务提供者须要每隔 5 秒左右向服务发现汇报存活，服务发现将服务地址和汇报工夫记录在 kv 中。服务中介须要每隔 10 秒左右查看 kv 数据结构，踢掉汇报工夫重大落后的服务地址项。这样就能够准实时地保障服务列表中服务地址的有效性。这也就是咱们说的 服务健康检查
服务列表变动时如何告诉消费者?
第一种办法是 轮询 ，消费者须要每隔几秒查问服务列表是否有扭转。如果服务很多，服务列表很大，消费者很多，那么服务发现也会有肯定的压力
第二种办法是 订阅生产模式，服务消费者订阅一个音讯，服务提供者有变动间接往音讯中发送对应变动就行。
常见的服务发现计划
– DNS
– mDNS
– Zookeeper
– Etcd
– Consul
具体计划大略理解一下就行，前面咱们会具体介绍一下Consul，那么咱们下期再见吧。如果这篇文章有帮忙到你，记得点赞分享哦，咱们下期见。
本文由 mdnice 多平台公布