gydtep

我们将这种结构化的数据上传到ES，然后语法服务后端服务器会基于用户的语法请求，构造ES请求Query，查询定义、引用或注释信息，将其拼装返回。

gydtep

对于分支，我们会持续更新和保留最新版本的索引数据；对于代码评审，我们会构建源分支的每次Push版本和源目标分支的merge-base版本的索引。

gydtep

对局部和全局的问题需要有发现的眼光，更应该有发现未发生问题的能力，哪些是需要治标，哪些需要治本，这个是发现问题的基本判断力。现在系统可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，未来业务可能遇到更严重的问题。架构师看问题的眼光和别人不一样，不要只看见这一个问题，还要看见这个问题背后是什么，这一类问题背后是什么，我怎么能用抽象的方法解决一类问题。想好了以后，我就把当前的这个问题先解决掉，其他的问题用抽象的方式去解决它。

gydtep

每时每刻都在发生技术的升级和变革，只有持续不断的学习，才能对老的架构有新的认识，对于老的问题产生新的解法，要了解业界最近在发生什么变化，这个领域最关键的项目和人在做什么，学习他们的技术，学习他们的论文。我以前每天大概2到3个小时是用来学习。这几个小时的学习时间是我最放松的时间，不用去想太多事。

gydtep

造成 XA 事务无法提供快照读功能的核心原因是我们缺乏一个全局时钟来排序每个事务，每个事务和视图在不同的 DN 上可能是不同的顺序。因此在 PolarDB-X 2.0 中，我们引入了基于 XA 事务优化的 TSO 事务。TSO 事务需要一个生成全局单调递增 Timestamp 的策略，常见的策略有 True Time（Google Spanner）、HLC（CockroachDB）、TSO（TiDB），在我们目前的实现中，我们使用了 TSO 策略，由 GMS（元数据管理服务）作为一个高可用的单点服务承担生成 Timestamp 的任务。TSO 保证了正确的线性一致性和良好的性能，只是在跨全球机房部署的场景会带来较高的延迟。

gydtep

原生的 InnoDB 引擎无法满足我们支持 TSO 事务的需求，因此我们修改了 InnoDB 引擎的提交逻辑和可见性判断逻辑，在 XA BEGIN 和 XA COMMIT 前插入了我们自定义的两个变量 SNAPSHOT_TS 和 COMMIT_TS。

gydtep

2015 年由 Linux 基金会发起了一个 The Cloud Native Computing Foundation（CNCF） 基金组织，CNCF基金会的成立标志着云原生正式进入高速发展轨道，Google、Cisco、Docker 各大厂纷纷加入，并逐步构建出围绕 Cloud Native 的具体工具，而云原生这个的概念也逐渐变得更具体化。因此，CNCF 基金最初对云原生定义是也是深窄的，当时把云原生定位为容器化封装+自动化管理+面向微服务：

gydtep

The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

gydtep

下面介绍云原生架构的一些关键技术点。涉及内容由微服务、分布式常见架构设计(性能、数据一致性、可扩展性、高可用)、研发流程、DevOps、组织文化等，可以根据目录选择性的看看，基本上都是一些介绍，详细的设计可以查看相关文档进一步了解。

gydtep

分布式架构 - 可扩展设计
水平扩展，指用更多的节点支撑更大量的请求。
横向扩展通常是为了提升吞吐量，响应时间一般要求不受吞吐量影响即可。