核心观点 摩根大通分享了其Chase.com平台在云迁移和构建大规模分布式系统方面的核心目标与策略，旨在实现高效弹性扩展、高韧性和卓越性能，以服务其9400万客户并应对不可预测的流量激增[1][44][45] 核心目标 - 云迁移聚焦三大核心目标：以成本效益高且高效的方式实现弹性扩展、实现高韧性、提供卓越性能以防止用户流失[2][47] - 系统需应对不可预测的负载激增，包括合法业务增长（如市场波动）和恶意攻击（如DDoS攻击），其流量可能超过正常负载十倍甚至更高[1][5][46][51] - 在系统压力下，多个组件可能同时发生故障，包括网络设备、负载均衡器、应用程序和数据库连接[1][46] 高效扩展策略 - 实现高效扩展需要分析客户使用模式和行为，发展预测能力，并采用流量整形来识别高频功能，从而有针对性地扩展关键应用[2][47][48] - 整体容量管理是关键，简单地增加服务器不能保证成功，必须仔细权衡成本[3][49] - 弹性扩展存在局限性：从实例启动到完全就绪可能需要数分钟，在此期间涌入的请求会导致资源争用，因此不能仅依赖弹性扩展[5][52] - 预留计算容量能在需要时保证资源可用性，尤其在多租户资源池出现争用时至关重要，并能带来成本节约[5][52] - 扩展不应局限于增加服务器，需辨别扩展是由真实需求触发，还是由上游服务排队导致的响应变慢所错误触发[7][54] - 整合断路器设计可防止应用因上游服务变慢而无限期等待，避免线程耗尽、减少不必要资源消耗，并防止错误触发扩展[7][54] - 成本管理需持续进行，应定期（如每月或每周）应用FinOps流程[6][53] 高韧性策略 - 韧性要求为不可避免的故障做好准备，早期检测和随时执行故障转移至关重要，但为所有组件实现100%可用性既不现实也无必要[8][55] - 基础设施根据关键性分为四层，并设定不同的可用性目标[9][56]： - 关键组件：必须尽可能接近100%可用，如DNS[9][56] - 可管理组件：目标为99.99%可用性（每年约52分钟停机），如各区域独立运行的服务[10][57] - 可容忍组件：目标为99.9%可用性，如可使用缓存数据的令牌服务[10][58] - 可接受组件：目标为99%可用性，如用于基础设施设置的日志服务[10][59] 高性能策略 - 性能显著影响用户体验和基础设施成本，速度能建立用户信任，谷歌等搜索引擎已将速度纳入排名算法[11][59] - 通过部署接入点提升用户体验，对移动设备延迟尤为敏感[11][59] - 实施全面性能策略后，系统延迟降低了71%[12][59] - 边缘计算是实现高性能的主要手段，可将静态内容卸载至靠近客户的入网点，源服务器仅处理动态操作和关键服务[22][68] - 流量整形可对流量分类，确保支撑核心业务的关键流量（如登录、余额查询、支付）资源始终优先运行[25][71] - 利用PoP缓存可将内容检索时间缩短至100毫秒内，远优于直接访问源站可能超过500毫秒的响应时间[26][72] 五大核心架构策略 - 架构方法围绕五个重点领域：多区域部署、高性能优化、全面自动化、具备自愈能力的可观测性，以及强大的安全性[13][59] 多区域部署 - 多区域架构通过隔离和分段实现解耦，有助于管理区域、可用区及网络故障，并限制故障的爆炸半径[14][60] - 面对9400万客户，可用区级别故障可被限制为仅影响一小部分用户[14][60] - 需解决DNS管理、区域间流量调度等挑战[14][60] - 应对可用区故障：需将依赖系统健康状态通过探针反馈给负载均衡器，或采用代理重路由机制将流量导向健康可用区[15][18][61][64] - 应对区域性故障：依赖每10秒一次的统一区域健康检查，关键决策在于选择完全故障转移还是接受降级服务，故障转移可能引发“惊群效应”[19][65] - 跨区域数据复制与一致性是主要挑战，客户分片（按地理位置）可减少复制需求并简化架构[20][66] - 状态管理需要战略性决策，如维护会话亲和性并支持故障转移[21][67] 自动化 - 自动化是关键战略元素，需在部署、基础设施供应、环境配置、健康检查及流量管理等各个阶段实施全面自动化[28][73] - 通过创建“带有倾向性的”架构模板，使应用能自动继承架构标准，让团队聚焦业务功能而非基础设施复杂性[30][75] - 基础设施“重铺”是一种高效实践：定期（如每周或每两周）系统性地自动重建基础设施，以消除配置漂移、应用安全补丁，增强安全性和稳定性[31][76][77] - 自动化故障转移需考虑活跃会话，防止故障转移循环，并根据场景容忍度决定是否降级运行[32][78] 可观测性与自愈能力 - 可观测性要求对观测到的事件进行自动化响应，通过无服务器函数与可观测性集成，自动执行如数据库切换、维护屏蔽等操作[33][79] - 健康监控需在应用层、可用区层、VPC层等多层级进行，每层通过简单的布尔指标实现自动化健康评估，以支持快速决策和自愈[34][80] - 面对告警，需根据业务需求决策，例如是重定向流量、接受降级服务还是执行故障转移[35][36][81] - 需处理“灰度故障”等模糊故障场景，基于可观测性数据将流量重路由至健康可用区[38][83] 健壮的安全性 - 安全需采用零信任模型的分层实现，每一层必须独立运作并假定其他层可能失效[39][84] - 分层涵盖客户端设备安全、边缘过滤与WAF、内部网络分段、容器镜像扫描与最小权限、应用认证授权、数据加密与隐私控制[39][84] 迁移与实施 - 文化转型是成功迁移的基础，云运维与传统企业自建系统存在根本差异，需持续适应云服务、网络策略和浏览器的变化[39][85] - 采用“谁构建、谁拥有、谁部署”的所有权模型，将责任赋予应用团队，并通过自动化确保一致性[40][86] - 结合反应式测试（如Chaos Monkey）和预测性分析（如失效模式与影响分析，FMEA）进行系统测试与验证[41][87] - 开发了名为TrueCD的CI/CD方法论，这是一套包含十二个步骤的自动化流程[41][88] - 使用抽象层（如Dapr开源框架）可最小化架构变更对业务的影响，并支持单云、多云或混合环境[42][89] - 大型应用迁移需循序渐进：先在内部用户中验证，逐步迁移小比例客户群体，最终实现全面迁移，避免压缩时间表[43][90] 实施成果 - 策略实施带来了可衡量成果：显著降低成本，性能指标大幅提升，平台在对比分析中名列前茅[44][91] - Dynatrace公开报告指出，实现亚秒级（<1秒）响应的站点代表了最优性能[44][91]