从本章开始，我们开始聊聊微服务内容。这里我们还是从场景入手，逐步展开说明，达到快速掌握微服务的一些组件实现原理，最终理解微服务架构的本质。
一、业务场景（八）
当前公司已经拥有了50多个服务，并且服务之间存在调用关系，而这些服务是使用各种语言编写的，比如Java、Go、Node.js。
因为跨语言，而目前流行的 Spring Cloud、Dubbo 都是针对 Java 语言的，所以我们没有使用 Spring Cloud、Dubbo 这些微服务框架。
那么，我们是如何配置各个服务之间的调用关系的呢？我们一起还原下当时的配置过程。
因为这 50 个服务都有负载均衡，所以我们首先需要把服务的地址和负载均衡全部配置在 Nginx 上，类似这样：
upstream user-servers {
server 192.168.5.150:80;
server 192.168.5.151:80;
}
upstream order-servers {
server 192.168.5.153:80;
server 192.168.5.152:80;
}
…
server{
listen 80;
server_name user-servers;
location / {
proxy_pass
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server{
listen 80;
server_name order-servers;
location / {
proxy_pass
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
而服务之间的调用关系主要通过本地配置文件配置，如下代码所示：
user.api.host
order.api.host
配置过程说明：我们先通过本地配置文件获取需要调用的服务的主机地址，再在代码中加上 URI 组装成 URL，然后所有服务之间的调用都通过 Nginx 代理，调用关系的架构图如下图所示：
那么，在以上这种架构中，我们到底会遇到哪些问题呢？
二、旧架构会出现的问题
1、配置烦琐，上线容易出错
上线部署时这个问题经常发生，因为每次增服务/加机器/减机器时，Nginx 都需要手工配置，而且每个环境都不一样，这样就很容易出错。
因此，服务器迁移或网络变动时，我们需要把这些配置重新捋一遍，并进行多轮测试才能确保没问题，要是我们没有进行详细检查，某些节点负载均衡出错了可能还不知道。
2、加机器要重
公司的流量起来后，通过监控我们发现有些服务需要增加机器，这个时候最考验系统的抗压性了。因为这个过程需要手工配置，稍不留神系统就会出错，比如一不小心按到了键盘多输了一个字符或没输对 IP。
而系统一旦出错，我们就需要重启 Nginx。我们设想下如果你是运维，请问那时你敢重启吗？要是重启失败了，那就完蛋了。因此，我们需要在短时间内确保配置准确无误，因为加机器是一件很急的事情，不会留给我们太多时间进行检查。
3、Nginx 单点
因为所有的服务都需要经过 Nginx 代理，所以 Nginx 很容易成为瓶颈。而如果 Nginx 配置出了问题，所有的服务就都不能用了，风险很大。好，那我们就让每个服务拥有自己的 Nginx ，而不是所有后台服务共用 1 个 Nginx 。这种方法可是可以，不过这种方式也很坑爹，当配置多了，运维出错概率也大了。
4、管理困难
在实际工作中，因为合规的要求，我们经常需要对全系统调用库进行升级，为了保证所有服务不遗漏，这就要求我们必须有一个后台服务清单。
考虑到后台服务清单都是通过手工进行维护的，所以我们需要定期对其进行整理，这着实是个苦力活。为了解决这个问题，我们尝试了不少解决方案，现在我分享 3 种有效的解决思路。
**（1）**将所有后台服务的服务清单及每种服务的服务器节点列表推送到所有的后台服务后，后台服务会自己控制调用哪个服务的哪个节点，这就是 Spring Cloud 和 Dubbo 的做法。 **（2）**将所有的服务部署到容器上，然后利用 Kubernetes 的 Service 与 Pod 的特性进行服务注册发现。 
具体操作：我们先在部署 User 服务的 Pod 上打上“User-App”标签，K8s 上就可以启动多个 User 的 Pod，其中 1 个 Service 叫 User Service，专门处理标签为“User-App”的 Pod，从 Client 过来的请求首先会到 User Service，再自动负载均衡到某个 User 服务的 Pod。（为了便于你理解，这里介绍的比较简单，如果你对 Kubernetes 感兴趣可以深入了解下。）
**（3）**每个服务会自动将服务和 IP 注册到协调服务（比如 ZooKeeper），然后设计一个工具自动获取 ZooKeeper 中后台服务的机器列表，最终根据列表自动更新 Nginx 的配置，更新完后再重启。
最终我们的方案采用的是第一种解决思路。
不用第二种解决思路的原因是那时我们对容器不熟悉，且几年前，容器的生产环境还没有那么成熟，如果需要我们把所有的服务迁移到容器，代价跟风险都太大。
而不使用第三种解决思路的原因是它并没有解决 Nginx 单点瓶颈、加机器后需要重启的问题。
因此，最终我们的解决思路如下图所示：
通过这张架构示意图，我们发现整个解决思路过程分为这么几个步骤：
- 每个后台服务自动把服务类型和 IP 注册到中心存储；
- 中心存储将服务列表推送到每个后台服务；
- 后台服务在本地做负载均衡，轮流访问同服务的不同节点。
解决思路出来了，接下来我们看看都有哪些注意点需要考虑。这里，我总结了四点注意事项，希望对你有所帮助。
三、注意事项
1、中心存储使用啥技术？
其实通过上面内容的介绍，我们发现这个问题使用一个Redis就可以解决了，但还需要考虑以下两个需求：
- 服务变更的需求，实时推送所有后台服务。比如我们新增了一个服务器节点，服务器节点启动时会自动连接中央存储，当后台列表更新其他后台服务如何实时收到更新请求？
- 随时监听所有后台服务的状态，如果某个服务宕机了，及时通知其他服务。
对于以上两点需求，分布式协调服务这个中间件，刚好能全部满足，所以最终我们选择使用分布式协调服务来存储服务器列表。
2、到底使用哪个分布式协调服务？
关于到底使用哪个分布式协调服务技术的问题，网络上存在如下一个技术对比表格，内容超级详细，大家可以参考了解下。
看到这里，大家应该知道怎么选了吗？其实，在实际技术选型过程中，我们不光需要考虑技术本身，还需要考虑组织的背景。比如我们公司那时已经在使用 ZooKeeper，对于运维团队而言，他们一般不会同时维护 2 种协调服务中间件，所以我们最终没有选择 ZooKeeper 以外的协调服务。
-
基于 ZooKeeper 需要实现哪些功能？
我们这边需要实现的几个要点就是：
-
服务启动的时候，将信息注册到 ZooKeeper；
-
将所有的后台服务信息从 Zookeeper 拉取下来；
-
监听 ZooKeeper 事件，如果后台服务信息出现变更，就更新本地列表；
-
调用其他服务时，如果需要实现 1 个负载均衡策略，一般用轮询（Ribbon）就可以了。
上面几个要点整体来说，我们实现起来一点儿也不复杂。
-
ZooKeeper 宕机了怎么办？
因为后台服务都是多台部署，比如某个节点宕机了，我们需要保证同服务的其他节点还可以正常工作，所以我们的重点是保证 Zookeeper 集群的高可用。（ZooKeeper 本身就有集群的能力，我们就不赘述了。）
ZooKeeper 设计本身为了一致性牺牲了高可用性，它同时兼着 Leader、Follower 和 Observer 三种角色，如果 Leader 或半数的 Follower 宕机了，Zookeeper 就会傲娇地进入漫长的恢复模式。而在这段时间里，Zookeeper 不接受客户端的任何请求，这就容易出现以下三种问题。
-
假设后台服务之前已经在本地已经有所有后台服务的清单，这个时候算运气好，后续你只需要保证这段时间新的后台服务器没有变更就行。
-
假设这段时间服务器刚好变更了，那就可能出现调用失败的情况。
-
假设后台服务在 ZooKeeper 恢复期间启动了，它便连不上 Zookeeper，也获取不到后台服务清单，这个最惨了。
听起来这个坑还挺大的，遇到以上问题我们该怎么办呢？
当时我们的做法是每次通过某个特定服务把所有服务清单同步一份到配置中心，新的后台服务获取不到服务清单时，再从配置中心获取。这个做法虽然没法解决 100% 的问题，但是已经算是一个性价比不错的方案了，而且到目前为止，我们的这个方案还没发生过以上说的那些问题。（也是运气好。）
四、总结
其实这个架构有点类似于自己造轮子，因为注册发现明明就是 Spring Cloud 或 Dubbo 已经实现的功能。不过，本篇文章意义在于可以帮助你从另外几个角度理解微服务中服务注册发现的实现原理。
