3.第三大块是应用架构，目前我们中台里面做的比较多的叫星环，星环说白了，它想达到架构的本质目的就是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。
这背后带来的问题是什么？我们原来产生用共建的方式支撑了50多个BU的会员、商品、交易、营销、资金、支付、库存逆向等等业务，其实每个里面都是遍地开花的if else。
第一个是形散而神不散。架构其实是每个应用线每个业务线都有。有些技术同学本身就是有架构师的这种角色。阿里很早以前是专门有架构师岗位，专门的去做架构，但是做着做着架构师就做没了。因为很不接地气，它没有解决具体、真实、实际的问题。
针对不同语言，我们只需要实现一次从源代码到LSIF格式的转换，就能将其应用在多种场景。多种代码语言代码语言都会被解析成统一的LSIF格式文件。
开发期间修复并适配了一些lsif-java的问题，如位置范围信息错乱，召回多种遗漏的高亮词类型，适配非Maven仓库的索引构建。同时还修复了Spoon关于无法正确解析注释中的部分注解的问题，PR已被Spoon社区接受合并。
比如看到一个会员，你不能仅仅只看到会员，你要看到会员上面的业务是什么，谁在用会员，这叫全局。同时，会员用的最多的是导购和交易，登录仅仅是会员本身一个很小的业务功能而已。基于会员，我们有导购有交易，把这些东西要串起来看明白，就能完整的认识到会员到底提供了什么，一定要有一个全局视角。
遇山开道、遇水架桥，这讲的是决心。很多时候问题确实很难解决，也需要协调更多的人。很多人可能会放弃。我们最近在做架构的升级，用国产化芯片，从底到上全链路的。
如果有一方配合不到位，这事情就很难推进了。从 4 月份一直到 7 月底被阻碍了两次，第三次如果再没办法开展下去，这个事情就彻底的结束了。我们当时把整个团队召集到一起，互相打气：一定要干成。遇山开道、遇水架桥，有什么问题抛出来，大家一起来解决，要有决心，更要果断。
除此之外，在分布式场景下，由于数据被分散在不同节点，线性一致性（linearizability）也是事务策略的重要特性。
目前主流的分布式数据库都使用了基于两阶段提交（2PC）的策略，包括 Percolator 算法和 XA 协议。
Percolator 是 Google 基于 BigTable 做的分布式系统，一个重要的设计就是使用了 Percolator 算法支持分布式事务。
