《企业级云原生白皮书项目实战》——第二章 云原生发展历史及现状——2.2 云原生的发展及现状（上） https://developer.aliyun.com/article/1229475?groupCode=supportservice
图 2.2云原生架构演进
如图 2.2云原生架构的演进过程可以看作是基础能力的逐渐下沉以及业务代码的纯粹度提升。
微服务架构模式是云原生应用的标准架构模式，通过微服务架构，将一个庞大的应用拆分为不同的模块，解耦后，各个模块独立自治，单独维护，以接口契约定义彼此业务关系，以标准协议确保彼此的互联互通，提高了系统的整体迭代速度，也能有效降低单个庞大系统的风险。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但是也需要注意到，服务拆分导致要维护的模块数增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。
Mesh架构模式主要是采用sidecar模式，将业务逻辑和辅助业务的其他内容分离，让业务更专注于业务部分，非业务能力部分下沉，这样业务逻辑将不会受非业务逻辑的影响，mesh部分即可实现独立更新扩展。具体地，Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后业务进程只保留客户端部分代码，客户端的只与Mesh进程通信，原来需要在SDK中处理的流程和逻辑则由Mesh进程完成。
Serverless模式，从中文含义上翻译为“无服务”，但并不是没有服务器了，而是服务器被云管理了，不论是在开发测试还是部署上，都无需感知服务器的存在，唯一需要感知的只有业务逻辑，非业务逻辑的代码，存储，网络，部署都不需要感知，这些能力将会全部下层到基础设施层，是一种比较理想化的云原生架构模式。目前Serverless并不适用于所有类型的应用，需要使用者决策应用类型是否适用于Serverless运算。在决策过程中可以考虑以下几方面：
1.应用是否有状态。对于有状态的应用，Serverless在调度时不会对应用的状态做同步，因此在调度时会导致上下文的丢失；
2.是否为I/O密集型应用。对于需要频繁的外部I/O的应用，通常因为I/O负担繁重，导致时延大而不适用于Serverless；
3.应用是否事件驱动。Serverless适用于应对突发流量或服务使用量不可预测的应用，因为Serverless应用在不运行时不收费；
4.业务是否需要快速开发迭代。Serverless无需提前申请资源，因此可以加快业务上线的速度。
