如何确定分布式架构？
在设计大型应用程序时，我试图了解思考过程。
假设我有一位客户需要一个新的客户网站，他估计每天有 40,000 个订单，并且已经拥有 25,000 个用户群。在设计应用程序时，您如何确定是否需要分布式架构？我应该使用网络农场吗？过去
我主要构建了 2 层（物理）应用程序，我真的想提高我的理解。
任何见解都会很棒！
I'm trying to get my head around the thought process when designing a large scale application.
Let's say I have a client who needs a new customer website and he is estimating 40,000 orders per day with an already 25,000 user base. When desiging the application, how do you about determining if a distributed architecutre is needed? Should I use a web farm? etc.
I've mostly build 2 tier (physical) applications in the past and I really want to improve my understanding.
Any insight would be great!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从一开始就对您的新应用程序进行负载测试。
由于预先进行大型设计永远不会给您带来预期的结果（15 年以上的经验），因此最好的做法是针对变化进行设计，并让正确的架构根据您的需求出现。
根据您的描述，对该项目采用敏捷方法，并使用其实践来指导您的项目取得成功。其中重要的实践之一就是为您所做的所有工作制定“完成的定义”。显然，您的 DoD 中将包含以下项目：
当您开始开发时，首先要做的事情之一当然是设置环境以能够运行此类负载测试。如果这种情况永远不会发生，那么您在项目的早期就已经知道自己会遇到麻烦。
根据需要多次完成负载测试（至少每个冲刺一次），您将知道您的架构可以处理规模要求。
高温
Load Test your new application from the get-go.
Since doing a big-design up-front will never give you the results that you expect from it (15+ years of experience) the best thing to do is to design for change and let the right architecture emerge from your requirements.
Given your description, adopt an agile methodology for this project, and use its practices to guide your project into a success. One of those vital practices is to have a 'Definition of Done' for all the work that you do. Clearly in your DoD you will have the item:
As you would then start development, one of the first things to do is ofcourse to set up the environment to be able to run such a load test. If that never happens, you already know very early in the project that you will be in trouble.
Having the load test done as many times as needed (at least once every sprint) you will know that the scale requirement is/can be handled by your architecture.
HtH
这将取决于许多其他因素，而不仅仅是每天的订单数量。它将在哪里举办？该物理架构是什么样的？除了电子商务之外，该应用程序还可以做什么？它是否需要与其他应用程序集成（当然除了支付网关之外）？等等。
在正确的云托管环境（例如 VMware）中，可以动态扩展的简单两层应用程序对于电子商务网站来说效果很好。正确的本地托管环境（负载平衡的网络场）中的简单两层应用程序也应该适用于电子商务网站。这就是纵向扩展（可能隐藏在虚拟化中，最终导致规模扩大）和横向扩展（添加更多服务器）之间的区别。
分布式架构允许您将系统负载（例如订单处理）分配给（可能）位于负载均衡器后面的 1:M 服务器。这是一种非常常见的方法，对于电子商务网站也非常有效。
在我看来，没有一种架构或系统设计适合每一种模式。适合每种模式的最接近的架构（再次，我的观点）将是面向服务的架构。如果所有业务流程和逻辑都是服务（并且设计正确），那么无论您的需求如何变化，无论您的托管环境是什么样子或发生变化，无论您有什么集成要求，您的系统都可以轻松处理它或没有变化。
It's going to depend on a lot of other factors than just the number of orders per day. Where will it be hosted? What does that physical architecture look like? What else does the application do besides ecommerce? Does it need to integrate with other applications (besides the payment gateways of course)? Etc.
A simple two tier application in the right cloud hosting environment (say VMware for instance) that can scale dynamically would work just fine for an ecommerce website. A simple two tier application in the right on-premises hosting environment (load balanced web farm) should also work fine for an ecommerce website. It's the difference between scaling up (potentially hidden with virtualization, which ends up being a scale out of sorts) and scaling out (adding more servers).
A distributed architecture would allow you to distribute the system load (say order processing) to 1:M servers that sit (perhaps) behind a load balancer. This is a very common approach, and would also work very well for an ecommerce website.
In my opinion, there isn't one architecture or system design that fits every mold. The closest architecture to fit every mold (again, my opinion) would be a service oriented architecture. If all business processes and logic are services (and designed correctly), then no matter how your requirements change, no matter what your hosting environment looks like or changes to, and no matter what integration requirements you have, your system can handle it with little or no changes.
由于您正在编写 .Net 代码，因此请将应用程序放入 Azure 中（da cLOUD man，DA CLOUD！；）。
它将帮助您获得所需的处理能力。只要您不犯任何愚蠢的错误，该应用程序就能正常运行。
Since you are coding .Net, put the application in Azure (da cLOUD man, DA CLOUD! ;).
It will help you get the processing power that you'll need. The application will work fin as long as you do not do any stupid mistakes.
通过负载平衡可以至少部分地解决扩展问题。
并发可能是您真正的问题。分布式事务是一个繁重的工具，但如果不经过额外的思考，它无法解决每个用例。
一些金融公司对直接访问数据库的 Web 服务器有额外的安全要求。
Scaling can be addressed, at least partially, with load balancing.
Concurrency might be your true problem. Distributed transactions is a heavy handed tool, but it won't solve every use case without additional thought.
Some financial companies have additional security requirements regarding the web servers having direct access to the database.