重读乐天API与Amazon MWS的旧文章 ― SP-API时代的设计发生了怎样的变化

8月21日
讀畢需時 5 分鐘

我们的博客上还留着2020~2023年前后写的「乐天商品搜索API的使用方法」「Amazon MWS的入门方法」等文章。乐天API至今仍在使用，但MWS已经不复存在。这次我们回顾这两篇旧文章，思考「如果是现在的自己，会如何重新构建」。希望能为正在构建类似自动化系统的朋友提供参考。

API設計の大進化を示す図解。左側にある単純接続のシステムから、右側のAmazon SQSやLambdaと連携するサーバレスアーキテクチャへと進化する過程を描写。

要回顾的两篇文章

・乐天商品搜索API的使用方法（2020年前后）：获取应用ID→组装搜索参数→拼接URL发送请求，这样朴素的构成

・Amazon MWS的入门方法（2020年前后）：使用AWS访问密钥·私有密钥进行认证，在Scratchpad中确认运行

两篇都是出于「想让卖家的商品调研自动化」这一相同动机而写的文章。当时的做法还很朴素，只是单次调用一次API。

MWS已经不复存在

首先说明前提：Amazon MWS（Marketplace Web Service）已于2024年3月31日彻底终止服务。如今再读那篇MWS文章，其中写到的端点已经无法使用。

从MWS迁移到SP-API（Selling Partner API），是一个重大转折点：从必须使用AWS IAM签名认证（Signature Version 4）的时代，转向了更简洁的OAuth方式认证。如今开发SP-API，当年文章中写的获取AWS访问密钥·私有密钥的步骤已完全不再需要。

作为撰写技术文章时的教训，这一点也颇为重要：涉及「认证方式」的文章，会随着服务规格变更而最先过时。我们自己的旧文章中，也养成了只在认证相关部分附加提示的习惯。

当时的设计：单次直接调用API

无论是乐天API的文章还是MWS的文章，当时的设计思路是共通的。

・想要的信息，通过一次API调用直接获取

・不特别在意速率限制，需要时按需调用

・结果当场确认，或至多记录到日志中

这在当时的用途（每月手动调研数十件商品左右）下是足够的设计。与其说是「程序」，不如说是「把浏览器里点点点的操作，用代码代替」的程度。

现在的设计：异步·限速控制·下限保护三件套

目前我们运营的Amazon FBM（自发货）调研·价格自动调整系统，虽然目的同样是「自动获取Amazon商品信息」，但架构已经完全不同了。

1. 引入SQS实现异步化

从当时的「需要时直接调用」，变成了「先入队列，由Lambda按顺序处理」的架构。由于SP-API有严格的速率限制，直接调用的设计很快就会遇到429错误（超出速率限制）。引入SQS FIFO队列后，就能在控制处理速度的同时处理大量ASIN。

翔泳社／适合想学习组合运用Lambda、SQS等AWS服务基础的读者。是理解本文这类异步处理设计的基础读物。

2. 用指数退避进行重试

即便如此，429依然会发生。放在当时，遇到错误就直接放弃了；现在则设计为自动重试。不是固定的等待时间，而是每次失败就把等待时间翻倍的指数退避，这样即使处于限速状态，也能自动、从容地重新尝试。

# 指数退避的骨架（实际在SP-API调用中通用）
MAX_RETRIES = 10
wait = 2
for attempt in range(MAX_RETRIES):
    try:
        response = call_sp_api()
        return response
    except Exception as e:
        if attempt == MAX_RETRIES - 1:
            raise
        time.sleep(wait)
        wait = min(wait * 2, 60)

📚 相关书籍

▶ AWS運用入門改訂第2版（AWS运维入门修订第2版）

翔泳社／一本讲述「持续运维」而非「上线即止」诀窍的书。其中关于错误处理与成本管理的思路，与实务直接相关。

3. 把价格下限设计成「不会被打破」

制作价格自动调整功能时，最可怕的事故就是「因为bug而无限制地一路降价」。以当时那种单次API调用的思路，这类防护措施很容易被往后拖延。

在现在的设计中，我们直接引用通过Amazon Listings Items API管理的卖家中心下限价格（minimum_seller_allowed_price），并在更新前必定把新价格钳制在该下限之上。

# 更新价格前务必钳制到下限
new_price = calculate_new_price(competitor_price)
floor_price = get_listing_min_price(sku)  # 从Listings Items API获取
final_price = max(new_price, floor_price)
update_price(sku, final_price)

我们也曾考虑过在自有数据库中重复维护下限价格，但为避免与卖家中心的数值产生偏差，最终确定为以Amazon一方的数据作为唯一真源。对于尚未设置下限的SKU，我们批量导入「当前价格下调10%」作为初始下限，此后程序本身不再更改该下限。

设计发生变化的原因：因为吃过亏

老实说，这3项变更没有一项是从一开始就看得清楚的。DynamoDB费用暴涨的经历，以及SQS堆积了33.6万条消息的经历，此前都在本博客写过。正是实际吃过苦头之后，设计才随之调整。

回过头看，当时的文章在那个时间点也是「正确」的设计。若每月处理量只有数十件，单次直接调用API完全没有问题。让设计走向复杂化的最大原因，往往是没有察觉到规模的变化、却继续沿用同样的构造。一旦处理量增长，「异步化」「限速控制」「下限保护」这3点就值得提早纳入考虑。

另一个变化：从爬虫走向API

旧文章里没有提到，但这几年另一个巨大变化，是数据获取手段本身。以前用BeautifulSoup做爬虫抓取数据的场景，如今正逐步替换为SP-API、Keepa API等官方许可的方式。

爬虫虽然上手容易，但站点结构一变就很容易失效，在Amazon这类平台上还伴随账号被封的风险。若已有官方API，即便多花点功夫，用官方渠道从长远看运营成本反而更低。

小结

把2020年的文章与现在的实现并排比较，变化可以归纳为以下3点。

・单次直接调用 → 经由SQS队列的异步处理

・出错就放弃 → 指数退避自动重试

・无价格保护 → 必定参照Amazon一方的下限价格进行钳制

技术文章从发布的那一刻起就开始过时。尤其是认证方式、计费结构这类「由服务方决定、会随之变化」的部分，需要以数年为单位重新审视。话虽如此，也不必为当年的文章感到难为情——把它作为「当时最优设计的记录」保留下来，日后回顾时反而会成为见证自身成长的资料。

若在使用Amazon SP-API进行自动化系统的设计与搭建上遇到困难，欢迎随时咨询Robin Planning合同会社。从速率限制应对到价格保护机制，我们将凭借实际踩坑积累的经验为您提供支持。

SB Creative ／适合想系统性重新学习AWS整体知识的读者。通过考取认证来梳理知识体系，也能让这类设计判断更容易做出。

※ 以上包含Amazon联盟链接。本博客的收益将用于运营费用。

#SPAPI #Amazon #API设计 #Lambda #SQS #自动化 #复盘

重读乐天API与Amazon MWS的旧文章 ― SP-API时代的设计发生了怎样的变化

要回顾的两篇文章