Octopus（八达通）支付网关微服务
可用于生产环境的多租户支付网关服务，具备 HMAC-SHA256 请求签名、防重放、商户密钥轮换和 webhook 投递。
- 角色
- 平台与 DevSecOps 工程师
- 类型
- 在 Appnovation 全职工作期间开发
- 时间
- 2025.09 至 2025.10
在 Appnovation，我设计并开发了一个达到生产标准的支付网关微服务，把 Octopus 支付处理从单个客户项目里抽出来，做成多个商户和应用可以共用的服务：身份认证、请求签名、静态数据加密、商户管理，以及带重试的 webhook 投递。
问题
Octopus（八达通）是香港的储值支付网络。它的支付逻辑原本写在一个客户项目里。再来第二个、第三个项目，就得复制安全关键的代码，所以它需要变成一个独立服务，供多个商户和应用调用。
难点在哪里
- 多租户：每个商户都有自己的凭证、密钥和资料，与其他商户相互隔离。
- 每个请求都必须经过身份认证并且防篡改，被截获的请求也不能被重放。
- 机密数据必须加密存储，密钥轮换不能造成停机。
- 发往商户系统的 webhook，必须经得起对方接口变慢或出故障。
架构
一个基于 PostgreSQL 的 Spring Boot 服务（Java 17），用 Docker 打包。调用方用 JWT 认证，并用 HMAC-SHA256 给每个请求签名。加密服务负责哈希和 AES-256-GCM 加密。商户管理 API 负责商户资料和密钥。webhook 投递异步执行，不在请求路径上。
- Java 17
- Spring Boot
- Spring Security
- PostgreSQL
- Docker
- JWT
- HMAC-SHA256
- AES-256-GCM
我做了什么
平台与 DevSecOps 工程师
- 01设计并实现加密服务：SHA-256 哈希，以及对静态存储的机密数据做 AES-256-GCM 加密。
- 02构建 HMAC-SHA256 请求签名系统，并防止重放攻击。
- 03开发商户管理 API，支持密钥轮换和商户资料管理。
- 04实现异步 webhook 投递，带重试逻辑和失败处理。
- 05编写单元测试和集成测试套件。
决策与挑战
每个请求都签名，拒绝重放
HMAC-SHA256 签名可以证明请求是谁发的，以及内容没有被改过。有了防重放，被截获的请求不能原样再发一次。
平滑轮换密钥
API 密钥自动轮换，旧密钥在宽限期内仍然有效，商户可以不中断服务地完成切换。
异步投递 webhook
向商户系统的投递不在支付请求之内执行，带重试和失败处理，所以一个慢接口不会拖住一笔支付。
必须存的就加密
静态存储的机密数据用 AES-256-GCM 加密。凡是原值以后不再需要的地方，都使用哈希。
值得一讲的故事
从一开始就是多租户：每个商户都有自己的凭证、密钥和资料。
API 密钥自动轮换，旧密钥过期前留有宽限期，商户切换时不会中断服务。
经过验证的结果
- 一个达到生产标准、独立的多租户支付网关服务，带商户管理 API。
- 两周交付约 3,680 行代码，含单元测试和集成测试。
- 请求签名、防重放、密钥轮换和 webhook 重试，都作为共享基础设施实现，而不是每个项目各写一份。
数字
- 两周约 3,680 行代码
- 多租户架构
- HMAC-SHA256 签名与防重放
这对客户说明了什么
我能把支付系统中安全关键的核心部分（请求签名、密钥管理、加密和可靠的 webhook）设计成一个服务，供其他团队在它之上开发。
告诉我你在做什么。
几句话就够了：做的是什么、目前进展到哪一步、需要工程师做什么。表单就在下方，也可以直接发邮件。我会在两个工作日内回复。