构建一个软件即服务（SaaS）应用程序是很难的，而且有比以往更多的选择。在这篇文章中，我将讨论一个名义上的现代架构。

当然，没有一个放之四海而皆准的架构。这种特定的设置适用于很多用例，但它肯定不会适用于其他用例。此外，如果你了解这些技术，它就能很好地工作，但如果你想快速将最小可行产品（MVP）推向市场，并且更愿意写一个单片机，那么尽可以这样做。我最不建议的是陷入学习新技术的泥潭，因为你完全有能力用你已经知道的技术来完成一个MVP。

一些基线要求

在我们进入架构的杂草之前，让我们谈谈一些基线要求。

我们的SaaS将需要以下东西。

• 一个带有营销材料的面向公众的网站。
• 博客文章以吸引搜索流量。
• 一个私人的网络应用程序，在客户注册后提供核心SaaS服务。这个网络应用可能需要在某个地方存储文本数据和媒体。

对架构的思考

在制定应用架构时，我喜欢问自己几个重要的问题。

我如何构建这个应用程序，以便为每个需求选择最佳技术？

这是一个大问题，在我看来，模块化的架构才是真正的亮点。例如，一个好的博客平台很可能不是一个好的核心应用平台。那么，我们是否可以选择一种架构，让一个强大的博客工具做博客部分，让一个强大的网络应用程序工具做网络应用程序部分？

我怎样才能确保应用程序能够扩展（在所有正确的地方）？

你的核心应用可能需要也可能不需要扩展。你的博客可能需要也可能不需要扩展。或者一个可能需要扩展，另一个可能不需要。不管是什么需求，你都应该试着定位自己，只扩展你的应用程序中需要扩展的部分，而不是为了满足某一部分的需求而被迫扩展整个单体，浪费金钱。

我怎样才能将应用程序划分开来，使专家们能够在各自的部分上孤立地工作？

为面向公众的应用程序创建博客文章和编写文案的营销人员可能不应该在SaaS应用程序的代码库中混战。更进一步说，你可能不想强迫后端工程师编写前端代码，反之亦然。

如果你是一个人的商店，这种考虑可能不那么重要，但从长远来看，像这样分离关注点可能会导致更好的关注点分离和更好的维护性。

我怎样才能使所有不同的部分保持同步？

虽然保持你的应用程序的所有不同部分单独运作是最理想的，但有时你将不可避免地需要协调面向公众的应用程序和Web应用程序的部署。我们怎样才能让应用程序的一堆不同部分隔离而又同步？

建议的架构

好吧，让我们来谈谈细节。除非有什么特殊的要求让我不这么想，否则我可能会对应用程序进行如下架构。

• 一个静态网站生成器，用于面向公众的网站和博客。
• 一个用于SaaS网络应用前端的单页应用程序。
• 为SaaS网络应用的后端提供API服务器。
• 为应用程序的数据提供云托管的数据库。根据需要，采用SQL或NoSQL。
• 为你的媒体提供基于云的对象存储。
• 一个monorepo，将这些不同组件的代码放在一起。

我为每个部分选择的具体技术如下，并在很大程度上受到我所拥有的经验的影响。

组件	架构选择	技术选择
面向公众的网站和博客	静态网站生成器	Gatsby托管在Netlify上
SaaS前端	单页应用程序	托管于Netlify的React
SaaS后端	API	托管在Heroku上的Node
文本数据存储	SQL或NoSQL数据库	托管在Heroku上的Postgres或MongoDB
媒体存储	云对象存储	亚马逊S3桶

现在再深入了解一下我为什么喜欢这些选择吧!

在面向公众的网站和博客中使用静态网站生成器

静态网站生成器（SSG）已经成为一个很好的选择，嗯，生成静态网站。作为一个开发者，你对网站的外观和感觉有很好的控制，但你可以使用额外的工具，如Contentful，为博客内容制作者提供一个方便的用户界面来创建和安排内容发布。

SSG通常有社区构建的（或官方）组件，以帮助实现出色的SEO。许多人的速度快得惊人，在Google Lighthouse上得分很高。

当你把你的SSG和Netlify这样的服务结合起来时，部署就像把你的代码推送到Github一样容易。Netlify会从存储库中提取你的代码，建立静态应用，并为你部署它。Netlify用他们自己的内容交付网络（CDN）处理内容交付，你一般不用担心流量大的问题。

我特别选择Gatsby作为SSG，只是因为我对它有很多经验（你现在看到的是Gatsby博客）。还有很多其他伟大的SSG!

在SaaS前端使用单页应用程序

单页应用程序（SPA）已经成为Web应用程序的标准。在这一点上，人们的期望是拥有一个非常流畅的体验，并将页面重载降到最低。SPA还有助于将你的视图层与你的后端隔离。出于与静态网站相同的许多原因，我建议使用像Netlify这样的即插即用的服务来托管SPA。

我会选择React作为我的前端，因为我对它有很多经验。同样，也有很多不是React的好选择。

一个基于API的后端

鉴于你已经选择了一个SPA前端，这就是你剩下的东西了。你可以很容易地在Heroku等地方托管一个API服务。API层将从你的前端接收请求，采取必要的行动，并将数据返回给前端。

将你的应用程序分成前端和API的一个好处是，如果这是SaaS模型的一部分，你可以很容易地为你的消费者提供API服务。

我可能会选择Node作为我的后端，因为我有很多JavaScript经验，但我也可以很容易地看到选择其他服务器技术。

**注：**也许值得关注 "无服务器功能"，作为单体API层的替代。与其担心服务，无服务器函数让你只需为API端点编写处理函数，而无服务器函数提供商（如亚马逊、Netlify等）则负责确保有服务器为其服务。

SQL或NoSQL数据库

这里可能没有什么太大争议：选择一个SQL数据库来处理表格数据，或者选择NoSQL来处理文档数据。可能会加入像Redis这样的东西进行缓存。假设我使用Heroku作为应用程序的后端，那么将其用于数据层也是一个合理的选择，因为我不喜欢管理大量不同的账户。

云对象存储

如果你要存储任何非文本数据，如图片或视频，Amazon S3桶似乎是一个非常可靠、安全和快速的选择。亚马逊为大多数后端堆栈提供了足够简单的软件开发工具包。

使用单一存储库

你不使用单片机并不意味着你不能把所有的代码托管在一起。我非常喜欢单库，因为你可以为你的应用程序的不同部分提供单独的服务，但更容易保持同步--你可以确保在你的API准备好接受新字段的同时，在面向公众的应用程序中对注册表的改变也被发布。

这一切是如何结合在一起的

下面的架构让你了解到我们的概念堆栈是如何结合在一起的。

用户进入面向公众的应用程序，并可能浏览博客。他们可能会选择注册或登录（我可能会把这些页面放在面向公众的网站上）。一旦登录，他们就会被送到单页应用程序。在那里，所有的请求都被发送到API，它在数据库和对象存储上执行任何数据操作，以及与第三方API（例如，一个认证提供者）集成。

总结

我希望你能喜欢这个快速游览的名义上的SaaS应用设计。当然，创建一个SaaS架构来统治它们是绝对不可能的，但我希望这能让你在考虑你的系统的特殊性时朝着正确的方向前进。