总结一下就是：
基于容器、服务网格、微服务、不可变基础设施和声明式 API 构建的可弹性扩展的应用。
基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统。
构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。
敏捷基础设施的目标
标准化：所有的基础设施最好都是标准的。
可替换：任意节点都能够被轻易地创建、销毁、替换。
自动化：所有的操作都通过工具自动化完成，无须人工干预。
分布式架构 - 可扩展设计
水平扩展，指用更多的节点支撑更大量的请求。
横向扩展通常是为了提升吞吐量，响应时间一般要求不受吞吐量影响即可。
• 资源管理器（Resource Manger，RM）：事务的参与方，如 MySQL 中的一个库，在 PolarDB-X 中这个角色由存储节点（DN）承担
XA 协议由 TM 向多个 RM 通过 XA PREPARE 和 XA COMMIT 两条命令完成两阶段提交。
• COMMIT_TS 统一了一个分布式事务在每个分片上提交数据发生的时间，会被记录到 InnoDB 引擎中。COMMIT_TS 决定了当前事务在全局事务中的顺序。
阿里电商系统很早就开始建立了，我们这一代一代人在里面去做架构，都是站在前一代人的肩膀上。要去看前一代人为什么要这么设计，去想或跟他去聊，吸取他好的地方。现在可能遇到新的问题，通过其他的方法来解决一些新的问题，需要有实践和知识的积累。
第一点就是沟通能力非常关键。你怎么把这个问题说清楚，切中问题的点，同时也能帮助上下游带来实际的效果。第二点是架构需要能救火，但不仅仅是救眼前的火，应该救未来的火，架构师救火能力要很强。
然而代码分析往往需要耗费大量的时间和资源，当用户请求某个语法服务（如查看定义），后端需要克隆代码，下载依赖包，解析语法，构建索引（类比一下IntelliJ Idea初始化工程的场景），编辑器场景用户已经习惯于这样的方式，等待几分钟或许问题不大。
时序锁管理
根据库大小的区别，LSIF的索引构建时间为10秒至数分钟不等，而用户对同一个代码仓库的提交操作峰值可能会达到每分钟近百次，即使我们采用了增量技术也很难满足高频的构建请求，并且提交事件触达和调度任务执行无法保证精准的时序性。综上所述，我们需要一个分布式时序锁来保证任务调度的顺序和尽量减少重复调度。
Shard Request Cache：针对 ES 的 query 请求，缓存各分片的查询结果，主要用于缓存聚合结果，采用LRU机制，当分片 refresh 后会失效。
