PROSAGA码农传奇-SO业务编排-扩展业务逻辑有什么意义？

<div class =“post-text”itemprop =“text”>
  
    对于复杂系统，您实际上希望能够在多个维度上进行扩展，所有这些都受到您的架构选择的影响。在我回答你的问题之前，这里有一些关于最重要问题的想法：
  
  <OL>
    <LI>
      
        水平扩展应用程序，例如用于更高负载/更多用户。我认为这就是你提到的问题。假设我们谈论一个拥有数百万用户的真正大型应用程序，这个问题变得最普遍，瓶颈很多，持久性只是其中之一。分布式系统，微服务，无状态应用层和许多最新技术的理论解决了这个问题。对于数据库而言，这是集群数据库的兴起，对于业务逻辑，这是无状态，容器化的服务部署，对于基础架构，这是云和虚拟化硬件集群的兴起。
关于你关于数据库的问题，我建议考虑可扩展的无sql数据库和cockroachdb的权衡，以便进行可集群，事务和关系选择。这些选择可以帮助您解决老派单服务器数据库约束问题，这似乎是协调多个数据库的提议所暗示的。
      
    </LI>
    <LI>
      
        扩展组织/开发规模，以便能够更快地开发并在更短的时间内添加更多功能。对于拥有数百万活跃用户的成功应用程序，通常也需要这样做。因此，您必须组织有数百或数千名开发人员的开发团队。这里的瓶颈是所需协调工作量。而且因为在许多传统的大型组织中，中层管理人员被激励尽可能多地收集团队，所以很多时候发生了大型无效的开发团队，他们花费大部分时间调整工作以便产生臭名昭着的昂贵的整体式应用。这个问题总结如下
        <a href="https://en.wikipedia.org/wiki/Conway%27s_law" rel="nofollow noreferrer">
          康威定律
        </A>
        。因此，针对（通常是年轻的）公司反击这种情况的方法是走向非常扁平的等级制度，转向小型的独立团队。独立性是这里的关键因素。允许团队开发自己的愿景（产品管理），执行自己的开发并发布自己的产品（模块，服务，应用程序等）。
      
    </LI>
  </醇>
  
    然后最终得出你原来的问题：
  
  <BLOCKQUOTE>
    
      为什么我必须扩展代码
    
  </BLOCKQUOTE>
  
    通过第1点，我们了解到，根据并发活动用户的数量和域问题所需的计算强度，我们可能必须将应用程序的业务层扩展到数十或数百个分布式计算机以容纳并发网络的数量连接并实现工作量（例如，想想Netflix在运行服务时必须做些什么）。
  
  
    通过第2点，我们了解到我们无法在团队/服务之间共享数据库，因为这会干扰为这些人提供独立开发周期的目标，并通过协调工作消耗宝贵的生产力。
  
  
    横向扩展业务逻辑层的其他原因是启用无中断服务（例如，当节点发生故障时，将有另一个接收请求）并允许通过任务自动化处理复杂性（
    <a href="https://en.wikipedia.org/wiki/DevOps" rel="nofollow noreferrer">
      DEVOPS
    </A>
     方法）。
  
  
    关于这方面的更多方面，我建议阅读
    <a href="https://martinfowler.com/articles/microservices.html" rel="nofollow noreferrer">
      Martin Fowlers的文章
    </A>
     作为一个起点。
  
</DIV>