业务场景

公司拥有多个服务，并且很多服务之间都有调用关系，而这些服务是使用各种语言编写的，比如 Java、Go、Node.js。因为跨语言，而目前流行的 Spring Cloud、Dubbo 都是针对 Java 语言的，所以没有使用 Spring Cloud、Dubbo 这些微服务框架

如何配置各个服务之间的调用关系的呢/span>

因为有多个服务都有负载均衡，所以我们首先需要把服务的地址和负载均衡全部配置在 Nginx 上，类似这样

而服务之间的调用关系我们主要通过本地配置文件配置，如下代码所示

配置过程说明：先通过本地配置文件获取需要调用的服务的主机地址，再在代码中加上 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

3. 每个服务会自动将服务和 IP 注册到协调服务（比如 ZooKeeper），然后设计一个工具自动获取 ZooKeeper 中后台服务的机器列表，最终根据列表自动更新 Nginx 的配置，更新完后再重启

最终方案采用的是第一种解决思路

不用第二种解决思路的原因是那时我们对容器不熟悉，且几年前，容器的生产环境还没有那么成熟，如果需要我们把所有的服务迁移到容器，代价跟风险都太大

而不使用第三种解决思路的原因是它并没有解决 Nginx 单点瓶颈、加机器后需要重启的问题

最终解决思路如下图所示

通过这张架构示意图，发现整个解决思路过程分为这么几个步骤

• 每个后台服务自动把服务类型和 IP 注册到中心存储；
• 中心存储将服务列表推送到每个后台服务；
• 后台服务在本地做负载均衡，轮流访问同服务的不同节点

解决思路出来了，接下来看看都有哪些注意点需要考虑。这里总结了四点注意事项

1. 中心存储服务使用啥技术/strong>

通过上面内容的介绍，发现这个问题使用一个 Redis 就可以解决了，但还需要考虑以下 2 个需求

• 服务变更的需求，实时推送给所有后台服务。 比如我们新增了一个服务器节点，服务器节点启动时会自动连接中央存储，当后台服务列表更新，其他后台服务如何实时收到更新请求/li>
• 随时监听所有后台服务的状态，如果某个服务宕机了，及时通知其他服务

对于以上 2 点需求，分布式协调服务这个中间件技术，刚好能全部满足，所以最终我们使用分布式协调服务来存储服务器列表

2. 到底使用哪个分布式协调服务/strong>

关于到底使用哪个分布式协调服务技术的问题，网络上存在如下一个技术对比表格，内容超级详细，可以参考了解下

在实际技术选型过程中，不光需要考虑技术本身，还需要考虑组织的背景。比如公司已经在使用 ZooKeeper，对于运维团队而言，他们一般不会同时维护 2 种协调服务中间件，所以最终没有选择 ZooKeeper 以外的协调服务

3. 基于 ZooKeeper 需要实现哪些功能/strong>

需要实现的几个要点就是

• 服务启动的时候，将信息注册到 ZooKeeper；
• 将所有的后台服务信息从 Zookeeper 拉取下来；
• 监听 ZooKeeper 事件，如果后台服务信息出现变更，就更新本地列表；
• 调用其他服务时，如果需要实现 1 个负载均衡策略，一般用轮询（Ribbon）就可以了

4. ZooKeeper 宕机了怎么办/strong>

因为后台服务都是多台部署，比如某个节点宕机了，我们需要保证同服务的其他节点还可以正常工作，所以我们的重点是保证 Zookeeper 集群的高可用

ZooKeeper 设计本身为了一致性牺牲了高可用性，它同时兼着 Leader、Follower 和 Observer 三种角色，如果 Leader 或半数的 Follower 宕机了，Zookeeper 就会傲娇地进入漫长的恢复模式。而在这段时间里，Zookeeper 不接受客户端的任何请求，这就容易出现以下三种问题

• 假设后台服务之前已经在本地已经有所有后台服务的清单，这个时候算运气好，后续你只需要保证这段时间新的后台服务器没有变更就行
• 假设这段时间服务器刚好变更了，那就可能出现调用失败的情况
• 假设后台服务在 ZooKeeper 恢复期间启动了，它便连不上 Zookeeper，也获取不到后台服务清单，这个最惨了

听起来这个坑还挺大的，遇到以上问题该怎么办呢/span>

当时的做法是每次通过某个特定服务把所有服务清单同步一份到配置中心，新的后台服务获取不到服务清单时，再从配置中心获取。这个做法虽然没法解决 100% 的问题，但是已经算是一个性价比不错的方案了

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树k8s包管理(helm)安装helm8665 人正在系统学习中

来源：知识记录者-vincent