第二大块是物理架构。大家在阿里可能都听说过，我们有一个比较有名的单元化架构，其实不光阿里有单元化架构，很多公司都有类似的架构。比如微信。阿里和他们的单元化架构其实有一些本质的区别。
从2017年到业务平台以后能学到系统它的链路是什么样的，数据链路是怎么样的，整个调用链路是怎么样的，它和底层的关系是什么样的，可能遇到什么样的问题了？现在可能出现这个问题，再往后运行是不是会出现其他的问题。通过救火的过程中积累对系统的了解。
如果在提交阶段我们发现事务只涉及了一个分片，那么我们就会将其优化为一阶段提交，使用 XA COMMIT ONE PHASE 语句提交事务。对于正常的 TSO 事务，我们取了 SNAPSHOT_TS 和 COMMIT_TS 两个时间戳，而对于一阶段提交的事务来说，其实行为与单机事务类似，因此我们并不需要通过 TSO 获取 COMMIT_TS，而是可以直接由 InnoDB 计算出一个合适的 COMMIT_TS 来提交事务。具体的计算规则是：COMMIT_TS = MAX_SEQUENCE + 1，其中 MAX_SEQUENCE 为 InnoDB 本地维护的历史最大的 snapshot_ts。
总结一下就是：
基于容器、服务网格、微服务、不可变基础设施和声明式 API 构建的可弹性扩展的应用。
基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统。
构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。
限流算法。限流也就是调节数据流的平均速率，通过限制速率保护自己，常见的算法有：
固定窗口算法（fixed window）。
漏桶算法（Leaky Bucket）：漏桶算法主要目的是控制数据注入网络的速率，平滑网络上的突发流量。
令牌桶算法（token bucket）：令牌桶控制的是一个时间窗口内通过的数据量，通常我们会以 QPS、TPS 来衡量。
部门墙。跨部门协调还不如与第三方合作。
不尊重专业人士。当所有的生杀大权都掌握在少数人手中的时候。
管理层级太深。管理层级太深导致的问题很多。
SAE 将这些能力组合起来，最终让用户在迁移传统单体应用或者微服务应用时，基本可以实现 0 改造迁移，0 门槛地享受到这款产品背后带来的技术红利。
云原生已经演化成了一个非常庞大的生态。这张图囊括了云原生里非常多的内容。从设计高可用且稳定性高的应用的角度来看，相关的内容包括数据库技术、云原生存储、Service mesh、可观测性、Serverless等。
但通过移除和核心业务无关的内容，从而减小节点数量后，系统的可用率就会大幅增高。上图的左右两边从不同角度对微服务的高可用设计进行了分析。左边是微服务设计应具有的能力，右边是设计高可用微服务架构时应遵循的原则。
微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革：
易于开发和维护：一个应用只会关注一组特定的业务功能，通过服务拆分，能减少应用之间的耦合度，让开发和维护更加简单。
