扩展业务逻辑有什么意义？答案

【问题标题】：What's the point of scaling business logic?扩展业务逻辑有什么意义？
【发布时间】：2019-06-21 23:50:13
【问题描述】：

我正在深入研究微服务并试图了解为什么我必须扩展代码，而不仅仅是数据库，这是实际的瓶颈。好吧，在高负载的世界里，我明白了这一点。但对于其余的，我们不应该只学习如何编排多个 DB 和多个模式吗？

UPD：我想我的问题不够清楚，所以我得到了一些很酷的回放，但并没有阐明主题。首先，我明白为什么高负载架构需要扩展业务逻辑。在这里我问的是中级项目：如何让他们尽快响应。微服务可能是答案，但没有人建议扩展代码只是一种选择，而且我的项目每天不会有数百万活跃用户，那么我只能将这种方法应用于 DB 层 - 将其划分为尽可能小的逻辑模式并相应地写下 BL。不需要 sagas、MQ 之类的东西，开发和维护是不是容易多了？

【问题讨论】：

orchestrate multiple DBs?不，不，不 - 系统集成的基本原则之一是您应该避免使用共享数据库进行集成。
@AdamSiemion 你能分享一个链接，让我可以阅读更多关于该原则的信息吗？
“企业应用架构模式”、“企业集成模式：设计、构建和部署消息解决方案”，例如或my M.Sc.

标签： database architecture microservices scalability distributed-computing

【解决方案1】：

查看微服务的 10 条原则。您可以根据您的舒适度首先从数据库开始改进，如果您有足够的负载，您将开始在客户端看到问题并开始优化服务。

您可以通过多种方式优化服务，包括负载平衡、缓存、响应格式、REST/gRPC、压缩等。

【讨论】：

【解决方案2】：

对于复杂系统，您实际上希望能够在多个维度上进行扩展，所有这些都受到您的架构选择的影响。在我回答你的问题之前，这里有一些最重要的想法：

水平扩展应用程序，例如对于更高的负载/更多的用户。我认为这就是您所指的问题。假设我们谈论一个拥有数百万用户的非常大的应用程序，这个问题变得最普遍，瓶颈很多，持久性只是其中之一。分布式系统、微服务、无状态应用层和许多最新技术的理论解决了这个问题。对于数据库而言，这是集群数据库的兴起，对于业务逻辑而言，这是无状态、容器化的服务部署，对于基础设施而言，这是云和虚拟化硬件集群的兴起。关于您关于数据库的问题，我建议您研究可扩展的 no-sql 数据库以及 cockroachdb 的权衡，以获得可集群、事务和关系的选择。这些选择将使您绕过老式的单服务器数据库限制，这似乎是在协调多个数据库的提议中暗示的。
扩展组织/开发规模，以便能够更快地开发并在更短的时间内添加更多功能。这通常也是拥有数百万活跃用户的成功应用程序所必需的。因此，您将不得不与成百上千的开发人员一起组织开发团队。这里的瓶颈是所需的协调工作量。而且因为在许多传统的大型组织中，中层管理人员被激励去收购尽可能多的团队，所以很多时候形成了大型、低效的开发团队，他们大部分时间都在调整他们的工作以产生臭名昭著的昂贵的单体式应用程序。这个问题总结在Conway's Law。因此，对于（通常是年轻的）公司来说，反击这种情况的方法是转向非常扁平的层次结构和小型、独立的团队。独立性是这里的一个关键因素。团队可以制定自己的愿景（产品管理）、执行自己的开发并发布自己的产品（模块、服务、应用程序等）。

然后终于来到你原来的问题：

为什么我必须缩放代码

通过第 1 点我们了解到，取决于并发活跃用户的数量和域问题所需的计算强度，我们可能需要将应用程序的业务层扩展到数十或数百台分布式机器以容纳数量并发网络连接并实现工作负载（例如，想想 Netflix 必须为运行他们的服务做些什么）。

关于第 2 点，我们明白我们不能在团队/服务之间共享数据库，因为这会干扰为这些团队/服务建立独立开发周期并通过协调努力消耗宝贵生产力的目标。

水平扩展业务逻辑层的其他原因是启用无中断服务（例如，当一个节点发生故障时，将有另一个节点接收请求）并允许通过任务自动化来处理复杂性（devops 方法）。

关于这方面的更多方面，我建议您阅读 Martin Fowlers articles 作为起点。

【讨论】：