如何确定分布式体系结构

从一开始就对新应用程序进行负载测试。

因为预先做一个大的设计永远不会给你期望的结果(15年以上的经验)，最好的办法是为变化而设计，让正确的架构从你的需求中出现。

给出你的描述，对这个项目采用敏捷方法，并使用它的实践来指导你的项目走向成功。其中一个重要的做法是对你所做的所有工作都有一个"完成的定义"。显然，在您的DoD中，您将拥有以下条目:

• 需要通过负载测试(40,000个订单;每天25000用户)

当您开始开发时，首先要做的事情之一当然是设置能够运行这样一个负载测试的环境。如果这种情况永远不会发生，那么您在项目的早期就已经知道您将遇到麻烦。在需要的时候进行多次负载测试(至少每个sprint一次)，你就会知道你的架构可以处理规模需求。

HtH

这将取决于许多其他因素，而不仅仅是每天的订单数量。在哪里举办?物理架构是什么样的?除了电子商务，这个应用程序还能做什么?它是否需要与其他应用程序集成(当然除了支付网关)?等。

一个简单的两层应用程序在合适的云托管环境中(比如VMware)，可以动态扩展，对于电子商务网站来说就很好了。一个简单的两层应用程序在正确的本地托管环境(负载平衡的web farm)中也应该可以很好地工作于电子商务网站。这是向上扩展(可能隐藏在虚拟化中，最终成为一种不可分类的扩展)和向外扩展(添加更多服务器)之间的区别。

分布式架构将允许您将系统负载(例如订单处理)分配到位于负载均衡器后面的1:M服务器上。这是一种非常常见的方法，对于电子商务网站来说也非常有效。

在我看来，没有一种架构或系统设计适合所有模式。最适合每种模式的体系结构(这也是我的观点)是面向服务的体系结构。如果所有的业务流程和逻辑都是服务(并且设计正确)，那么无论您的需求如何变化，无论您的托管环境是什么样子或更改为什么，无论您有什么集成需求，您的系统都可以在很少或没有更改的情况下处理它。

既然你正在编写。net代码，那么就把应用程序放在Azure中(da cLOUD man, da cLOUD !;)。

它将帮助你获得你需要的处理能力。只要你不犯任何愚蠢的错误，这个应用程序就能正常工作。

可以通过负载平衡来解决伸缩问题，至少是部分解决。

并发性可能是你真正的问题。分布式事务是一个笨重的工具，但如果没有额外的思考，它不会解决每个用例。

一些金融公司对直接访问数据库的web服务器有额外的安全要求。