许多人的头脑中都有可能吸引数百万人的在线创业公司，但大多数时候，您的预算（时间和资源）很少，因此您希望在一年内交付。发布后不久，您必须执行一个或一系列升级，其中可能包括：将代码重构到更新的基础、在软件架构中添加层次结构或重构数据库。此升级/重构周期继续如下：
以上述为先决条件，我想认真对待这个讨论并确定 Web 应用程序可升级解决方案的本质。在讨论中，您可以谈论开发的任何阶段（初始、早期升级、增量升级）并涵盖以下一项或多项：
【问题讨论】：
标签： performance architecture web-applications scalability
您会发现 RDBMS 技术不易扩展。所有供应商都会告诉您否则，当您尝试多台服务器并进行负载平衡时，就会出现固有的限制。其他一切都可以用“更大的铁”来加强，并且可能是更高效的代码，但数据库不能轻易拆分和分发。
Web 应用程序有望推动数据库技术的创新，并帮助我们摆脱陈旧的关系模型思维定势。早就该来了。
我建议从一开始就非常关注这个薄弱环节。
【讨论】：
我们公司的网络解决方案已进入第四代主要，在过去 8 年中取得了长足的发展。最新一代引入了各种各样的结构来帮助完成这项任务，因为根据新的客户需求更新上一代变得笨拙。因此，我在 2009 年花了很多时间思考这个问题。
您能做的最有价值的事情就是采用敏捷方法来构建软件。特别是，您应该维护一个可以（并且正在）每天创建新构建的环境。虽然每日构建只是敏捷的一个方面，但这是解决问题最重要的实践。虽然这与可升级性本身不同，但它在流程中引入了一个规则，有助于减少您的代码库变得笨拙（或者您将成为Architect Astronaut）的可能性。
就框架和语言而言，有两个主要要求：框架寿命长且稳定，环境支持Separation of Concerns。 ASP.NET 在这方面对我来说效果很好：它以合理的方式发展，没有使旧代码失效的不连续性。我使用单独的业务逻辑层来管理 SoC，但 ASP.NET 现在也支持 MVC 开发。相比之下，在使用 PHP 几个月后，我开始不喜欢它，因为它似乎鼓励了会危及未来升级的混乱做法。
关于DBMS 选择，任何现代 RDMS（SQL Server、MySQL、Oracle）都能很好地为您服务。不过关键在于：您将需要维护 DDL 脚本来管理升级。这只是生活中的事实。那么，您如何使这个过程变得易于处理？任何第三方开发人员提供的最有价值的工具是我从 Red Gate 获得的 SQL Compare 副本。在我找到这个工具之前，这个过程曾经是一场彻头彻尾的噩梦，严重拖累了我改进代码的能力。因此，一般建议是使用存在工具的数据库来比较数据库结构。 SQL Server 在这方面非常幸运。
硬件几乎是无关紧要的。只要您的开发过程包含合理的发布构建过程，您就可以随时迁移到新硬件。
需求不断变化的策略。 再次参见敏捷。我鼓励您不要再将它们视为“要求”——传统意义上的充满规范的大型文档。敏捷以重要的方式改变了这一点。我也不保留需求文档，除非在为外部付费客户工作时，这样我可以确保适当的计费并防止功能蔓延。在这一点上，我们的内部流程是如此快速和流畅，以至于我们的功能请求/错误管理软件（如果您想知道的话，是 FogBugz）的报告在记录新的营销版本时用作我们的文档。
全面重新设计的策略/决定是：不要。如果您对将要使用的流程进行合理的考虑，选择主流工具并强制执行关注点分离，那么除了完全放弃 HTTP 和 RDBMS 之外，没有什么会导致彻底重新设计.
如果您足够敏捷，任何事情都可以改变，那么您就不太可能处于所有事情必须改变的位置.
【讨论】：
为了让事情顺利进行，我认为支持依赖注入（或如今似乎被称为控制反转）概念的语言/框架会在列表中名列前茅。
【讨论】：