对于应用交付的整个流程而言，通常会涉及三个环节，即开发、测试和运维，而在传统的组织架构中，他们对应的也往往是三个不同的团队。这三个环节各自有自己的侧重点，但是在实际上，想要让整个应用交付过程变得顺滑高效，并且让应用在上线后保持高可用的状态，往往需要三个团队将相互之间存在的墙打破掉。
果采用云托管模式，实际上是在基础设施层去构建应用，应用构建的抽象层次是比较低的，因此会带来大量工作，用户自己需要整合不同的组件和服务，需要进行大量的决策和实现，交付的速度会比较慢，需要考虑很多的事情，而且在运维方面有大量的重复工作。
最后分享一些比较成功的案例。阿里Serverless计算支撑了阿里集团小程序平台，节省了40%研发资源。阿里云 Serverless 支撑语雀使用函数计算实现文档等计算密集型业务，大幅度地降低了运维成本，还为石墨文档降低了58%的运维成本，帮助微博提升了研发效能，使得功能上线时间从原本的2周变为几小时。
索引构建的另外一个难点是增量计算。如上文所述，语法服务索引构建对资源的要求非常高，而现实中代码库不可避免地会存在频繁提交的现象。如此引申出了两个优化点：
利用增量的方式减少存储内容的变更，加快索引构建速度。
利用分布式时序锁减少频繁请求带来的压力。
第三大块是应用架构，目前我们中台里面做的比较多的叫星环，星环说白了，它想达到架构的本质目的就是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。
第一点就是沟通能力非常关键。你怎么把这个问题说清楚，切中问题的点，同时也能帮助上下游带来实际的效果。第二点是架构需要能救火，但不仅仅是救眼前的火，应该救未来的火，架构师救火能力要很强。
要将技术的先进性转化为业务的先进性，忘掉屁股。这个“忘掉屁股”就是你做很多事情不是你一个人能搞定的，复杂、越大的事情是要协同更多的人。如果你就是为了你自己，比如说KPI去做事，我告诉你，这个事情做一次两次可以，但后面就没人跟你配合。你一定要忘掉屁股，才能慢慢的把这个事情做成，真正做到你想要的结果。
如果在提交阶段我们发现事务只涉及了一个分片，那么我们就会将其优化为一阶段提交，使用 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。
下面介绍云原生架构的一些关键技术点。涉及内容由微服务、分布式常见架构设计(性能、数据一致性、可扩展性、高可用)、研发流程、DevOps、组织文化等，可以根据目录选择性的看看，基本上都是一些介绍，详细的设计可以查看相关文档进一步了解。
当这些 BaaS 云服务日趋完善时，Serverless 因为屏蔽了底层设施的运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless 计算包含以下特征：
