微服务在当今互联网架构中的重要性就不多说了。随着微服务的广泛应用，“服务发现”一词也发生了变化。天气越来越热了。在平时的工作中，我发现现在很多人喜欢把一些很简单的东西搞得很复杂，比如什么是BFF结构，这个中台那个中台。事实上，服务发现也是如此。很多文章把这个内容写的太妖魔化了，导致很多人望而却步，觉得自己好像很高级，然后放弃这个领域。“其实，服务发现是一个非常简单的过程。”稍微有点编码基础的人都能看懂。传统的客户端与服务端的交互方式服务端123分别提供了一个服务“ip”和“端口号”。这里的client不是我们狭义上理解的clientapp或者frontend。客户端也可以是一个服务端，比如你在一个golang项目中需要不同的服务，那么你的golang项目就是上图中的客户端，这一点尤其要注意。如果更准确的话，这里的客户端应该叫做“服务消费者”，服务端应该叫做“服务提供者”。server2挂了，但是client还不知道，还会继续请求，那么可用性当然就大大降低了，所以下一步就触发了我们接下来要说的“服务发现”模式。服务发现模式大概流程其实，所谓服务发现就是在服务消费者调用服务提供者提供的服务时，多了一层“服务中介”。服务中介中有很多键/值对，键是“服务名称”，值是“服务提供者的地址列表”。“当你添加一个新的服务提供者时，你将kv数据写入服务中介。这个过程称为服务注册。”“你在请求服务的时候，直接把key拿给服务中介，得到相应的值，也就是服务商的地址列表，然后直接请求就行了。”当服务提供者节点挂掉时，要求服务能够及时取消注册，比如及时通知消费者重新获取服务地址，当一个服务提供者加入新的服务提供者时，需要服务中介及时告知服务消费者是否要试用新服务。基本流程如下图Step1：每增加一个新的服务提供者，需要先在服务注册中心注册一个key/value（服务名称/服务提供者地址列表）Step2：服务调用者不直接调用服务提供者，而是带着标志（即上面注册的key（服务名称））到服务注册中心找到对应的值（服务提供者的地址列表）第三步：服务注册center会告诉服务调用者对应的key（服务名称）是否有值（服务提供者的地址列表），如果有则返回对应的值（服务提供者的地址列表）给服务调用者第四步：服务调用者将返回值（服务提供者的地址列表）用户的地址列表）去请求相应的服务服务发现是不是太简单了？上面的流程好像有点太简单了，而且好像没有解决什么问题，还好像增加了复杂度。事实上，情况并非如此。如果服务提供者进程被kill-9暴力杀死，服务消费者不知如何是好？这个不用担心，在服务发现中引入了“服务保活和检查机制”，更换了数据结构。服务提供者需要每5秒左右向服务发现报告一次存活，服务发现在kv中记录服务地址和报告时间。服务中介需要每隔10秒左右检查一次kv数据结构，将上报时间严重滞后的服务地址项踢掉。这样可以准实时地保证服务列表中服务地址的有效性。这就是我们所说的“服务健康检查”，当服务列表发生变化时如何通知消费者？第一种方法是“轮询”。消费者需要每隔几秒检查服务列表是否发生变化。如果服务很多，服务列表很大，消费者也很多，那么服务发现也会承受一定的压力。第二种方式是“订阅消费模式”。服务消费者订阅一个消息，服务提供者如果有变化直接发给消息。对应变化就行了。常见的服务发现方案-DNS-mDNS-Zookeeper-Etcd-Consul对具体的方案有一个大概的了解就可以了。我们稍后会详细介绍“Consul”，我们下期再见。如果这篇文章对你有帮助，
