云原生架构设计原则
云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。
容器：云原生世界技术爆炸的奇点
1 安全容器
容器技术的采纳率连年提升，已经开始进入企业的生产环境。以 Docker 为代表的普通容器通过 Namespaces 和 cGroups 实现的隔离，共享内核的机制使得隔离性具有天然的缺陷无法根除，在多租户场景下安全问题更加凸显。
2 Serverless 容器
FaaS（Function as a Service）平台提供的是函数级别的 Serverless 化部署，且应用场景多依赖于其绑定的触发器，对函数的执行有一些配置限制，并且不支持进程常驻。传统的应用大都是单体应用或者微服务应用，在迁移到 FaaS 平台时，需要拆分函数，迁移成本较高。
Serverless 容器，可以很好地弥补 FaaS 的不足，Serverless 容器可以支持进程常驻的服务形态，不限运行时长，并扩大 Serverless 的应用场景。Serverless 容器支持服务的形态，传统的单体应用或者微服务应用，几乎可以无缝迁移到 Serverless 容器平台上。
3 裸金属容器
容器服务最早部署形态是基于 IaaS 虚拟机，以虚拟机节点作为容器集群的计算节点，并基于此构建容器的网络、存储和编排能力，这样的堆叠架构虽然可以让整个软件栈分工明确、边界清晰，但是带来了较大的性能损耗和功能冗余。此外如果用户对实例安全隔离性要求较高，就需要借助虚拟化技术，而虚拟化平台不能很好支持该能力。基于以上痛点，在裸金属服务器上搭建容器服务成为一些对性能和实例隔离性较高用户的选择。
从软件架构的演化来看，微服务架构的出现是用户需求、开发周期以及市场规模变化下的必然发展。在单体架构中，应用大多数通过瀑布式模型进行开发，计划、开发、测试、上线等阶段单独进行，以整个应用为单位进行开发、维护。这种开发模式与印刷术出现之前的手写时代相似。
手写卷很难根据场景复用，有按需更新或修改的部分则需要整体重构。借由类比，单体架构的优点和缺点都十分明显：在小型应用中整体从设计到上线的速度很快，其中的管理工作简单；但是在需要更新和修改的情况下，应用整体高度聚合，各部分高耦合，牵一发而动全身，常常需要整体重新开发。
无服务器是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注业务本身。在无服务器架构的理念和方法下，有很多种无服务器的技术形态，目前成熟落地的有 3 种形态，函数即服务（FaaS）、后端即服务（BaaS）和Serverless 容器。
云原生芯片
云原生技术的应用普及对云计算的上下游技术也产生了革命性的影响，芯片技术首当其冲。引发芯片云原生化演进的原因主要有两个，一是应用负载模型的精细化、动态演进，要求芯片内核技术升级。从架构设计上，芯片内核的线程处理分割需要更加细粒度，独立内核需要有独享的二级缓存，来能够最大程度的去适应云原生环境中需要平行扩展的微服务化应用，为用户提供更高性价比的服务；二是超大规模数据中心和边缘数据中心的需求猛增，这两类数据中心在延时、散热、功耗等需求与传统数据中心不同，这对 CPU 的部署密度和能耗的要求越来越高，基于 ARM架构的芯片成为云原生芯片的主要发展方向，比较典型的产品有阿里云的倚天 710 芯片、AWS 的Graviton 系列芯片等。
云原生网络
云原生网络的基本目标是满足云原生服务的网络端点和服务间的互通性、安全性和负载均衡要求。Kubernetes 已经成为容器编排的事实标准，容器网络也需与 Kubernetes 的调度机制相匹配。
容器网络接口 CNI(Container Network Interface) 是现行的网络接口标准， CNI 接口只实现创建、删除容器时的调用方法，其他所有的网络能力都交由网络厂商实现增值服务，这在一定程度上加速了网络方案的繁荣，但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择，根据网络协议的不同，可将网络方案分为路由模式、Overlay和 L2 方案三种。
