SaaS 架构设计的参考指南 _SaaS

文章插图

为什么需要 SaaS？软件即服务（SaaS）是一种灵活的软件分发模型，可以由少到一个人或多至上千人的组织来运作。云服务的问世让任何人都可以独立运行自己的 SaaS，并在此基础上建立免费增值模式的业务。
与其他类型的软件服务相比，它的系统设计相对简单。但是，由于没有合适的基准架构，如果我们在设计 SaaS 时没有认真思考，其结果可能会变得一团糟。我见过的一些例子中，SaaS 平台最终成为一个庞大却脆弱的单体 Web 应用程序，其中遍布冗杂的功能。
本文的目的是为你提供一种参考架构，为 SaaS 实现可伸缩性和可维护性。
SaaS 平台的需求产品需求

用户和用户组的访问控制。
向用户和组织提供订阅层，其中每种订阅类型都可以访问一组产品。
托管内部管理工具的能力。
可扩展的功能。我们应该能轻松添加新的产品和功能集。

设计目标

隔离的服务带来清晰的责任归属与关注点分离。
减小任何更改的影响半径，比如说分析仪表板中的错误不应该影响管理仪表板。
隔离运行 Web 应用程序。每个 Web 应用程序都提供一组相关的功能来服务我们的客户。在大型公司中，每个 Web 应用程序都可以有自己的专门团队来构建和运行。

解决方案：隔离和重用将服务隔离到逻辑组件中的设计可以让我们的 SaaS 有更好的可扩展性。我们应该针对我们的架构作出改进，在规模扩展时打破常规：规模越大，架构却变得越容易管理。就算只有一位孤独的车间开发人员，他也可以很容易运行并管理多个服务，尤其是现在我们已经拥有了各种各样可以编排微服务的云服务，这种事情做起来就更简单了。
因为计划在 SaaS 平台上运行这些功能 Web 应用（feature Web App），所以我们应该先思考“我们可以重用什么？”这个问题。
隔离隔离的 Web 应用程序是将相关功能分组在一起形成的一个 Web 应用程序，或是代表一款产品的一组 Web 应用程序。具体而言，我将其称为“产品 Web 应用”，后文将做更进一步的介绍。
在 Web 应用程序中分组相关功能例如，所有 " 分析报告功能 " 都可以组合在一起，成为一个独立的 Web 应用程序，该应用将由一个专门的团队来构建和维护，且这个团队在构建分析报告产品方面具有相关的领域知识。在大型公司中，每个产品 Web 应用都有自己专门的团队来构建和运行。
内部与公共（可选）【SaaS 架构设计的参考指南】你的产品 Web 应用也可以分为两个部分：内部和公共部分。内部和公共部分之间明确区分开来后，你就能在自己的专用网络内路由一组专用的安全管理工具。
在内部和公共区域代理这些服务的工作由 " 路由服务 " 处理，具体将在后面的章节中介绍。
重用这些是不同的功能 Web 应用及其相应服务共享的通用功能。每种功能 Web 应用都需要利用下面列出的这些功能。

文章插图

组件下面这些是构成我们 SaaS 的逻辑组件。
路由服务每个请求都需要路由到正确页面。当用户访问 yourWebsite.com/your-path 时，/your-path 需要将用户转发到其关联的请求页面或功能 Web 应用。路由服务可确保用户得到他们所请求的内容。

文章插图

在本文的例子中，我们将需要路由服务（routing service）调用另一个服务以获取路径和 Web 应用程序 URL 映射，以及所需权限。
这些映射预计将在运行时更新。例如，在需要引入新页面或更改用户权限而无需发布的情况下更新。
路由服务还负责内部或公共的产品 Web 应用。可以将其部署到两个单独的运行实例中。

文章插图
公共和私有路由服务设置的高级设计
实现技巧：Node.js 的 http-proxy-middleware 或 Nginx 的 Reverseproxy 是两个可行的选择。如果你不需要在运行时从其他服务中以编程方式检索路径、URL 和权限，则后者是理想的选择。有关更多信息，请参见后文的 "Web 应用仓库 " 章节。
产品 Web 应用每个产品 Web 应用都通过一个可在内部访问的 URL 公开，例如 https://my-product-app-1.mydomain.local 。其中一些由路由服务路由，以供订阅的用户访问，而另一些仍在内部访问。