Architecture 可扩展体系结构/应用程序

如今，我们有一个很大的噪音围绕着可伸缩性，构建一个可以处理数百万请求的应用程序。有许多库旨在帮助您开发可扩展的应用程序，但毕竟只有几种方法可以扩展您的应用程序（这些库只是为您提供了围绕它们的包装）：

• 有一个专用的任务队列（它可以是显式队列，也可以是实现的隐式队列），并有一个或多个线程处理队列中的任务
• 在服务器之间分发执行（负载平衡/分片）

就是这样。这个假设正确吗？还是有其他方法来实现“可伸缩”体系结构？

---

问题的重点是验证是否只有有限的一套（基本上）来扩展应用程序，库/工具只是帮助您实现它们。

在我之前去过的一家公司中，有这样的体系结构，所以

这个假设正确吗

我想是的。该公司规模相对较大，运营经验丰富。您可以考虑其中一个最重要的产品架构，如贝娄所示：

                   ______________
               ->    API1: 1000 
                   --------------
______________     ______________      ______________       |    |
LoadBalancer   ->    API2: 1000     ->   CacheServer   ->   | DB |
--------------     --------------      --------------       |    |
                   ______________
               ->    API3: 1000 
                   --------------

---

可伸缩体系结构需要解决N层单片应用程序中常见的耦合问题，SOA正试图解决这个问题

通过分布、使用异步通信（使用消息传递）、垂直分割（自治）组件、不共享资源（包括数据），您可以实现可伸缩性和持久性，这是一个大主题

我建议你读一读

---

是一种与SOA相结合的解决方案，可以帮助您构建可扩展的持久系统。

从负载平衡器到各个服务器只需一步

无论应用程序需要多少线程，它都需要节省使用的线程数量，以便操作系统的调度程序尽可能少地使用CPU周期来确定最高优先级的线程。实现这一点的一种机制是I/O完成端口，它可以在Windows和某些Unix版本中找到。在这里搜索IOCP

节省对共享资源（通信、数据库、总线、RAM和L3缓存等）的访问，并尝试在非共享资源（L2和L1缓存）中容纳线程和数据，这将导致应用程序比忽略这些访问时更具可伸缩性。有许多多线程应用程序运行速度比单线程应用程序慢的例子

确定SOAP（或XML格式的请求）应该做什么是CPU密集型的，文本越多，任务就越大。如果应用程序使用二进制请求，它将有更多的剩余资源用于执行请求，并且花费更少的时间来理解请求本身。冗长请求和响应的另一个方面是它们占用了通信带宽。1兆字节的响应需要大约10兆字节的带宽。这是每秒100 Mbps连接容量的十分之一。因此，它会将您的响应能力限制为每秒最多10个响应。你想要一千？您需要的响应长度不超过10 kB

如果您的应用程序足够快，那么如果它需要转到另一台服务器来执行部分请求，它将被挂起。即使是光纤互连，这也适用。SAN比物理连接存储速度慢