容器是操作系统级别的虚拟化技术，共享操作系统内核，分为独立的用户空间，可以运行软件的实例，做到了解耦。适用于微服务的架构。
云计算通常具有下列特点：①超大规模；②虚拟化；③高可靠性；④通用性；⑤高可扩展性；⑥按需服务；⑦极其廉价；⑧潜在的危险性。
DevOps 可以看作是开发、技术运营和质量保障三者的交集，促进之间的沟通、协作与整合，从而提高开发周期和效率。而云原生的容器、微服务等技术正是为 DevOps 提供了很好的前提条件，保证 IT 软件开发实现 DevOps 开发和持续交付的关键应用。换句话说，能够实现 DevOps 和持续交付，已经成为云原生技术价值不可分割的内涵部分，这也是无论互联网巨头企业，还是众多中小应用开发公司和个人，越来越多选择云原生技术和工具的原因。
云原生架构有着以下优势：通过对多元算力的支持，满足不同应用场景的个性化算力需求，并基于软硬协同架构，为应用提供极致性能的云原生算力；基于多云治理和边云协同，打造高效、高可靠的分布式泛在计算平台，并构建包括容器、裸机、虚机、函数等多种形态的统一计算资源；以“应用”为中心打造高效的资源调度和管理平台，为企业提供一键式部署、可感知应用的智能化调度，以及全方位监控与运维能力。
传统云计算的 3 层概念，即基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。
IaaS(基础设施即服务)向用户提供计算机能力、存储空间等基础设施方面的服务。
功能性特性是真正为业务带来价值的代码，比如建立客户资料、处理订单、支付等；
非功能性特性是没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
高度自动化的软件交付：软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。软件交付的困难在于开发环境到生产环境的差异(公司环境到客户环境之间的差异)以及软件交付和运维人员的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。
韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间(Mean Time Between Failure，MTBF)。从架构设计上，韧性包括 服务异步化能力、重试限流/降级/熔断/反压、主从模式、集群模式、AZ 内的高可用、单元化、跨 region 容灾、异地多活容灾等。
Mesh 化架构是把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很 “薄” 的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通信，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。
分布式环境中的 CAP 困难主要是针对 有状态应用，因为无状态应用不存在 C(一致性)这个维度，因此可以获得很好的 A(可用性)和 P(分区容错性)，因而获得更好的弹性。在云环境中，推荐把各类暂态数据(如 session)、结构化和非结构化持久数据都采用云服务来保存从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，这时可以考虑通过采用时间日志+快照(或检查点)的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。
微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。1）传统采用 XA 模式，虽然具备很强的一致性，但是性能差。2）基于消息的最终一致性(BASE)通常有很高的性能，但是通用性有限。3）TCC 模式，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高。4）SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段，而是每个正向事务都对应一个补偿事务，也是开发维护成本高。5）开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。
事件驱动架构不仅用于(微)服务解耦，还可应用于下面的场景中。1)增强服务韧性：由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被上游感知，自然也就不会对上游带来影响。2)CQRS(Command Query Responsibility Segregation)：把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的 API 接口；结合 EDA 中的 Event Sourcing 机制可以用于维护数据变更的一致性，当需要重新构建服务状态时，把 EDA 中的事件重新“播放”一遍即可。3)数据变化通知：在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。4)构建开放式接口：在 EDA 下，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景—数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。5)事件流处理：应用于大量事件流(而非离散事件)的数据分析场景，典型应用是基于 Kafka 的日志处理。
Docker 容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。更重要的是，Docker 提出了创新的应用打包规范--Docker 镜像，解耦了应用与运行环境，使应用可以在不同计算环境一致、可靠地运行。借助容器技术呈现了一个优雅的抽象场景：让开发所需要的灵活性、开放性和运维所关注的标准化、自动化达成相对平衡。容器镜像迅速成为了应用分发的工业标准。Kubernetes 提供了分布式应用管理的核心能力：资源调度——根据应用请求的资源量 CPU、Memory，或者 GPU 等设备资源，在集群中选择合适的节点来运行应用。
Serverless 计算包含以下特征：1) 全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；2) 通用性，结合云 BaaSAPI 的能力，能够支撑云上所有重要类型的应用；3) 自动弹性伸缩，让用户无需为资源使用提前进行容量规划；4) 按量计费，让企业使用成本得有效降低，无需为闲置资源付费。
服务网格(ServiceMesh)是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的 连接、安全、流量控制 和 可观测 等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化。
