【SaaS架构】构建 SaaS 产品所需的技术——第一部分

你有一个新软件产品的想法，你已经完成了你的研究，创建了一个受众并承诺每个人都会解决这个问题。在下文中，我将为您提供一个经过验证的清单和构建 SaaS 的最佳实践。

如今，我们有无数的工具来构建软件。从编程语言、框架和云平台到 nocode 应用程序构建器。此外，市场上充斥着各种提高用户期望的 SaaS 产品。

定义核心

因为竞争如此激烈，你不能不断地重新发明轮子。相反，您的主要目标应该是尽快掌握核心功能。 但核心功能究竟是什么？假设您想创建一个新的送餐应用程序。除非您创建一种新的独特的用户身份验证方式，否则您可能不想推出自己的用户身份验证系统，对吧？用户身份验证似乎不费吹灰之力，但订单管理或交付跟踪等其他子系统可能需要更多考虑。您应该自己构建还是购买解决方案？ 在下文中，我将快速介绍一组可能不属于核心的系统和服务，因为它们对许多 SaaS 产品很常见并且可以重用。让我们开始吧。

用户认证

正如已经提到的，我们绝对不应该重新发明轮子进行身份验证，而只是重用现有的服务。您的应用应提供至少一种身份验证提供商，例如 Google 或 Facebook。您甚至可以决定不提供电子邮件注册，这样您就不必自己创建不同的登录、注册和密码重置表单。

电子邮件通知

向您的客户发送诸如订单确认之类的交易电子邮件是必不可少的。有很多服务提供 API 以低价发送交易电子邮件。但你可能会在路上遇到一些惊喜。例如，有一次著名的电子邮件服务提供商刚刚停止为我工作，因为共享 IP 地址被大多数反垃圾邮件服务列入黑名单。支持也无能为力，建议等待，希望共享IP地址尽快下线。在此期间，没有电子邮件可以通过，所以我要么升级并获得一个昂贵的专用 IP 地址（不，谢谢），要么转移到其他服务。最后我决定快速转向另一个电子邮件服务，因为这些服务的 API 都非常相似，只需要对代码进行微小的更改。这里的教训是尽量减少对外部服务的依赖。 但还有更多。如果您正在为欧洲客户服务，那么您需要了解最新的数据隐私法规，看看 Schrems II。查看服务提供商，从他们那里获得签署的 DPA（数据处理协议）并调整您的隐私政策。在某些情况下，您甚至可能需要停止使用该服务。同样在这一点上，尽可能少的依赖是好的。 另一点是多租户。如果您的客户需要从其域发送电子邮件，则电子邮件服务必须支持不同的自定义域。仔细检查自定义域的定价和限制。

多租户

在多租户方面，基本上有两种 SaaS 产品：B2C 和 B2B。 对于 B2B 应用程序，最好为每个客户创建一个逻辑分区或数据库。一方面，这将降低代码的复杂性，因为现在您不必担心层次结构层。团队层次结构和权限管理已经是复杂的主题。此外，您还可以降低您的客户的客户由于某些可能给您带来麻烦甚至破产的错误而混淆的风险。删除客户数据也只是删除数据库的问题，而不是在庞大的数据库中搜索该客户的特定数据，然后将其删除。 对于 B2C 应用程序，使用单个逻辑数据库可能更容易。特别是如果您想创建一个具有社交媒体特征的应用程序或类似约会应用程序的客户相互交互的应用程序，那么您可能会从更紧密的客户数据中受益。但是，如果您的客户数量很少，而对象却很多，那么在单个逻辑数据库中管理角色和权限就变得太繁琐了。 授权 基于角色的授权通常用于定义权限和团队层次结构。通常角色直接附加到身份验证上下文。我不是这种方法的忠实拥护者，因为您需要完全控制身份验证服务才能设置角色。最好将授权规则直接存储在您可以控制的客户数据库中。这也产生了很好的关注点分离。

付款

付款必须完全外包。如果您有许多不同的产品和订阅计划，最好在您身边创建发票并将提供商用作纯粹的支付处理器。这将降低将所有产品与支付处理器系统集成的复杂性，因为发票是与外部系统的唯一接口。这还允许您在将来添加其他支付处理器，例如 POS 终端或切换支付处理器，例如由于费用较低。再一次，过多的外部依赖会减慢你的速度。

托管后端 API

托管后端 API 的选项有很多。从裸机到托管应用服务。我相信作为一家 SaaS 公司，你不会因为构建最精美的 Kubernetes 基础设施而获奖。最佳基础设施应该具有成本效益、易于更换和易于扩展。这可以通过无服务器技术（例如 Google Cloud Run）来实现。只需部署您的 docker 容器即可。一个缺点是第一个请求很可能会有几秒钟的“预热”时间。但是，一旦您的流量增加，这个问题就会完全消失。到目前为止，我发现 Google Cloud Run 是唯一实际收费的服务按请求时间而不是实例时间。查看这个关于如何收取请求时间的插图。这是一个巨大的成本节省。

数据库技术

我曾经是 SQL 数据库的忠实粉丝，直到我意识到 RDBMS 只是过去的应用程序框架。要知道，古希腊人会把他们的代码写在靠近数据的存储过程中。稍后他们会将前端代码转储到表中并从中生成视图。在某一时刻，面向对象的语言变得非常流行，不知何故，我们最终将对象强制放入表中，并将这种痛苦称为：“阻抗不匹配”。 值得庆幸的是，我们不必再处理这个问题了（除非我们真的必须这样做，因为我们的 CTO 强迫我们）。NoSql 面向文档的数据库，例如 MongoDB 或 RavenDB，正在兴起，它们性能好，易于使用，我们可以直接处理对象，而不必担心 ORM。 将数据作为转储对象处理对我们的整体设计非常有益。我们倾向于更多地关注对我们系统的行为进行建模。数据模型成为行为的结果。文档数据库总是必须有一些非规范化数据的论点已经过时了。今天，我们可以创建高度规范化的关系模型，并轻松地在数据库级别对文档执行连接。面向文档的数据库对生产力非常有益，让我们能够更快地构建应用程序的核心。

托管数据库

与无状态后端 API 不同，您的数据库需要持久存储。许多数据库提供商提供其数据库引擎的云托管。这些服务还包括备份管理和维护。 不过，定价相当高。我们可以使用免费套餐作为起点，但它们的资源往往非常有限。 另一种方法是租用一个小型虚拟机并自行托管一个社区许可的实例，它可以为最初的数百名用户提供足够的电力。我不推荐大型云提供商租用虚拟机，它们在这方面太贵了。自托管当然需要更多的设置工作，但可以让我们获得足够的利润来切换到无服务器数据库解决方案。

后台处理

我们希望在后台异步处理某些类型的工作负载：

• 不需要立即得到结果的数据处理任务，可以放在后台。
• 处理外部事件，例如来自我们的支付服务提供商的支付状态更新或来自其他集成系统的更新
• 处理内部事件

无服务器功能与消息服务总线相结合，为数据处理和内部事件处理提供了一个很好的解决方案。另一方面，外部事件主要是触发我们系统中的 http 端点的 webhook 调用。对于这种情况，最好启动一个 Google Cloud Run 实例，该实例将在后台处理传入的 webhook 调用。Azure、Aws 和 GCP 为消息总线和无服务器功能提供了良好的解决方案。在撰写本文时，我正在构建一个基于 GCP 的更统一的解决方案，敬请期待！

第一部分结束

在这篇文章变得太长之前，让我们在一个简单的清单中总结到目前为止我们学到的东西：

• 确定您的应用程序的核心业务理念
• 了解您的应用类型是 B2B、B2C 还是两者兼有
• 添加身份验证提供程序
• 为您的交易电子邮件找到合适的电子邮件服务提供商
• 使用发票作为数据接口集成在线支付提供商
• 使用无服务器技术为您的无状态后端 API 提供服务
• 使用面向文档的数据库，例如 RavenDB 或 MongoDB
• 在小型虚拟机上托管您的数据库或在刚开始时选择收费计划，稍后切换到基于云的托管
• 在您选择的云提供商处：创建消息总线并附加无服务器功能以处理内部事件

在第二部分，我将写 UI 框架、代码设计、安全、DevOps 和其他 SaaS 相关主题。同时在这里加入我们新的聚会小组，并与社区分享您的想法。

谢谢大家关注，转发，点赞和点在看。