第一点就是沟通能力非常关键。你怎么把这个问题说清楚，切中问题的点，同时也能帮助上下游带来实际的效果。第二点是架构需要能救火，但不仅仅是救眼前的火，应该救未来的火，架构师救火能力要很强。
XA 协议由 TM 向多个 RM 通过 XA PREPARE 和 XA COMMIT 两条命令完成两阶段提交。两阶段提交常常为人诟病的问题是 TM 的单点问题和 Commit 阶段发生异常可能导致的数据不一致问题。为此，在 PolarDB-X 的实现中，我们额外引入了事务日志表以及 COMMIT POINT 的概念。
后来到 2013 年 Matt Stine 在推特上迅速推广云原生概念，并在 2015 年《迁移到云原生架构》一书中定义了符合云原生架构的特征：12 因素、微服务、自服务、基于 API 协作、扛脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁移的过程中，需要文化、组织、技术共同变革。 解读：**云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸**。
其次云作为一种 PaaS 服务，这位“土著居民”从出生(设计)到成长(开发)，再到生活(部署)都应该是基于云的理念来实现的，那么就需要一套自动化的开发流程 CI/CD 来实现。这是 Native 的第二种表现。
故障演练
随机关闭生产环境中的实例。
让某台机器的请求或返回变慢，观察系统的表现，可以用来测试上游服务是否有服务降级能力，当然如果响应时间特别长，也就相当于服务不可用。
模拟 AZ 故障，中断一个机房，验证是否跨可用区部署，业务容灾和恢复的能力。
查找不符合最佳实践的实例，并将其关闭。
易处理，快速启动和优雅终止可最大化健壮性，只有满足快速启动和优雅终止，才能使服务更健壮。
开发环境与线上环境等价，尽可能保持开发、预发布、线上环境相同。
为什么说 Serverless 是天然云原生的呢？虽然 Serverless 出现的时间比云原生更早一些，我们向前追溯，AWS 率先推出初代 Serverless 产品——Lambda，其按请求计费和极致伸缩的特点，非常符合云原生的定义，比如基础设施下沉。在 Lambda 里，不需要管理服务器，它会根据请求去伸缩服务器，实现了高度自动化；它还以函数的形式来组织代码，函数相对于应用来说要更轻量，交付速度也更快。但是这种模式的缺点就是改造成本高，因为很多应用原来是一个巨大的单体或者微服务应用，很难改造成函数模式。
SAE 采用了 Kata 安全容器技术，从时间和开源界的事实来说，Kata 是 runV 和 Clear Container 两个项目的结合，相比于 Firecracker 以及 gVisor 方案更加成熟。
此前，应用设计需要考虑读写分离，需要连接不同的数据源处理读写分离的结果，并且这些功能都需要写入应用程序代码。而现在，这些功能可以直接利用数据库的水平扩展能力来实现，数据库技术的发展极大地避免了我们直接和数据层交互。
在一个简单的微服务架构中，如果某应用处于整个链路的入口位置，它的前端一般会挂上负载均衡组件（上图中的应用 A），以承接来自于最终用户的业务请求。这类应用在进行生命周期管理的时候，复杂度会更高，为了确保应用在新版本发布过程中的平衡稳定，会经过如下的步骤：
