为了给企业提供更加易用的应用层软件，越来越多的软件提供商推出了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架构设计防止用户体验的升高或者造成您的损失。

本篇作者


张明月
亚马逊云科技
合作伙伴解决方案架构师