前言： 从刚毕业那会儿进入一家大数据企业工作，再到某头部科技公司从事云计算产品设计，之后又在某 AI 独角兽开始接触高性能计算 (HPC)。
回看过去的这些年，在我从行业小白到架构师的成长之路上，「云技术」可以说是伴随我整个工作历程。
借此征文机会也做个小结吧，从三方面谈谈我理解的云原生，知其然也要知其所以然。
- 从虚拟化到云原生
- 业务需求主导技术选型
- 架构设计优化数字化转型
「云技术」是一个相当广的概念，泛指基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术以及应用技术等的总称。
我第一次接触云技术，大概是在 2011 年，中国举办了第一届云计算技术大会。
彼时大家对「云计算」的认知还云里雾里。十年过去了，企业上云已经成为共识。甚至可以说，今天几乎所有企业都在某种程度上依赖着云计算。
我们现在回过头来聊云计算，已经很清楚：云计算 (Cloud Computing) 是一种计算资源交付模型。 其中集成了各种服务器、应用程序、数据和其它资源，并通过 Internet 以服务的形式提供这些资源，且通常对资源进行了虚拟化。
一、从虚拟化到云原生
虚拟化作为云计算中最基础的关键技术，其本质是利用一种逻辑将另一种逻辑进行抽象出来。 也就是用某种技术，将硬件的算力逻辑化，再具象成能多个独立且相互隔离的逻辑主机。
怎么理解虚拟化呢？
比方说最早的时候，大家把业务跑在服务器上面。但物理机就那么几个规格，有些业务可能只用到一半的资源，那能不能把空载的另一半也利用起来呢？
虚拟化就让我们可以在一台物理机上跑很多虚机，虚机有不同的操作系统，它们之间互相隔离且彼此独立。使用上和物理机没有区别，称之为逻辑主机。可以理解为是云计算的 ver 1.0。
我们继续推广「虚拟」的思维 —— 把更多的基础设施、甚至是平台服务进行池化打包，再统一提供 API 接口，IaaS 和 PasS 相继诞生。
再然后是容器，将容器作为一个载体来运行应用和服务。我们还可以将大型的复杂的单体应用分解成很多小的模块来运行，这是「微服务」。
在这个发展过程中，不难看出云计算行业的两个趋势：
一是技术演进让开发人员可以更专注于应用程序，而非基础设施；
二是开发模式趋向于将大型复杂的单体应用程序分解为小模块执行单元。
这个发展历程至当下，便是「云原生」了。具体来讲，云原生包含了以下三个方面：
- 把应用程序切分为多个微服务；
- 再把每个部分打包成容器；
- 并且动态地编排这些容器以优化系统资源。
在 Gartner 2022 年顶级战略技术报告中提及：当前能够帮助企业完成数字化转型与信息流变现的技术趋势中，云原生平台 (Cloud Native Platforms) 首当其冲。
报告预测：至 2025 年，云原生平台将成为 95% 以上新数字计划的基础，而在 2021 年尚不足 40%，发展空间充分
二、业务需求主导技术选型
从「知道」到「读懂」云技术，还有关键的一步 —— 理解业务需求。
技术的提出，可能是实验室里研究员的灵光乍现。而技术的应用，则需要用户的使用和企业的支持。换句话来说：上云可能我已经知道了，但是我为什么要用云原生呢？
重点在于「交付业务价值」，构建和整合基础架构所产生的工作量不能成为负累：
一方面是成本：
云原生减少了操作系统虚拟化这层的资源损耗，也就变相降低了服务器的成本。在架构层面，云原生将应用程序切分成很多的微服务，并打包成容器，拆分粒度更细，切分的资源成本也就更小。
另一方面是增效：
云原生可以实现分布式调度和链路追踪，更好地去观察业务的运行状态，相当于辅助企业的整个平台。另外，围绕云原生的一些 DevOps 工具链，也让效能提升得更好，不用时刻纠结于开发与测试之间不一致的环境等等。
这两点是云原生的优势。鉴于数字化转型过程中代码重构的工作量，一般建议企业在满足自身业务需求的情况下，尽可能选择标准接口、协议的方式，或者直接使用业界事实标准来进行云原生的改造。
近年来，企业级软件的市场环境发生了很大改变，公开透明的开源模式逐渐成为主流。
下图是 Intel 的开源云计算，其中虚线标志表示该项目由 Intel 发起，并且贡献到开源社区的。图里我们能看到包括 IaaS、SaaS、边缘计算和容器运行时等等的开源项目。
其中，开源项目 Kubernetes, AKA K8s 是业界最受欢迎的底层调度平台，也是云原生的基石。在云原生落地实践的过程中，大部分企业会选择 K8s 作为其云原生的底层调度平台。
尽管市面上云原生技术生态蓬勃发展，但这种开源自主的模式，对于技术底蕴较弱的用户而言，还是可能会面临无从下手的困境。
Intel 在帮助企业落地云原生时也看到了一些问题，比方说创建容器时间过长、容器扩展速度慢、资源利用率低等等。
为此，Intel 在 K8s 社区里也做了很多相关工作：
- 基于快照 + 热代码块来创建容器，以解决容器创建时间过长的问题；
- 利用分片式多调度器来面对低吞吐量 / RPS / 突发并发等；
- 通过弹性 POD 自动扩展来加快容器扩展速度；
- 基于遥测的快速预测，用于实时扩展集群的决策；
- 动态插入/删除 POD 中的 Sidecar 容器解决 Sidecar 资源开销的问题
- ……
这些不同类型的技术方案，使其能够根据企业用户所处行业特性、数字初始化复杂程度进行灵活定制。
但是，仅靠软件层面的技术方案仍然差点意思，虽然云原生让开发者更专注于应用层面的研究，可云原生的性能调优对 IT 底层设施的要求可一点都不低。应用想获得最优的性能，需要在基础设施层就提供稳定可靠和极致的性能。
我尝试自下而上，从架构的角度探索云原生的最佳实践。
三、架构设计优化数字化转型
随着越来越多的应用在云原生平台中产生或迁移，与这些现有应用整合的需求只会不断增加。在此背景下，通过架构的设计和搭建选择适合企业自身业务的云原生项目变得尤为重要。
大部分企业在选择了 K8s 作为云原生的底层调度平台后，会随着业务需求的增加，发现无法依托单一的技术来融入云原生生态，继而持续地做「加法」：诸如使用 Prometheus 技术栈来掌握平台情况；而后，又要进行日志管理，开始做相应的微服务架构……
这并没有错，但不是最优解。
一个思想是：用架构思维为云原生做减法！
换言之，用户只需要面对一个产品，就能享受整个云原生团队的服务。这「一个」产品，是不是也可以包含底层硬件？
我们知道 Intel 是芯片厂商。除此之外，Intel 也前瞻性地布局了包括计算、网络、存储、安全在内的全部产品线能够在 K8s 平台快速集成和稳定使用。使得以 K8s 为技术标准的用户，不仅能够在 Intel 平台上获得超预期体验，还能集成各种插件、管理技术，获得更多的功能加速与容器业务的优化。
一直以来，企业级硬件测试与调优，都是耗费 IT 人员精力的大头。现在，以 K8s 为代表的开源软件为核心组件，基于 Intel 云原生技术的硬件，调整架构方式后的软硬全栈方案让云基础设施有更强的弹性伸缩能力支撑上层业务。
架构思维的精髓在于软硬结合，理解底层原理才能更好地实践上层应用。
在当前云原生生态环境下，不同于传统虚拟化平台与硬件之间的弱关联，云原生容器化的平台上，软件应用效率和硬件技术的关系更紧密。
未来算力提升的趋势是异构计算，GPU /FPGA/ASIC 等硬件将发挥更多的能力。
在异构架构中，硬件会越来越多地通过云原生平台，给应用带来价值。软硬件协同一体调试才能让容器平台的运行达到更好的性能。
在基于 K8s 的架构上，Intel 通过优化的技术实践来完成对用户云原生应用场景的支持。而在整个云原生生态层面，Intel 基于长期的技术趋势探索与开源生态共建，来帮助企业用户完成不同技术现状的实践落地。
从知道「云技术」的名词，到接触业务，再到能用架构的思维去看待这项技术，我才能说读懂了。