大型电子商务网站拓扑和部署指南

Question

问题

我是一个被高度贩卖的eCommerce网站的首席工程师(每小时超过100万页的浏览量)。由于各种原因，我们有机会重建我们的大部分基础设施。这就引出了在平衡灵活性、稳定性、市场速度等方面存在的一些有趣的问题。在高层次上，我感兴趣的是其他人是如何处理类似情况的。特别是，我想知道其他人是如何设计他们的站点的，以便在快速移动的环境中提供稳定的部署。

• 其中一个主要的权衡，我看到是打破我们的网站的功能领域，并提供他们各自的子域。这方面的主要驱动因素是我们在Azure上托管，而部署则是全部或完全没有。
• 我还感兴趣的是，其他人是如何在快速变化的环境和由不同经验级别组成的团队中维护体系结构完整性的。

技术

我们主要是一个微软商店: Server，Windows 2008，.Net 4.0，Visual 10等等。

我们还决定在Azure平台上托管我们的主站点，并大量使用表和blob存储以及app fabric缓存。我们正在考虑使用多个Azure数据中心，但到目前为止还没有做出最终决定。

所有静态内容，包括JavaScript和CSS将被缩小，并托管在我们的CDN上。

我们的站点是使用.Net MVC 3构建的，并受到DDD风格体系结构的支持。我们的数据访问库和业务规则封装得相当好，并且与实际的显示逻辑分离。

过程

虽然不是一个真正的敏捷商店，我们很快迭代频繁的部署，多元测试，及时的要求，等等.我们通常很有企业家精神，有必要在新机会出现时迅速作出反应。(代码为“它可以变得混乱”)

Team

我们的开发团队由几十名具有不同技能和经验的开发人员组成。虽然一些开发人员可以独立操作，但其他开发人员需要进行非常仔细的代码检查。

QA团队有一个非常彻底的手工评审过程。他们还开始构建一套QTP测试来自动化回归测试。而开发团队则在适当的时候使用单元测试和BDD测试。

不考虑

我知道有很多强烈的意见，所以为了防止宗教战争，这里有几个对我没有帮助的回应。

• 只需使用Java，Oracle，PHP，Ruby等.
• 只需使用EC2
• 只需要让你的开发人员更加小心
• 告诉您的开发人员要更快地编写代码。
• 只要告诉“生意”放慢脚步
• 只需使用

，我在找

的反馈

我知道有许多工程师，虽然非常熟练，但从未在支持数百名并发用户的系统上工作过。从一个支持30,000名并发用户的站点中获得的经验教训与一个内部支持应用程序的经验非常不同(顺便说一句，我在这两个方面都做过工作，并不是贬低内部应用程序)。它们只是需要一种不同的方法)。

如果你有类似情况的经验，我很想听听你是如何处理问题的，以及你的解决方案的退路在哪里。

Answer 1

我想知道其他人如何设计他们的站点，以便在快速移动的环境中提供稳定的部署。

我们有: 1)标准的3层体系结构，DB (My )，业务层(Java，Struts )，表示层(Java，Html，Javascript，Css)

2) 1主DB服务器+故障转移DB服务器

3) 3台具有负载平衡的we服务器(站点速度快，虽然我们每小时只有250 k的点击量)。我们可以在2上过活，但我们想为什么不让故障转移服务器做一些工作，而不是只是闲置着)

4)电子商务站点处理与客户端的所有交互，并且只保存必要的数据。在ERP系统中，所有的管理、订单处理、付款处理都在本地进行。定期从网站下载订单数据。

5)所有项目级数据均在企业资源规划系统内保存，并定期发布给电子商务数据库。(除其他外，在数量方面也有一些出入)

6)在部署时，我们发布整个代码库。它很小，我想不到10毫巴。我们运行DB mod脚本。它需要较少的5分钟的停机时间，我们这样做时，使用率很低(凌晨2点左右)。

一个主要的权衡，我正在看是打破我们的网站按功能领域，并提供他们各自的子域。这方面的主要驱动因素是我们在Azure上托管，而部署则是全部或完全没有。

我认为这是一个错误，它影响用户体验，因此应该基于业务原因，而不是技术原因。

我还感兴趣的是，其他人是如何在快速变化的环境和由不同经验级别组成的团队中维护体系结构完整性的。

我们有一个关键的架构职位，他和我一样，从一个很高的层次上了解enter系统架构。我们做出所有主要的架构决策，并批准任何Db结构修改。我们扮演中央控制角色。