如何将基于微服务的Angular静态构建项目部署到AWS S3并正确管理路由？

方案1：Lambda@Edge Origin Request触发器（推荐） #

针对多微服务场景，这个方案能精准匹配各服务的深层路由，让Angular前端路由接管请求处理。

• 先在us-east-1区域创建Lambda函数（Lambda@Edge要求必须部署在此区域），代码如下：

exports.handler = async (event) => {
    const request = event.Records[0].cf.request;
    const uri = request.uri;
    
    // 替换成你的实际微服务前缀列表
    const microServices = ['global-dashboard', 'user-center', 'system-settings'];
    
    for (const service of microServices) {
        // 匹配微服务下的深层路由，排除静态资源（带后缀的文件）和根路径
        if (uri.startsWith(`/${service}/`) && !uri.includes('.') && uri !== `/${service}/`) {
            request.uri = `/${service}/index.html`;
            break;
        }
    }
    
    return request;
};

• 发布Lambda函数为版本，然后在CloudFront分发的Origin Request触发器中关联该版本。可选择让触发器作用于所有行为，或针对每个微服务的路径单独配置。
• 确保Lambda函数拥有lambda:GetFunction、cloudfront:CreateCloudFrontOriginAccessIdentity等必要权限。

方案2：CloudFront错误页面重定向（快速临时方案） #

如果不想用Lambda@Edge，可通过CloudFront错误规则兜底处理：

• 进入CloudFront分发的错误页面设置，添加404错误码规则：
  • 开启「自定义错误响应」
  • 响应页面路径：/global-dashboard/index.html（多微服务场景需给每个服务的路径行为单独配置，比如路径模式/global-dashboard/*对应错误页面/global-dashboard/index.html）
  • HTTP响应码设置为200 OK
• 这个方案适合快速验证，但灵活性不如Lambda@Edge。

方案3：Angular构建前置优化 #

部署前确保Angular项目构建时设置正确的基础路径，避免路由根路径混乱：

• 执行构建命令时指定base-href：

ng build --prod --base-href="/global-dashboard/"

• 这样Angular生成的路由会自动以/global-dashboard/为基础，配合CloudFront的路由转发规则，能避免前端跳转时的路径错误。

关键注意事项 #

• S3静态网站的索引文档必须设置为index.html，错误文档可留空或同样设为index.html。
• CloudFront行为配置中，针对index.html要设置不缓存，避免路由更新后用户看到旧页面。
• 测试所有路由场景：直接访问深层路径、刷新页面、前端路由跳转，确保所有请求都能正确转发到对应微服务的index.html。

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