构建可扩展的应用程序VS只是云就绪应用程序

最近，我和一位被称为经验丰富的架构师的建筑师进行了讨论。讨论围绕着在Web Farm中运行的基于Web的多租户应用程序的理想架构和设计。该应用程序的唯一工作是允许用户上传系统正在处理的'n个'Excel文件，以生成非常复杂的报告。处理这些文件需要很长时间（每个文件一个小时，让我们把它作为一个约束）。因此，上传后的用户等待来自系统的通知下载生成的报告。构建可扩展的应用程序VS只是云就绪应用程序

乍一看这个需求看起来非常简单，但期望的是应用必须是100％可扩展的。我们与架构讨论了各种解决方案，但我们并不认为它令人满意。我需要这个社区的成员与技术一起提出设计解决方案。这不是我的专业任务，但它只是一项调查，旨在了解架构师对构建可扩展应用程序的看法，以及仅适用于云应用程序的应用程序，其中易于扩展基础架构而非关注应用程序可伸缩性。

来源

2013-05-02 iarchitect

是否都是独立于对方的excel处理？如果没有依赖关系，只要你像在云中一样不断扩展硬件，就会看起来像一个简单的问题。 – computinglife 2013-05-02 18:46:29

是的，所有的处理都是独立的，但挑战在于让应用程序可扩展，而不仅仅是抽取更多的h/w。我们应该考虑扩大规模作为最后的选择，直到我们达到应用程序无法进一步扩大的阶段。 – iarchitect 2013-05-08 13:07:06

那么你的问题应该改变为效率而不是可扩展性，因为你已经拥有了它。如果您将问题更改为针对Excel文档转换的特定问题，您将得到更好的答案。 – computinglife 2013-06-27 06:03:29

用户可以通过该网站上传excel文件。他们的凭证也通过了。后端将此请求注册到数据库中，并返回请求标识（Guid或其他）。该过程结束。

Windows服务正在运行并轮询数据库，寻找新的请求进行处理。你可以利用Quartz.NET来安排一些处理请求的并行作业。此请求处理（处理excel文件和生成报告）委派给负载均衡的WCF服务，因此您拥有的WCF服务越多，可以调度更多并行Quartz作业。如果处理了请求，可以安排另一种Quartz作业发送邮件。

该网站定期轮询以查看请求（或特定请求）的状态和进度;并管理它们。对于已完成报告的请求可以下载。

我认为这是一个非常可扩展的解决方案，也是松耦合的。

来源

2013-05-02 17:57:10

亲爱的L-Three谢谢你的建议。看起来可行和下降的解决方案，我们如何确保数据库操作的可扩展性？像选择，插入，更新大规模？所有这些服务是否同时访问数据库？它会不会太多的税收数据库？同样，我们如何确保来自客户端的这么多请求得到有效处理，例如解析数据库？ – iarchitect 2013-05-08 09:12:36

我认为数据库很少是瓶颈，但这取决于你当然想要做什么。例如，要处理并发读/写操作，请使用正确的锁定机制（如http://ludwigstuyck.wordpress.com/2013/02/28/concurrent-reading-and-writing-in-an-oracle-database/），对于批量插入，使用适当的技术（如http://ludwigstuyck.wordpress.com/2013/02/27/bulk-insert-into-an-oracle-database/）等等。所以尝试拿出具体的非首先是功能需求，然后进行技术设计。 – 2013-05-13 06:03:24

谢谢，我将其留待进一步评论。 – iarchitect 2013-05-17 11:01:35

构建可扩展的应用程序VS只是云就绪应用程序

回答

相关问题