SaaS架构

SEO Title
saas architecture
Chinese, Simplified

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

SEO Title
The tech that you need to build your SaaS Product — Part I
Chinese, Simplified

你有一个新软件产品的想法,你已经完成了你的研究,创建了一个受众并承诺每个人都会解决这个问题。在下文中,我将为您提供一个经过验证的清单和构建 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 相关主题。同时在这里结帐并加入我们新的聚会小组,并与社区分享您的想法。

原文:https://medium.com/codex/tech-that-you-need-to-build-your-saas-product-…

本文:https://jiagoushi.pro/node/2005

【SaaS架构】由 Next JS 和 AWS 组成的单人团队在 2021 年构建 SaaS 的现代技术堆栈

SEO Title
The Modern Tech Stack to Build a SaaS in 2021 as a Team of One-Man with Next JS and AWS
Chinese, Simplified

作为热爱尖端技术的人,我选择使用现代技术堆栈构建我的第一个 SaaS。 随着 JAMStack 和无服务器架构的兴起,我创建了带有 Next JS 静态生成的 PostMage,用于前端和部署到 AWS 的 Node.js 后端。
因为我是一个单独的全栈开发人员,所以我的时间和资源非常有限。 在本文中,我将分享我用于构建 SaaS 产品的所有技术:从编程语言到开发工具。 您将了解我如何克服这一挑战,以独立开发者的身份构建 SaaS。
希望我的故事能给你灵感来创建你的 SaaS 产品。


无处不在的TypeScript


为了构建我的 SaaS,我用 TypeScript 编写了每一行代码。 是的,所有代码:前端、后端以及 TypeScript 中的基础设施即代码。

整个项目只使用一种独特的编程语言。 没有时间学习新语言并通过使代码易于维护来节省时间。
我为什么选择 TypeScript? 它通过强类型使开发更加愉快,并且与 IDE 有更好的集成。 所以,如果你还是一个 JavaScript 开发者,你应该试一试。


前端框架


对于前端,我使用 Next.js。 这是一个构建复杂应用程序的 React 框架。 好消息是,Next JS 开箱即用地支持 TypeScript。

我使用 Tailwind CSS 样式化 React 组件。 作为开发人员,您通常会构建一个丑陋的界面。 使用 Tailwind CSS,即使您不是设计师,您现在也可以构建一个不那么难看的界面。

作为 JAMStack 的忠实信徒,我之前花了一些时间尝试 Jekyll、Hexo 和 11ty 用于不同的项目。 我选择使用 Next JS 以静态生成模式构建我的 SaaS。 因此,在构建时,所有页面都会生成并预渲染。 非常适合 SEO、廉价托管、快速、安全和高度可扩展。


静态托管


我使用 Cloudflare Pages 作为前端的托管服务,它是 Netlify 或 Vercel 的全新替代品。 Cloudflare 已于 2020 年 12 月发布测试版,并于 2021 年 4 月向公众发布。

Pages 中有一些小的缺失功能(没什么大不了的)。 在 Cloudflare 团队解决它之前,我找到了临时解决方法。 所以,这没什么大不了的。
Cloudflare Page 的好处是其慷慨的免费套餐:无限带宽(Vercel 和 Netlify 每月限制为 100GB),您可以免费设置受密码保护的网站(Vercel 或 Netlify 中不包括免费)。


无服务器 REST API


在后端,我使用 Express.js 和无服务器框架构建了一个 REST API。 为了在 Serverless Framework 中支持 TypeScript,我使用了 serverless-bundle 插件。 Express.js 需要另一个插件来使用名为 serverless-http 的无服务器框架。

为了获得更好的开发者体验,我还使用了另外两个插件:serverless-dotenv-plugin 和 serverless-offline。第一个插件是支持 dotenv 文件,第二个是在本地计算机上运行无服务器框架。
作为一名独立开发人员,我选择无服务器架构,因为它易于部署、低维护和可扩展的后端,让我的生活更轻松。无需成为 DevOps 工程师:无需 SSH、进行操作系统更新、配置代理/网络服务器/负载均衡器/防火墙等。


认证


REST API 受 IAM 身份验证保护。它是 AWS 的内置功能,可以保护任何 AWS 资源,在我们的例子中是 API 网关和 AWS lambda。当用户未连接到 SaaS 应用程序时,它会拒绝 API 调用。因此,当它受到保护时,外部参与者将无法调用您的资源。
因为 API 部署到 AWS,所以我选择使用 AWS Cognito 进行身份验证。好消息是 Cognito 通过提供为 SaaS 实施身份验证所需的一切,节省了大量时间。您无需任何努力即可访问电子邮件身份验证和社交登录(Facebook、Google、Apple 和 Amazon)。

AWS Cognito 和 React 前端之间的连接是通过 AWS Amplify 完成的。 Amplify 提供 React 组件和代码,让您的前端集成到 AWS 更轻松、更快捷。

NoSQL 数据库


PostgreSQL 和 MySQL 等主要和知名的数据库不太适合无服务器架构。 由于无服务器的性质,它可以创建大量的数据库连接并耗尽数据库连接限制。


在大多数提供商上,即使您的 SaaS 上没有任何流量,您仍然需要为数据库实例付费。 相反,当您的应用程序开始增长时,您的数据库很快就会成为瓶颈。


作为一个单独的全栈开发人员,我想要一些非常容易管理并且 100% 兼容无服务器的东西。 因此,我选择 DynamoDB 作为主数据库。

DynamoDB 是一个完全由 AWS 管理的 NoSQL 数据库,我用它来存储用户状态。 他们几乎处理所有事情,我只需要专注于我的代码。


基础设施即代码


如您所见,我为我的 SaaS 应用程序使用了多种 AWS 服务。 在每个环境(开发、登台或生产)中手动设置云资源非常痛苦,并且很难保持它们之间的一致性。
AWS 允许开发人员访问 AWS CDK,您可以在其中使用 TypeScript 定义您的云资源。 在一个命令中,您可以部署到您的 AWS 账户并预置所有内容。

部署


像许多开发人员一样,我使用 Git 和 GitHub 对我的代码进行版本控制。 许多现代托管服务,如 Vercel 和 Netlify,Cloudflare 页面会在每次提交时自动构建和部署您的代码。 如果您使用 Git 分支,您还可以实时预览结果而无需推送到生产环境。

对于后端和基础架构,我使用名为 Seed.run 的第三方服务在每次提交时自动部署。 与前端一样,它也在 AWS 上构建和部署后端资源。


DNS 和 CDN


您可能会怀疑,我毫无意外地将 Cloudflare 用于 DNS 和 CDN ;) Cloudflare Pages 会自动将您的代码部署在 Cloudflare 网络中,我只需将我的域指向 Cloudflare DNS 服务器,其余的由他们处理。 使用 Cloudflare,您可以获得大量安全功能,例如为您的 SaaS 产品提供防火墙和 DDoS 保护。

错误跟踪


我使用 Sentry 作为错误跟踪解决方案。 当出现问题时,它会自动报告有用的信息,如堆栈跟踪、面包屑(问题之前发生的一系列事件)、浏览器信息、操作系统信息等。它通过丰富的数据使生产中的调试变得更加容易:

Sentry 只为前端设置,而不是为 REST API 设置,我一直使用本机解决方案。 事实上,使用 AWS lambda 的 Sentry 会产生大量开销,而且设置并不简单。 在下一节中,您将找到我在后端用于错误跟踪的解决方案。

记录、监控和警报


AWS Lambda 自动将日志发送到 AWS CloudWatch,因此无需使用 Sentry。 以下是 CloudWatch 中存储的日志示例:

您还可以访问您的 lambda 指标。 非常适合了解您的无服务器函数的行为方式并检测是否有任何错误。

我还使用 Lumigo 为我的日志记录和监控提供更多信息。 与 Cloudwatch 相比,该界面更易于使用:

您还可以在 Lumigo 中启用跟踪,您可以在其中可视化您的 AWS 服务和外部 API 调用。 通过让您知道代码中是否存在错误或来自外部服务的错误,它使您的调试会话更容易。

付款和订阅


SaaS 的最后一部分,对企业来说最重要的是接受付款。 接受一次性付款很困难,但重复付款的任务非常复杂。 不幸的是,对于 SaaS 业务,我们需要处理第二种情况。
您的客户在首次订阅时需要选择计划并输入他们的个人信息。

之后,您的用户应该有一个自助服务门户,他们可以在其中管理他们的计划:升级、降级、取消、暂停、恢复他们的订阅计划。
他们有时还需要更新他们的个人信息。 而且,他们还需要在需要时访问他们的发票历史记录。

Stripe 可以管理我在本节中提到的所有内容,它隐藏了所有这些复杂性,并使与支付的集成更容易。

结论


我花了 5 个月的时间来构建这个全栈 React SaaS 模板。 我没有专注于我的业务,而是解决了这些技术细节。 构建您的 SaaS 的第一个版本应该只需要 1 个月而不是 5 个月。
通过这段漫长的旅程,我学到了很多东西,也犯了很多错误。 我希望其他开发人员不会犯同样的错误,所以我为 SaaS 产品构建了 Nextless JS,React Boilerplate。

使用 Nextless.js,您无需编写任何代码即可获得我在本文中提到的所有内容。 节省您的时间,专注于重要的事情并更快地启动您的 SaaS。 在 Nextless JS 中查找更多信息。

原文:https://medium.com/@ixartz/the-modern-tech-stack-to-build-a-saas-in-202…

本文:https://jiagoushi.pro/node/2027