在亚马逊云科技Marketplace上的SaaS架构设计——如何支持多产品使用单一账户中心

为了给企业提供更加易用的应用层软件，越来越多的软件提供商推出了SaaS产品。亚马逊云科技Marketplace(以下简称Marketplace)是一个提供甄选的数字化产品的平台，能够帮助SaaS厂商降低销售成本，触达更多的客户，是很多SaaS厂商的首选。

通过软件即服务（SaaS）产品，您部署了在亚马逊云科技提供的基础设施上的软件，并允许买家可以直接通过Marketplace来使用您的软件。您需要在您的软件中管理客户访问、账户创建、资源配置和账户管理。

在Marketplace中上架您基于SaaS模式的软件过程中，您需要与Marketplace SaaS提供的多个API进行对接，具体对接的方式您可以参考卖家指南。

在您的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 Service的账户身份，同时该用户在您的SaaS应用程序中载入后，他也具备您的SaaS租户属性，为了日后您与Marketplace进行交互，您需要在这一步骤中进行API集成，完成该用户2个身份的绑定。

ResolveCustomer API是整个SaaS API集成的第一步，也是客户通过Marketplace进入到您的SaaS应用的第一步，在这一步骤中，我们需要通过该API完成两部分工作：

• 验证新客户

在客户订阅您的产品后，他们将被重定向到执行的URL。该重定向是一个POST请求，包括一个临时令牌。然后，您的应用程序需要通过调用Marketplace计量服务API中的ResolveCustomer，将令牌换成客户ID。在获得客户ID后，将其保存在您的应用程序中，以便将来调用。

• 载入您的新客户

在成功地验证了一个客户后，让他们加入您的应用程序。例如，让他们填写一个表格来创建一个新的用户账户。或者，为他们提供进入应用程序的后续步骤。您的应用程序可以根据客户的信息来自动化的装载该客户所需要的后续资源与服务。

如上图所示，在使用ResolveCustomer API的过程中，首先需要从Http Request中获取token，当客户从Marketplace跳转到您的应用程序过程中， Marketplace会给您上线过程中提交的URL发送POST请求，您需要从该请求中通过获取x-amzn-marketplace-token获取该用户的身份token，然后调用ResolveCustomer API获得CustomerIdetifier和ProductCode，其中CustomerIdetifier为该客户在AWS上身份的标示，ProductCode是产品的唯一标识码。

您需要将CustomerIdetifier与ProductCode基于您应用程序逻辑进行业务处理，并用于后续该用户与AWS 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架构设计避免用户体验的降低或者造成您的损失。

本篇作者