.net 描述向SaaS模型的过渡

从一个独立的解决方案到另一个解决方案的有机增长过程是什么？明明

可伸缩性不是开发结束时附加的“特性”

所以我对所需的高级代码和架构更改感兴趣

• 有人会选择一个现有的平台并过度规范化它吗

• 是否从基本的云架构开始，然后迁移遗留功能

• 积极的技术升级（即web表单>MVC）是否适合该流程

更新： 我被要求对当前的项目架构进行一些澄清。不必太详细，可以考虑一个.NET webforms应用程序，它插入到一层业务逻辑中，并与多个第三方供应商集成。每当需要新的平台实例时（我这里没有术语，我的意思是当一个新客户需要业务逻辑调整、与不同的第三方提供商集成、新的热门品牌等），现有的代码就会被分支，并建立一个新的环境。任何更改实际上都是非常低级的，无论它们是否直接发生在aspx文件、组件代码或db配置中

这个场景似乎非常适合实现一个“合适的”SaaS模型，但我很难对迁移过程做出建设性的贡献。重新表述最初提出的问题，这将是一个有效的策略：

• 过度规范现有平台并使所有内容都可配置，有效地暂停了这种模拟的可伸缩性，并且在架构重构之前不会引入新客户机。这种imho的缺点是继续依赖于没有为可伸缩性而构建的代码和结构（详情如下）

• 从零开始，使用（主观上）被认为是未来解决方案的最佳体系结构，然后根据需要迁移遗留功能。这允许几乎任何期望的技术升级，但在完成之前缺乏可视性，并且作为一种积极的变更，管理层将视为固有的高风险

就我个人而言，我倾向于第二种选择，因为存在大量遗留代码，并且缺乏足够的数据库规范化。同时，现有的解决方案是成熟的和功能性的（如果它没有损坏，就不要修复它），除了上面列出的两种方法之外，可能还有更多的扩展方法

如果上面的上下文允许提供特定于场景的建议，我将接受它。然而，我仍然愿意接受更一般的做法和不做法，以及适合更广泛受众的建议

I'm interested in high level code and architecture changes required.

不幸的是，对于如何改变您的体系结构，没有“正确”的答案。解决方案取决于您当前的体系结构，以及您作为开发人员的能力和偏好。一些独立系统可能已经有了一个相对可扩展的平台，而另一些可能需要在开始获得吸引力时进行改进，而另一些可能需要从头开始，因为它们的代码库无法使用

坚实的代码基础非常重要。如果没有一个高效、干净的代码库，您的体系结构就不可能实现理想的扩展。许多公司犯下了在创可贴之后搭起创可贴来解决短期问题的错误——但从长远来看，这种做法永远不会奏效。当某些东西不能正常工作时，花时间以最合理的方式修复它——即使这意味着调整平台中的其他代码

最好的方法是为您提供构建可伸缩系统的一般建议，即使用缓存、将系统设计为水平伸缩、优化数据库、确保在适当的情况下使用db索引。一些最佳实践依赖于体系结构，但几乎每个可扩展平台都需要遵循一些一般原则。 对于良好的可伸缩性技术和设计模式的深入报道，我想看看

至于选择平台，这完全取决于您和您作为开发人员的偏好。你喜欢用什么编码？C#，Ruby，PHP？遵循团队一致同意的语言和平台。我更喜欢RubyonRails，我喜欢MVC设计模式，但这并不意味着它是适合您的最佳解决方案。选择对您最有意义的，并与之合作开发一个可扩展的系统

---

在过去，当我在需要高可伸缩性的系统上工作时，我经常会发现需要从头开始。不幸的是，并不是每个人都有远见去了解他们所需要的所有最佳实践和特性，而且这往往会导致数据库和平台设计不够理想。开发一个系统的过程可以让我们深入了解真正需要什么以及该系统的最佳方法。因此，在过去的几次中，我已经完成了一个产品的一半，并且意识到需要一个新的代码库，因此我重新开始并迁移我认为适合新设计的任何遗留代码。

过程基本上是创建一个客户机/服务器接口（在基于web的SAAS情况下为http）基于与您的数据交互

如果您可以直接访问服务器中的数据，则可以将软件解决方案的全部或大部分迁移到基于web的平台，如asp.net、php、ruby+rails、python+django或其他。在这个替代方案中，您可以通过多种方式传递数据：JSON、oData、文本、embbed-In-code（对象或数组）等。有非常聪明的解决方案可以解决这个问题。通常涉及AJAX和无处不在的XMLHTTPRequest

如果在极端情况下，您甚至没有您试图使用的软件的代码，那么想象一下某个COBOL或类似的解决方案，您只有可执行文件。。。即使在这种极端情况下