从独立解决方案到Software as a Service的有机增长过程是什么？清楚地
可伸缩性不是＆＃34;功能＆＃34;在发展的最后加上^
所以我对所需的高级代码和架构更改感兴趣。
是否选择现有平台并使其超常化？
是否重新开始使用裸骨架构，然后迁移旧版功能？
积极的技术升级（即网络表格＆gt; MVC）是否适合这个过程？
我被要求对当前的项目架构进行一些澄清。不需要太多细节，可以考虑一个.NET webforms应用程序，它可以插入一层业务逻辑并与多个第三方供应商集成。每当需要新的平台实例时（我在这里缺少术语，我的意思是当新客户需要业务逻辑调整，与不同的第三方提供商集成，热门的新品牌等等。），现有代码是分支的，并建立了一个新的环境。任何更改实际上都是非常低级的，无论它们是否直接发生在aspx文件，组件代码或db配置中。
这种情况似乎非常适合拥有适当的＆＃34;实施了SaaS模型，但我在构建性地为迁移过程做出贡献方面存在困难。要重新解释所提出的原始问题，这将是一个有效的策略：
对现有平台进行Overnormalize并使所有内容都可配置，有效地暂停此模拟可伸缩性，并且在重构体系结构之前不会引入新客户端。这个imho的缺点是继续依赖不是为可扩展性而构建的代码和结构（详情如下）。
从头开始，使用任何被认为是（最终）最佳架构的解决方案，然后根据需要迁移旧版功能。这允许几乎任何所需的技术升级，但在完成之前缺乏可见性，并且作为一种积极的变化，管理层将被视为固有的高风险。
我个人倾向于第二种选择，因为存在遗留代码的数量和缺乏足够的数据库规范化。与此同时，现有的解决方案已经成熟并且功能齐全（如果它没有被破坏，不能解决它）除了这两种方法之外，还有更多的方法可以扩展我已在上面列出。
如果上面的上下文允许针对特定情景的建议，我会接受它。然而，我仍然对更适合更广泛受众的更一般的做法和指针开放。
答案 0 :(得分：4)
关键是架构。方法是分而治之。方法是放松。
建筑最重要的组成部分是它的架构。空间的形状有墙壁和地板，窗户和天花板，即建筑本身的元素。建筑师的目标不是设计墙壁。他将它们设计为实际工作的次要部分：设计由墙壁塑造的空间。我们不建造有墙的建筑物，我们建造它们以便有空间。
我们首先设计的功能是我们想要的软件功能。然后我们详细介绍了如何使其成为可能，即构建产品。我们使用的技术不是主要的，它们是墙壁，我们真正想要的是空间本身。
通过对我们正在构建的软件的理解，工程变得更容易，几乎是自动化的过程。技术难题开始出现，理解清晰，幸运的是，显而易见的解决方案。
良好架构的一个非常重要的衡量标准是它使解决方案的组件明确定义。当我们可以分别看到大图的这些组成部分时，我们可以将工作分成不同的部分。然后我们可以构建单独的东西来协同工作。
也许这个标题听起来像我试图给文字带来一些幽默;但不，请不要误解我的意思。如果您拥有良好的架构，您可以放松，您的Web服务器，数据库服务器，工程师，客户，用户以及世界其他地方也可以放松。如果不是这种情况，则意味着您应该重新开始构建您的架构。
好的，我会试试;但首先，让我们放松一下......然后我们可以看看一些真实的例子。
我们说我们正在为专业人士和个人开发网络出版服务。每个客户都有自己的网站，在我们的系统上运行。这些网站可以是访问量极低的普通个人网站，如果我们的业务运气好，我们的其他一些客户也可以成为纽约时报等大型出版物。
我们需要解决两种可扩展性问题：随着我们开始拥有越来越多的客户端，运行越来越多的网站，扩展我们的业务，我们的系统。与第二个网站相比，这是一个非常简单的问题，因为它吸引了越来越多的访问者，越来越多的数据，越来越多的应用程序在这些数据上运行。
我们可以重写＆＃34;如何扩展＆＃34; as＆＃34;如何划分＆＃34;更清楚地看到解决方案。如果我们可以将某些东西分成小块，我们可以通过添加更多资源来扩展它，从而横向增长。
我们将拥有可用于该数据的数据和应用程序。假设我们有一个数据库服务器和一个Web服务器，并尝试使其可扩展。
考虑我们将为我们的服务运行的Web服务器;如果我们不在这些机器上保存数据，它们将变成通用的，相同的组件，数据后端的小客户端，将这些数据连接到世界其他地方。通过使我们的Web服务器保持轻盈，愚蠢，空白，我们可以轻松地使其中许多服务器处理越来越多的请求。
好的，将Web服务器变成愚蠢的代理并不是最聪明的想法。我们需要做的事情，要运行的应用程序。而且，因为在我们的架构中，Web服务器是最容易繁殖的，我们希望在这些Web服务器上尽可能多地执行操作。我们将继续解决这个困难问题。标题如下。在此之前，让我们看看我们目前在桌面上有什么样的架构以及可扩展的方式。
我们使用负载均衡器使许多Web服务器并行运行，并使用DNS（甚至在请求到达我们的系统之前）将多个网站划分为多个负载均衡器。例如，a.com，b.com，c.com负载均衡器1，a-very-big-website.com负载均衡器2，...每组负载均衡器，一组Web服务器和一个数据库服务器在我们的系统中创建一个单独的 Universe 。现在我们可以拥有数百万个网站，并通过添加更多这些单独的Universe来扩展我们的系统，而不受任何限制。我们的营销部门可以为尽可能多的网站提供服务。我们的第一个问题已经解决了。如何运行大型大型网站？
当然，我们不能像使用单独的网站那样将单个网站划分为单独的网站;但这并不意味着我们根本无法分割任何东西。我们将继续分裂和征服。为此，我们需要仔细研究我们解决的问题。
什么是网站？网页，支持css和js文件等内容，图像和视频文件等多媒体内容，以及大量数据。由于CDN和云计算系统提供的强大存储服务，静态文件不再是我们问题的重要部分......
我们真正做的是渲染网页。上面，我们认为我们的Web服务器是我们数据库后端的非常轻便的通用接口。我们还没有解决如何在我们的Universe中运行应用程序。现在是时候这样做了。
我们系统的每个请求都将来到一个站点，并由运行该站点的应用程序处理。我们的Web服务器首先要做的是确定请求属于哪个站点。在我们的数据库服务器上，我们保留一个将主机名与站点匹配的表。对于我们拥有的每个新客户网站，我们将在此表中添加一个或多个域以匹配此站点。对于我们的Web服务器的每个请求，我们将查询数据库服务器并确定要加载的站点。好？
不，不好。太糟糕了。为什么呢？
我们有少量网站;但是有很多请求。与其他类型的数据（如博客网站上的评论）相比，Universe上的网站数量变化的频率要低得多。此表在已建立的Universe上每天更新几次。每天一次又一次地为每个请求查询这么小的（几千个记录，小！）数据库并不聪明。执行此操作的明智方法是将此表的副本保留在Web服务器上，并仅在更新时进行更新。我们如何知道网站列表何时更新？我们可以使用数字作为表格版本号来保留一行。每次更新我们都可以增加这个数字。或者我们可以保留上次更新的时间戳。 Web服务器可以检查数据库服务器以获取此数字，并将其与其本地内存中版本进行比较。如果table更新，我们再次拉取数据覆盖本地内存中的副本。这样，我们就可以将数千个查询减少到很少的数量。大数字，小数字......
此时，我们在建筑物上使用的材料开始变得重要。哪种语言，什么样的平台和数据库系统等等。现在，它们很重要，因为它们可以使我们的架构更好或更差。例如，对于表的更新，我们的数据库服务器可以具有向Web服务器通知更新的机制。这样，我们将进一步完全删除域网站表的不必要的查询。因此，如果我们选择的系统提供这样的机制，则意味着这些系统是我们架构的良好选择。
当我们从我们的软件中理解我们想要的东西时，会以智能的方式自动划分。扩展数据库服务器非常困难。因为我们需要数据在一起。通过增加Web服务器的数量，我们可以水平扩展而不受任何限制;但对于数据库服务器，这不适用。数据库服务器必须保持对数据的访问，并且机器具有我们无法以有效方式扩展的限制。
每个数据库系统都提供了像分片或无共享架构一样的扩展方法。有一段时间你必须使用这些;但正如我在论坛，博客和其他地方看到人们分享他们的经历，恕我直言，人们使用这些过于激进和错误。他们让他们的数据库变得越来越大，然后就是缩放，让我们添加一些分片。＆＃34;所有这些应用程序中有99％是盲目运行的。人们将他们的问题抛给软件，并期望他们像魔术一样得到解决。不幸的是，他们很快意识到没有魔力。
我们应该通过观察我们的数字来避免盲目运行的解决方案：大数字，小数字。同时了解我们系统的内部工作原理，通过架构解决问题，而不是大量使用材料。
以下是架构解决方案：Architected Solution（Calatrava）。
以下是依赖于材料而非良好架构的其他解决方案： [Blind-run Solution 1]，[Blind-run Solution 2]
自己判断差异。
我们如何扩展数据库服务器？我们可以重新考虑我们的数据，而不是盲目地在中间划分表格。我们可以将用户帐户信息与网站模板分开吗？当然，为什么不？我们可以为旧数据和新数据保留不同的数据库服务器吗？更难一点，特别是考虑到搜索设施;但为什么不呢？
聪明地分开，而不是盲目地分开！我接受有时候你不能分开它了;但接下来，我们有多少人在为Google或Facebook工作？
- 嘿，伙计，我们有一个非常大的数据集，当我们运行时...
- 嘘。首先，返回并检查您的数据集。它真的必须一个大型数据集吗？
大多数时候，不，它没有。我们只是不想承认......
从头开始重建一切需要很多企业负担不起的时间。更好的方法是构建我们当前的系统而不重写每个组件;但相反，将它们分离并重新定义为组件。这主要是分析后几乎没有变化。系统上的每个函数调用都可以很容易地成为一个分裂点。我们可以将系统从那一点切割成两部分。
只需几个小时，您对当前系统的快乐表现将向您展示如何划分这些部分的许多想法。一旦你划分它们，很容易重新构建一切，然后逐个重新构建你的新系统。如果我有一座建筑物，我需要在同一块土地上建一座更大的建筑物，那么建造新建筑物的同时又不会让所有已经居住在那里的人们感到非常困难。但并非不可能。说到软件而不是建筑物，它就容易多了。所以？
是软件。它很柔软。您可以复制数据，对其进行测试，删除所有内容，复制数百万次。一旦您的架构设计得很好，您的错误就不会导致灾难性事件。将6人餐桌变成可容纳60位客人的餐桌非常困难;但软件是...... 软件，我们可以轻松地做这些事情。 放松。
- 上面的问题涉及这样一个区域，仅在几个段落中无法涵盖。基于以下问题的这一部分：＆＃34;然而，我仍然对更适合更广泛受众的更一般的做法和指针开放。＆＃34;我试图以一般格式提及事物而不深入细节。虽然我试图给出一些我的原则的实际应用的小例子，但我知道我在这篇简短的文本中留下了许多开放的目标。我很感激评论中的任何批评和问题。
答案 1 :(得分：3)
I'm interested in high level code and architecture changes required.
不幸的是，对于如何改变您的架构没有“正确”的答案。解决方案取决于您当前的架构是什么样的，以及您作为开发人员的能力和偏好。一些独立系统可能已经具有相对可扩展的平台，而其他可能需要在它们开始获得牵引力时进行改进，而其他系统可能需要从头开始，因为它们的代码库不可用。
坚实的代码库非常重要。如果没有高效和干净的代码库，您的架构不太可能无法扩展。许多公司犯了一个错误，就是在创可贴之后使用创可贴来解决短期问题 - 但从长远来看，这种做法从来都不是很好。当某些东西不能正常工作时，请花时间以最合理的方式修复它 - 即使这意味着调整平台中的其他代码。
最好的办法是为您提供构建可扩展系统的一般建议，即使用缓存，设计系统以横向扩展，优化数据库，确保在适当的地方使用db索引。一些最佳实践依赖于体系结构，但是一些通用原则，几乎每个可伸缩平台都需要遵循这些原则。 为了深入了解良好的可伸缩性技术和设计模式，我会查看Scalability Rules: 50 Principles For Scaling Websites。
就选择平台而言，这完全取决于您和您作为开发人员的偏好。您喜欢编码什么？ C＃，Ruby，PHP？使用您的团队同意的语言和平台。我更喜欢Ruby on Rails并且我喜欢MVC设计模式，但这并不意味着它是最适合您的解决方案。选择对你最有意义的东西，并与之合作开发可扩展的系统。
过去，当我处理需要高可扩展性的系统时，我常常发现需要从头开始。不幸的是，并不是每个人都有先见之明来了解他们需要的所有最佳实践和功能，而且往往导致数据库和平台设计不够理想。开发系统的过程可以让您深入了解真正需要什么以及该系统的最佳方法。因此，过去曾经有过几次我在产品中途，并意识到需要一个新的代码库，所以我重新开始并迁移我认为适合新设计的任何遗留代码。
答案 2 :(得分：1)
我的情况有所不同，但可以是从桌面直接过渡到saas的一种模式。我公司做媒体监控。最近，我们发现媒体不再是电视和广播，并且已经开始从“可能的网络”中捕获所有流。为了给我们的客户提供解决方案 - 他们需要ARCHIVES而非RECORDERS - 我们只需在我们的服务器上为他们提供托管解决方案。
这使我们能够将所有内容集中在一起，并直接在“云总部”维护代码库。
还有更多内容，但我不会厌烦读者，只会指出我们没有强迫自己 - 它真的是有机的，完全正常。
我们解决方案的体系结构遵循一个重要前提：添加到系统的每个硬件节点都将被完全利用，从网络到存储再到CPU。每个软件都被写成'任务服务器'＆lt; - ＆gt; “代理人”分开运作。因此，您可以随时购买更多机器并运行您需要的任何东西。
答案 3 :(得分：1)
读一读： http://static.usenix.org/event/lisa07/tech/full_papers/hamilton/hamilton_html/index.html
这为构建可扩展系统提供了很好的概述。从硬件/软件的角度来看，从服务器的角度来看都是人工扩展工程师。
这本书（或点燃书）The Lean Startup (Eric Ries)也有一些很好的指示。
答案 4 :(得分：0)
这些流程基本上是基于与您的数据交互而创建一个客户端/服务器接口（基于Web的SAAS案例中的http）...
如果您可以直接访问服务器中的数据，则可以将全部或大部分软件解决方案迁移到基于Web的平台，如asp.net，php，ruby + rails，python + django或其他。在这种替代方案中，您可以通过多种方式传递数据：JSON，oData，Text，嵌入代码（对象或数组）等。有非常聪明的解决方案可以解决这些问题。通常涉及AJAX和无处不在的XMLHTTPRequest。
如果你甚至没有尝试使用的软件代码的极端情况，想象一下你只有可执行文件的一些COBOL或类似解决方案......即使在这种极端情况下你也可以创建一个Broker从您的程序的屏幕上读取（自动 - 它可以做到），将该数据传递到您的Web界面，将其呈现在客户端端点，从您的Web程序获取结果并将其注入可执行界面（auto - 再次或其他一些宏控制库）。
您不需要MVC / MVVC / RAILS / DJANGO或其他，但如果您在将操作与数据分离并控制Web程序流程方面没有一定程度的经验，它们可以使您的生活更轻松。< / p>