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

本文涉及的产品
简介: 【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 相关主题。同时在这里加入我们新的聚会小组,并与社区分享您的想法。

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
相关文章
|
1天前
|
消息中间件 监控 API
构建高效微服务架构是后端开发的关键
【5月更文挑战第22天】构建高效微服务架构是后端开发的关键,涉及核心原则如服务独立、去中心化、自治和轻量级通信。优势包括可扩展性、独立性、技术灵活性和团队协作。最佳实践包括恰当的服务拆分、选择RESTful API、RPC或消息队列进行通信、处理数据一致性和分布式事务、实施服务治理与监控,以及确保安全性与权限控制。随着技术进步,未来将探索服务网格、容器化和云原生技术,以提升微服务架构的效能和适应性。
9 0
|
1天前
|
Kubernetes Cloud Native API
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第22天】 随着企业加速其数字转型的步伐,云原生架构成为了推动创新、提升敏捷性及优化资源使用效率的核心动力。本文深入探讨了云原生技术如何助力企业实现弹性伸缩、持续集成与持续部署(CI/CD)、微服务架构以及如何借助容器化和编排工具来管理复杂应用。通过分析云原生架构的主要组件,包括容器、服务网格、不可变基础设施和声明式API,揭示了它们如何共同塑造出一个高度自动化、可扩展的云计算环境。此外,文中还讨论了采纳云原生实践所面临的挑战与克服策略,为读者提供了一个关于云原生技术如何赋能业务发展和技术升级的全面视角。
|
2天前
|
消息中间件 安全 数据管理
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第21天】 在现代软件开发的浪潮中,微服务架构已经成为一种流行且有效的解决方案。它通过将复杂的应用拆分成一组小服务来增强系统的可维护性、扩展性和技术多样性。本文深入探讨了构建高效微服务架构的关键要素,包括服务划分原则、通信机制、数据管理以及安全性考量。通过对这些核心组件的分析,我们将揭示如何优化后端开发流程,以适应快速变化的市场需求和技术演进。
|
2天前
|
人工智能
邀您参会丨飞天技术沙龙 AI 原生应用架构专场·北京站
飞天技术沙龙 AI 原生应用架构专场·北京站报名中。
|
2天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业转型中的关键角色
【5月更文挑战第21天】 随着数字化转型的浪潮席卷全球,企业正面临前所未有的挑战与机遇。本文深入探讨了云原生架构如何成为推动企业敏捷性、可扩展性和创新能力的核心动力。通过分析云原生技术的基本原理及其在各行各业中的应用案例,揭示了该技术如何助力企业实现资源优化、加快产品上市时间以及提高服务质量。文章旨在为企业决策者和技术实践者提供洞见,以便更好地理解和应用云原生架构,从而在竞争激烈的市场中保持领先地位。
|
2天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与实践
【5月更文挑战第21天】 随着数字化转型的加速,企业对于敏捷性、可扩展性和成本效益的需求日益增长。云原生技术以其独特的优势应运而生,成为推动企业IT架构现代化的重要力量。本文将深入探讨云原生架构的核心概念、关键技术以及如何在企业中实施云原生解决方案,以实现真正的弹性、自动化和持续交付。
|
2天前
|
Cloud Native 持续交付 API
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第21天】 随着企业加速其数字化进程,云原生架构已成为推动创新和灵活性的核心驱动力。本文探讨了云原生技术如何助力企业构建高度可靠、可扩展的系统,并确保业务连续性。通过深入分析微服务、容器化、持续集成和自动化管理等关键概念,揭示云原生实践如何优化资源利用,降低运营成本,同时提升服务质量。文章旨在为决策者提供策略洞见,帮助他们在动态市场环境中保持竞争力。
|
2天前
|
消息中间件 设计模式 开发者
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第21天】 在快速迭代的软件开发领域,微服务架构已经成为支持复杂应用和持续交付的关键设计模式。本文将深入探索微服务的核心原则、技术栈选择以及它们如何影响现代后端开发流程。通过分析微服务的设计理念和最佳实践,我们将了解如何构建一个既灵活又高效的系统,以应对不断变化的业务需求和技术挑战。
|
2天前
|
消息中间件 数据管理 持续交付
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第21天】 随着企业应用的复杂性不断增长,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为解决方案,其优势在于模块化设计、独立部署和可扩展性,为后端开发带来了新的思路和方法。本文将探讨如何构建高效的微服务架构,涵盖关键组件的选择、网络通信机制、数据管理策略以及持续集成与持续部署(CI/CD)的实践。我们的目标是为后端开发者提供一套可行的技术指南,帮助他们在面对不断变化的业务需求时,能够设计出既稳定又灵活的服务架构。
|
2天前
|
Cloud Native 持续交付 云计算
构建未来:云原生架构在企业数字化转型中的关键角色
【5月更文挑战第21天】 随着企业加速其数字化转型步伐,云原生架构凭借其灵活性、可扩展性和敏捷性成为支撑创新的关键。该文深入探讨了云原生技术如何助力企业实现从传统IT向现代应用开发和运维模式的转变,以及这一转变如何推动业务增长和竞争力提升。文中不仅阐述了云原生的核心组件如容器化、微服务和持续集成/持续部署(CI/CD)等,还讨论了企业在采纳这些技术时面临的挑战及克服策略。通过具体案例分析,本文揭示了云原生实践在不同行业中的适用性和效益,为决策者提供了实施云原生路线图的洞见。