可能有的开发者会认为，目前的业务运行非常的稳定，在用户流量上并不存在明显的突增，所以扩容和缩容是一个伪需求，在将来也不会有这样的需求。这可能是对互联网业务的一种误解，因为完全没有扩容需求的情况是不存在的。
然而，每个团队对于应用的迭代都会有自己的节奏，与此同时，他们又想拥有独立的端到端测试环境，从而实现环境之间的隔离，以避免团队之间的相互影响。这样的话，很有可能会形成多套测试环境：
前面两种其实就是为了最终一致性做铺垫，因为数据同步是牺牲了一部分实时的性能，所以我们需要做数据分区，做中心封闭，这样才能保证用户请求的及时响应和数据的实时准确性。
针对不同计算场景，容器运行时有不同的需求。比如在传统数据中心，基于操作系统虚拟化的 RunC/Docker 容器可以很好地满足大部分业务需求；如何提升更好的安全隔离能力？KataContainer，Firecracker, gVisor, Unikernel 等新技术层出不穷。但是没有任何一款容器技术可以在安全隔离性、执行效率和通用性上都做到完美。我们在相当长的一个历史阶段，依然可以看到多种技术路线并存和多彩纷呈的竞争。OCI（Open Container Initiative）标准的出现，可以对不同的技术采用一致的方式进行容器生命周期管理，进一步促进了容器引擎技术的持续创新。
阿里云在 2018 年 5 月推出 ECI（Elastic Container Instance 弹性容器实例）、ASK (Alibaba Cloud Serverless Kubernetes) 等产品，并在 2019 年 2 月正式商业化。目前业界所有公有云厂商都推出了 Serverless 容器产品，除阿里云 ASK/ECI 外，还包括 AWS Fargate, Azure ACI，华为 CCI，腾讯 EKS, GCP CloudRun 等。
蚂蚁的大部分业务已经实现云盘存储，也就是将日志存储到远方磁盘。此前，单体应用通常将数据存储于本机磁盘，并且不提供其它冗余备份；而云盘则默认提供数据冗余，这在基于日志不可靠假设进行应用设计时带来了很多变化。
线下业务和淘宝业务实际上使用同一个版本进行应用开发和发布，它们的隔离仅仅体现在流量和部署层面。比如，它们所使用的交易服务在开发层面就是完全相同的，仅仅在部署层面将它们的流量分离到不同的服务中。这样，在以业务维度做跨节点的流量绑定时，就需要将几个服务及其节点圈出来进行分流。
服务端下沉和抽象化、原子化，提供标准的、原子的领域能力，由 S2C 体系进行能力的理解，并通过需求的约束对调用逻辑：胶水层代码 进行生成。
其实对于错埋和多埋的修复场景，就是在上报SDK前这一时机进行计算。
至此，一个解决埋点热修问题的计算框架原理基本完成。框架主要围绕三件事情展开：
一，向JSContext补充API提供基础计算能力。
二，补充数据源为计算提供物料。
三，补充触发计算的时机。
以上了解了 12-Factor 应用原则。在我们学习 K8s 的过程中，个人认为 K8s 结合service mesh 很好的满足了上面的每条原则。设计 K8s 和 ServiceMesh 的人很伟大，提出 12 原则的 AdamWiggins 很伟大。
