服务注册与发现

• 服务注册：简单理解，就是有一个注册中心，我们的每个服务实例启动时，都去注册中心注册一下，告诉注册中心我的地址，端口等信息。同样的服务实例要删除时，去注册中心删除一下，注册中心负责维护这些服务实例的信息。
• 服务发现：既然注册中心维护了各个服务实例的信息，那么客户端通过注册中心就很容易发现服务的变化了。

有了服务注册与发现，客户端就不用再去配置各个服务实例的地址，改为从注册中心统一获取。
那注册中心又是怎么保证每个地址的可用状态呢，假如某个实例挂了怎么办呢？原则上挂掉的实例不应该被客户端获取到，所以就要提到：健康检查 。

• 健康检查：每个服务都需要提供一个用于健康检查的接口，该接口不具备业务功能。服务注册时把这个接口的地址也告诉注册中心，注册中心会定时调用这个接口来检测服务是否正常，如果不正常，则将它移除，这样就保证了服务的可用性。

常见注册中心有 Consul、ZooKeeper、etcd、Eureka。

Consul的作用

微服务带来大的好处就是把整个大项目分割成不同的服务，运行在不同服务器上，实现解耦和分布式处理。微服务虽然有很多好处，但是也会有不好的一方面。任何事物都会有两面性，在微服务里面运维会是一个很大的难题，如果有一天我们的服务数量非常的多，然后我们又不知道哪一个服务在什么机器上。可能会有人说这部分直接写在程序的配置里面就好了，当我们服务少的时候是可以这么做的，也允许这么做，但是在实际当中我们要尽量避免这么做，比如说我们某一个服务，地址换了，那么我们设计的相关代码就得修改重新部署；又或者说我们有一天上线一个新服务或者下线一个服务，这时候我们又得修改程序代码，这是非常不合理的做法。那么有没有什么可以解决这样的问题呢？这里就需要用到我们的服务注册和发现了。

没有服务注册发现的结构

上面图片我们可以看到在没有服务注册发现的时候一个调用者需要维护多个服务的ip和端口，这是非常不好的做法，当我们服务进行调整的时候就有可能导致服务调用失败，还有服务器更换服务器，上下新服务，都会受到影响。将来某一个服务节点出现问题，排查对于程序和运维人员来说都是一场很大的灾难，因为不知道哪一个节点出了问题，需要每一台服务器的去排查。

而当我们有使用服务注册发现之后的结构体是什么样子的呢？

有服务注册发现的结构

我们从上图可以发现，当我们有注册中心之后调用者不需要自己去维护所有服务的信息了，仅需要向注册中心请求获取服务，就可以拿到想要的服务信息。这样当我们的服务有所调整，或者上线下线服务，都要可以轻松操作，并且可以在注册中间检查到服务的健康情况，帮助运维人员快速定位到故障的服务器。

在Swoft这个框架里面推荐我们使用的就是consul，consult是一个使用go写的服务注册、发现、配置管理系统。

• Agent：Agent是Consul集群中一个常驻后台的程序。Agent有两种模式，一种是服务端，一种是客户端。所有Agent都可以运行DNS或者HTTP接口，并且负责检查服务是否存活，和保持服务同步。

• Client：Client是一种Agent的运行模式，把所有RPC转发到Agent服务器的代理者，客户端会在后台有一个用最小带宽消耗把请求转发到后端的Agent服务，减轻Agent服务器的压力。

• Server：Server是另一种Agent的运行模式，包括使用Raft算法处理数据，维护集群状态，响应RPC的请求，与其他集群的server交换数据或者远程数据中心。

• RPC：远程过程调用，这是一种允许客户端发出服务器请求的请求/响应机制。

以上是我们本次比较重要的一些概念性的东西。知道每一个组件每一个部分干嘛的我们看以下的配置才会简单，才会事半功倍。

在consult里面有很多组件，在这里我们暂时使用一个组件就够了就是agent，对于consul的安装也是非常简单的毕竟只有一个二进制文件包，所以直接下载就可以使用了。

文章参考：

https://www.sunnyos.com/article-show-85.html （描述作用）

https://www.cnblogs.com/xhznl/p/13091750.html （讲解比较详情，代码注册服务）