TL;DR
……是的，处理这么多任务快把我累垮了，所以我需要你们的帮助。拜托了！
假设我开发了一款新的移动应用。我的系统包含前端和后端服务，它们通过 REST API 进行通信。这就是我的系统架构。
我的产品首次上市，目前只有少数用户。后端服务运行良好，能够按预期处理请求。用户对应用的运行速度非常满意。
随着我为应用程序添加更多功能，用户数量也在增长。我的后端服务需要处理的请求数量比以前更多。请求数量的增长开始影响后端服务，导致性能下降。由于无法处理所有请求，后端服务甚至会宕机。这意味着可用性也受到了影响。
用户开始抱怨应用运行速度变慢。他们很不满意，我也很不满意，因为我担心会流失用户。我该如何提升后端性能？如何提高后端可用性？
实现这一目标的方法有很多种。可以是重新审视应用程序算法，可以是更换编程语言，可以是增加服务器资源，也可以是增加后端服务的实例。诸如此类，不胜枚举。
在这种情况下，我将选择添加更多后端服务的实例，因为我有足够的时间重写后端服务。
由于我需要创建后端服务的多个实例，因此需要一种机制将来自移动应用程序的请求重定向到这些实例。这里我使用了负载均衡器。顾名思义，负载均衡器用于在后端实例之间分配工作负载。我的架构如下所示。
负载均衡器有自己的算法来分配工作负载。我可以选择的算法有几种，例如轮询调度、加权轮询调度、最少连接数调度等等。我可以根据我的需求选择合适的算法。
在这种情况下，我的后端服务现在需要处理的请求数量将比以前少。假设之前单个后端服务平均每分钟处理约 6000 个请求。现在我可以将工作负载分配给三个实例，这意味着每个实例每分钟将处理 2000 个请求。这将有助于提高性能和正常运行时间。
我们可以使用一些负载均衡技术，例如 HAProxy、Nginx 和云负载均衡。您可以根据需要选择任何一种。
只处理这种情况吗？
显然不是！负载均衡不仅仅适用于处理高负载的情况。那么还有什么其他方法呢？
假设我有一些服务运行在虚拟机上。现在我想把所有部署都迁移到容器中。这听起来很简单，因为我只需要使用容器重新部署所有服务。之后，我将所有请求重定向到容器集群。但这真的是个好做法吗？
这种方法风险太大了。想象一下，如果容器集群上的某些部署配置不当，就可能导致停机。那么负载均衡器又能如何帮助我呢？
由于直接迁移到容器集群风险较高，所以我选择分阶段迁移。在将所有服务部署到容器集群后，我想先进行一些请求测试。我可以使用负载均衡器在虚拟机集群和容器集群之间分配负载。我将负载均衡器配置为将 20% 的请求分配给容器集群，80% 的请求分配给虚拟机集群。通过这种方式，我可以监控容器集群的运行状况，确保其配置正确。之后，我可以逐步增加容器集群的请求量，直到完全部署为止。
这种情况与将虚拟机集群迁移到容器集群非常相似。直接迁移单体应用风险很大。负载均衡器可以帮助我分阶段迁移。我可以使用负载均衡器在单体集群和微服务集群之间分配请求。我会一直使用负载均衡器，直到我确信微服务运行良好为止。然后，我才会进行全面迁移。
在 Gojek，我们也自主开发了负载均衡器，名为 Weaver。这是一个开源项目，您可以在这里找到它。
Weaver 是一款具有动态分片策略的七层负载均衡器，它是一款具有高级功能的现代 HTTP 反向代理。
git clone git@github.com:gojektech/weaver.git
make build
从这里下载发布版本的二进制文件：
Weaver 用作etcd控制平面，将传入的请求与特定的路由配置进行匹配，并根据某种分片策略将流量分片到不同的后端。
Weaver 可以配置为匹配不同的路由……
您可以阅读我们创建它的原因，因为我们知道有一些现有的负载均衡技术可以利用。
希望你喜欢阅读！
~CappyHoding 💻 ☕️
blog.gojekengineering.com
blog.gojekengineering.com