我正在研究微服务，并试图理解为什么我必须扩展代码，而不仅仅是数据库，这是实际的瓶颈。好吧，好的，在高负载的世界中，我明白了这一点。但是对于其余的内容，我们不应该只学习如何编排多个DB和多个模式吗？
UPD：我想我的问题还不够清楚，所以我得到了一些很酷的重放，无法阐明这个主题。首先，我了解为什么高负载架构需要扩展业务逻辑。在这里，我要问的是中级项目：如何使它们尽快响应。微服务可能是答案，但是没有人建议伸缩代码只是一种选择，而我的项目每天不会有数百万活跃用户，那么我只能将这种方法应用于数据库层-将其划分为最小的逻辑模式并相应地写入BL。因为不需要sagas，MQ和所有这些工具，开发和维护起来是否容易得多？
答案 0 :(得分：1)
对于复杂的系统，您实际上希望能够在多个维度上进行扩展，所有这些因素均受体系结构选择的影响。在回答您的问题之前，这里有一些最重要的想法：
水平扩展应用程序，例如用于更高的负载/更多的用户。我认为这就是您提到的问题。假设我们谈论的是一个拥有数百万用户的大型应用程序，这个问题在其中最为普遍。瓶颈是很多的，持久性只是其中之一。分布式系统，微服务，无状态应用程序层以及许多最新技术的理论都解决了这个问题。对于数据库，这是集群数据库的兴起；对于业务逻辑，这是无状态的容器化服务部署；对于基础架构，这是云和虚拟化硬件集群的兴起。 关于您的数据库问题，我建议您考虑可伸缩的无SQL数据库的权衡问题，以及关于可集群化，事务性和关系型选择的cockroachdb。这些选择将使您摆脱老式的单服务器数据库约束，而编排多个数据库的提议似乎暗含了这种约束。
扩展组织/开发规模，以便能够在更短的时间内更快地开发并添加更多功能。对于拥有数百万活跃用户的成功应用程序，通常也需要这样做。因此，您将不得不组织具有成百上千个开发人员的开发团队。这里的瓶颈是所需的协调工作量。而且，由于在许多传统的大型组织中，中层管理人员被激励去尽可能多地收购一支团队，因此，许多次的情况是，成立了效率低下的大型开发团队，他们花费了大部分时间来调整工作以产生臭名昭著的工作。昂贵的整体式应用程序。 Conway's Law中总结了此问题。因此，针对（通常是较年轻的）公司进行反击的方法是朝着非常平坦的层次结构和小型，独立的团队发展。这里的独立性是关键因素。允许团队制定自己的愿景（产品管理），执行自己的开发并发布自己的产品（模块，服务，应用程序等）。
然后终于要提出您的原始问题了：
我为什么要缩放代码
对于第1点，我们了解到，取决于并发活动用户的数量和域问题所需的计算强度，我们可能必须将应用程序的业务层扩展到数十个或数百个分布式计算机以容纳该数量并发网络连接并实现工作量（例如，想想Netflix为运行其服务必须做什么）。
从第2点开始，我们了解到我们无法在团队/服务之间共享数据库，因为这会干扰为他们/他们建立独立开发周期并通过协调工作消耗宝贵的生产力的目标。
水平扩展业务逻辑层的其他原因是为了实现无中断服务（例如，当一个节点发生故障时，将有另一个承担请求）并允许通过自动化任务来处理复杂性（devops方法）。
有关此方面的更多信息，我建议您以Martin Fowlers articles为起点。
答案 1 :(得分：0)
查看微服务的10条原则。您可以根据舒适度从数据库开始进行改进，如果负载足够，您将开始在客户端看到问题并开始优化服务。
您可以通过多种方式优化服务，包括负载平衡，缓存，响应格式，REST / gRPC，压缩等。