共计 4900 个字符，预计需要花费 13 分钟才能阅读完成。
为了给企业提供更加易用的应用层软件，越来越多的软件提供商推出了 SaaS 产品。亚马逊云科技 Marketplace 是一个提供甄选的数字化产品的平台，可能帮忙 SaaS 厂商升高销售老本，触达更多的客户，是很多 SaaS 厂商的首选。
通过软件即服务（SaaS）产品，您部署了在亚马逊云科技提供的基础设施上的软件，并容许买家能够间接通过亚马逊云科技 Marketplace 来应用您的软件。您须要在您的软件中治理客户拜访、账户创立、资源配置和账户治理。
📢 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注 2021 亚马逊云科技中国峰会！点击图片报名吧～
在亚马逊云科技 Marketplace 中上架您基于 SaaS 模式的软件过程中，您须要与亚马逊云科技 Marketplace SaaS 提供的多个 API 进行对接，具体对接的形式您能够参考 卖家指南。
- 卖家指南
https://docs.aws.amazon.com/m…
在您的 SaaS 中，建议您将与亚马逊云科技 Marketplace SaaS API 进行接口集成的局部作为独立模块进行研发和治理，并运行在您的亚马逊云科技账号中。
在上一个文章《亚马逊云科技 Marketplace 上的 SaaS 架构设计 ——如何反对跨多账户对接》中，咱们基于 SaaS 架构设计的角度介绍了多个亚马逊云科技账户中构建亚马逊云科技 Marketplace SaaS 的 API 对接的最佳实际，除了多亚马逊云科技的账户状况可能会产生，还会产生另外一种状况，就是 卖家将同一个 SaaS 应用程序，依据性能以及业务上的要求，拆分成了多个 SaaS 产品上架到了亚马逊云科技 Marketplace 中，这意味着同一个卖家账户，在亚马逊云科技 Marketplace 上架了多款 SaaS 产品，然而这些 SaaS 产品的租户与账户零碎是雷同客户同时登陆雷同的 SaaS 应用程序。
在这种状况下，与亚马逊云科技 Marketplace 的租户 API 对接过程将会变得复杂，本文将基于这个场景，进行 SaaS 架构设计的介绍。
租户对接介绍
在您的 SaaS 应用程序与亚马逊云科技 Marketplace API 进行对接的过程中，其中一个重要的就是租户的对接，这里波及到的 API 为 ResolveCustomer。
ResolveCustomer 是由 SaaS 应用程序在注册过程中调用的。当买家在注册过程中拜访您提交给咱们的落地页面时，买家会通过他们的浏览器提交一个注册令牌。注册令牌通过该 API 被解析，以取得 CustomerIdentifier 和产品代码。
- 接管新用户 API：ResolveCustomer
当一个用户从亚马逊云科技 Marketplace 订阅并跳转到您的 SaaS 应用程序后，您将会面临您的应用程序与亚马逊云科技进行用户对接的过程，该用户在第一次达到您的 SaaS 应用程序时，他具备 Amazon Web Services 的账户身份，同时该用户在您的 SaaS 应用程序中载入后，他也具备您的 SaaS 租户属性，为了日后您与亚马逊云科技 Marketplace 进行交互，您须要在这一步骤中进行 API 集成，实现该用户 2 个身份的绑定。
ResolveCustomer API 是整个 SaaS API 集成的第一步，也是客户通过亚马逊云科技 Marketplace 进入到您的 SaaS 利用的第一步，在这一步骤中，咱们须要通过该 API 实现两局部工作：
- 验证新客户
在客户订阅您的产品后，他们将被重定向到执行的 URL。该重定向是一个 POST 申请，包含一个长期令牌。而后，您的应用程序须要通过调用亚马逊云科技 Marketplace 计量服务 API 中的 Amazon ResolveCustomer，将令牌换成客户 ID。在取得客户 ID 后，将其保留在您的应用程序中，以便未来调用。
- 载入您的新客户
在胜利地验证了一个客户后，让他们退出您的应用程序。例如，让他们填写一个表格来创立一个新的用户账户。或者，为他们提供进入应用程序的后续步骤。您的应用程序能够依据客户的信息来自动化地装载该客户所须要的后续资源与服务。
如上图所示，在应用 ResolveCustomer API 的过程中，首先须要从 Http Request 中获取 token，当客户从亚马逊云科技 Marketplace 跳转到您的应用程序过程中，亚马逊云科技 Marketplace 会给您上线过程中提交的 URL 发送 POST 申请，您须要从该申请中通过获取 x -amzn-marketplace-token 获取该用户的身份 token，而后调用 ResolveCustomer API 取得 CustomerIdetifier 和 ProductCode，其中 CustomerIdetifier 为该客户在亚马逊云科技上身份的标示，ProductCode 是产品的惟一标识码。
您须要将 CustomerIdetifier 与 ProductCode 基于您利用程序逻辑进行业务解决，并用于后续该用户与亚马逊云科技 Marketplace API 交互。
案例背景
以上为失常状况下的租户对接过程，但如果在亚马逊云科技 Marketplace 中您应用了雷同的卖家账号上架了多款 SaaS 产品，但这些 SaaS 应用程序应用了雷同的租户注册与验证零碎同时客户登陆的是同一套 SaaS 应用程序，将会面临更加简单的问题。
对于亚马逊云科技 Marketplace 中基于 SaaS 交付的产品中，有多种价格模型能够抉择，本篇文章所波及的内容重点为 租户零碎对接的设计，订阅模型与合约模型作为租户零碎对接设计的后续行为，所以在下文中，将以基于订阅的价格模型作为举例。
在本文章的举例中，有两个您上架的 SaaS 产品，别离为
SaaS1
产品 ID 为 product1111
SaaS2
产品 ID 为 product2222
SaaS 架构设计
在失常的状况下，当客户通过亚马逊云科技 Marketplace 购买您的产品后，咱们会建议您将 SaaS 应用程序的租户与通过亚马逊云科技 Marketplace API 换到的 CustomerIdetifier 进行绑定，而产品 ID 则依据您的需要进行正当的长久化，这样您的 SaaS 应用程序中的用户在产生消费行为过程中，您会将该行为记录并整合到您的用户的租户中，并通过亚马逊云科技 Marketplace API 与亚马逊云科技 Marketplace 进行计价的交互，在这种背景下，租户对接设计个别为：
在下面所举例的租户设计中，Marketplace_Id 字段代表着长久化的亚马逊云科技 Marketplace CustomerIdetifier，该字段存在值代表着该租户是通过亚马逊云科技 Marketplace 平台进入到 SaaS 应用程序中，将来该租户的所有计费相干的行为将应用该字段的值，该 SaaS 应用程序的产品 ID 以及计费维度和使用量来与亚马逊云科技 Marketplace 进行交互，如下所示：
{
"ProductCode": "product1111",
"UsageRecords": [
{
"CustomerIdentifier": "5ha1maxi",
"Dimension": "Data",
"Quantity": 2,
"Timestamp": xxxxx
}
]
}但当中您应用了雷同的卖家账号上架了多款 SaaS 产品，但这些 SaaS 应用程序应用了雷同的租户注册与验证零碎，这种架构设计会导致以下问题：
无法控制 SaaS 应用程序的权限
用户通过亚马逊云科技 Marketplace 抉择您其中一款 SaaS 产品购买并注册 / 登陆后，因为您之前的 SaaS 架构设计起因，您将无奈区别该用户来源于哪个亚马逊云科技 Marketplace 中您上架的产品，所以您无奈进行 SaaS 应用程序的权限管制
局部状况下无奈进行 API 交互
用户通过亚马逊云科技 Marketplace 抉择您其中一款 SaaS 产品购买并注册 / 登陆后，可能会在您的 SaaS 应用程序中应用了您另外一款上架的 SaaS 应用程序的性能，您的 SaaS 应用程序会依据该性能去调用亚马逊云科技 Marketplace 计费 API 与亚马逊云科技 Marketplace 交互，然而因为该用户并没有通过亚马逊云科技 Marketplace 订阅您的另一款产品，您会失去一个谬误的返回。
所以在这种非凡的状况下，您的 SaaS 架构设计在租户层依据您上架的产品数量来进行标示的辨别并与您的租户零碎进行绑定，如下图所示：
或者
{
"Tenant_T": [
{
"TenantID": "AAA",
"User": [
{"UserID": "111"},
{"UserID": "222"},
{"UserID": "333"}
],
"Marketplace": [
{
"ProductID": "product111",
"MarketplaceID": "5ha1maxi"
}
]
},
{
"TenantID": "BBB",
"User": [
{"UserID": "111"},
{"UserID": "222"}
],
"Marketplace": [
{
"ProductID": "product111",
"MarketplaceID": "5ha1maxi"
},
{
"ProductID": "product222",
"MarketplaceID": "d92nwk21"
}
]
}
]
}在这种租户架构下，您能够清晰地区分出亚马逊云科技 Marketplace 端的租户，您上架的产品以及您的 SaaS 应用程序的租户之间的关系，当某一个用户进行您的 SaaS 应用程序性能的抉择时，你须要找到该用户对应的租户以及该租户中通过亚马逊云科技 Marketplace 订阅的产品，如果该性能所属的产品曾经被订阅，您能够间接应用这些信息于亚马逊云科技 Marketplace API 交互进行用量的传输，如果该用户并没有订阅该产品，您的应用程序应该进行相应的解决，比方禁止该用户应用此性能并疏导客户至相应的亚马逊云科技 Marketplace 上您的产品进行订阅后再进行应用。
总结
该文章中阐明了在 SaaS 架构设计中，在依据业务和产品的需要，须要将 SaaS 应用程序拆分多个产品进行上架的状况下，如何进行 SaaS 租户的设计以及权限的判断，咱们建议您在非必要状况下，不要进行繁多 SaaS 应用程序的的拆分而上架多个亚马逊云科技 Marketplace 产品，但如果您的需要必须如此，请您进行好响应的 SaaS 架构设计防止用户体验的升高或者造成您的损失。
本篇作者
张明月
亚马逊云科技
合作伙伴解决方案架构师
