从Elastic Beanstalk迁移至Lambda：微服务并行与域名配置问询

一、完全可以在同一api.domain.com域名下共存 #

不需要更换子域名，核心靠CloudFront的路径路由和API Gateway的自定义域名绑定实现流量分流，具体操作：

• 在现有CloudFront分发中添加新的行为规则：将指定路径（比如/v1/user-service/*）转发到新的API Gateway端点，原有路径（比如/v1/legacy/*）保持指向Elastic Beanstalk的负载均衡器。用户请求不同路径时，CloudFront会自动将流量导向对应服务。
• 为API Gateway绑定api.domain.com自定义域名：在API Gateway中设置路径映射，比如把/v1/user-service关联到Lambda服务的API部署阶段。注意要在AWS Certificate Manager（ACM）中申请api.domain.com的证书，API Gateway使用的证书必须部署在us-east-1区域，和CloudFront使用的证书保持一致即可。
• Route53无需修改：流量仍先进入CloudFront再做路由分发，原有Route53记录可直接保留。

二、逐步解耦的实操步骤 #

1. 优先拆分独立功能模块：从单体应用中挑选边界清晰的功能（比如用户认证、订单查询），用Lambda重写并搭配API Gateway构建独立服务。
2. 配置路由分流规则：按照上述CloudFront和API Gateway的配置，让新服务的路径指向Lambda，原有路径继续走Elastic Beanstalk。
3. 小流量验证后全量切换：先将一小部分流量切到新服务，确认稳定无问题后，把单体中对应功能的流量全部迁移过去，随后停用单体里的该模块。
4. 重复拆分流程：依次拆分其他功能模块，每次都通过CloudFront路径路由实现新旧服务并行，直到所有功能都迁移到Lambda。
5. 收尾清理：所有服务迁移完成后，关停Elastic Beanstalk环境，删除CloudFront中对应Beanstalk的行为规则，将所有路径统一转发到API Gateway。

三、需要注意的细节 #

• 提前规划路径前缀：每个微服务的路径前缀要提前确定（比如/v1/users、/v1/orders），避免路径冲突，确保CloudFront能精准路由。
• 日志监控同步跟进：新旧服务并行期间，分别为Beanstalk和Lambda配置CloudWatch日志，方便排查问题、监控请求状态。
• 跨服务通信走内部地址：如果Lambda需要调用原有Beanstalk的API，直接使用Beanstalk负载均衡器的内部域名，避免走公网，提升性能与安全性。

内容的提问来源于stack exchange，提问作者Caco