架构师看问题的眼光和别人不一样，不要只看见这一个问题，还要看见这个问题背后是什么，这一类问题背后是什么，我怎么能用抽象的方法解决一类问题。想好了以后，我就把当前的这个问题先解决掉，其他的问题用抽象的方式去解决它。
2019年整个核心系统上云的时候，同样跟技术的广度有关系，我们上云发生了什么变化？整个底座到云上去了，计算、存储、网络全到云上去了，那要了解云啊。我2018年在阿里云注册了个账号，基本把阿里云的云产品全摸了一遍，这时就会对阿里云的网络、技术有本质的了解。
造成 XA 事务无法提供快照读功能的核心原因是我们缺乏一个全局时钟来排序每个事务，每个事务和视图在不同的 DN 上可能是不同的顺序。因此在 PolarDB-X 2.0 中，我们引入了基于 XA 事务优化的 TSO 事务。TSO 事务需要一个生成全局单调递增 Timestamp 的策略，常见的策略有 True Time（Google Spanner）、HLC（CockroachDB）、TSO（TiDB），在我们目前的实现中，我们使用了 TSO 策略，由 GMS（元数据管理服务）作为一个高可用的单点服务承担生成 Timestamp 的任务。TSO 保证了正确的线性一致性和良好的性能，只是在跨全球机房部署的场景会带来较高的延迟。
原生的 InnoDB 引擎无法满足我们支持 TSO 事务的需求，因此我们修改了 InnoDB 引擎的提交逻辑和可见性判断逻辑，在 XA BEGIN 和 XA COMMIT 前插入了我们自定义的两个变量 SNAPSHOT_TS 和 COMMIT_TS。
• SNAPSHOT_TS 用于判断其他事务提交数据对当前事务的可见性，统一了一个分布式事务在每个分片上进行读取发生的时间。SNAPSHOT_TS 决定了当前事务的快照。
而到 2018 年，随着 Service Mesh 的加入，CNCF 对云原生的定义发生了改变，而这也逐渐成为被大家认可的官方定义：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
团队规模导致的问题
缺乏信任。由于人数众多，难于管理，只能通过制度、流程、规范、绩效约束。
没有责任感。高层管理者忙着开各种决策会议。
部门墙。跨部门协调还不如与第三方合作。
不尊重专业人士。当所有的生杀大权都掌握在少数人手中的时候。
管理层级太深。管理层级太深导致的问题很多。
在涉及敏感数据的行业工作的云原生开发人员更倾向于在本地服务器或私有云上运行代码。与其他行业相比，金融服务领域的云原生开发人员在本地服务器上运行代码的比例高 12%，而医疗保健领域的开发人员的比例高 8%。
他们希望通过本地计算，更好地控制敏感数据。
市场营销、**和房地产领域的云原生开发人员不太可能在本地服务器上运行代码。这些行业的重点是内容，因此需要轻松快速地访问。可访问性和性能对这些领域的成功至关重要，而本地服务器可能无法满足这些要求。
将应用程序的组件部署到单独的进程或容器中以提供隔离和封装。这种模式还可以使应用程序由异构组件和技术组成，该模式被命名为 Sidecar，因为它类似于连接到摩托车的辅助车，辅助车被附加到父应用程序并为应用程序提供支持功能。
