而到 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.
Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统，每个服务都以一个独立进程的方式运行，每个服务与其他服务使用轻量级（通常是 HTTP API）通信机制。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署，同时服务会使用最小规模的集中管理（例如 Docker）能力，也可以采用不同的编程语言和数据库。
事务的四大特征
原子性（Atomicity）。
一致性（Consistency）是指通过事务保证数据从一种状态变化到另一种状态。
隔离性（Isolation）是指事务内的操作不受其他操作影响，当多个事务同时处理同一个数据的时候，多个事务之间是互不影响的。
持久性（Durability）是指事务被提交后，应该持久化，永久保存下来。
流水线
持续交付：降低交付周期，通过自动化工具实现设计、开发、测试、发布、运维各个阶段的重复性工作，通过工具实现标准化、规范化，降低出错概率。
免运维、极致弹性、极致成本
托管服务器资源，不需要用户自己运维服务器，同时也相应地具备极致弹性和极致成本的能力。
因为云产品有几百多款，如果要每一款都用好也是额外成本。所以我们对最常用的云服务进行了一体化集成，包括基础监控、业务监控 ARMS、NAS 存储、SLS 的日志收集等各方面，降低用户使用产品的门槛。
最后 SAE 可以根据压测模型配置相应的弹性策略，比如根据 CPU memory、RT 或者 QPS 等，在有容量模型的情况下设置行业策略，达到非常贴合实际使用量的效果，实现低成本及架构的最大化升级。
高可用设计主要有三个原则，包括可观测、可灰度、可回滚。大部分云研发场景并不需要关注可演变，但在一些特殊场景下可演变仍然是一个问题。比如，蚂蚁的金融业务需要和一些机构进行信息交换，由于金融领域的RPC交互常常使用标准化文件，在文件场景下如何保证可演变也是高可用设计需要关注的内容。典型的用于提高架构可用性的设计原则包括四种：解耦、冗余、异构和异步。
在应用生命周期管理以及服务治理方面， Kubernetes 提供了比较完善的实现机制，通过构建 Deployment 资源，配合 proStop 和 postStart 脚本，能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（引入 Service Mesh 技术能增强流量控制力，不在本文讨论范围），但相比简单的发布脚本，已经有了飞跃性的提升。
Serverless Kubernetes 架构虽然能适配所有的业务场景，但对于开发者而言，构建一整套 Kubernetes 体系，需要掌握一系列跟 Kubernetes 相关复杂的概念，有着非常陡的学习曲线。而且 Kubernetes 生态中各种组件的搭建，再加上网络层与存储层的适配，都涉及非常复杂的工作。
