云原生技术与架构实践年货小红书.pdf

云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 2 前言前言 回顾过去一年，云原生将科技创新与商业元素不断融合、重构，重新定义了新业态下的增长极。随着云原生在中国各行业广泛深入，云原生新技术不断演进、优秀开源项目大量涌现，云原生架构实践进入“火箭式”发展阶段。云原生在通过方法论、工具集和最佳实践改变着整个软件技术栈和生命周期，云原生架构对云计算服务方式与互联网架构进行整体性升级，这让企业和开发者更加聚焦于业务本身并借助云原生技术与产品实现更多业务创新，有效提升企业增长效率，爆发出前所未有的生产力与创造力。所以，这一本年货小红书应运而生。这里是阿里云一整年的云原生技术内容合集，本书超过 1500 页，接近 70 万字。涵盖容器、微服务、Serverless、云原生架构设计、云原生架构实践、架构师与开发者成长等多个内容方向，沉淀了阿里云以及诸多企业的行业技术解决方案与案例，并有阿里云云原生技术大咖推荐工具、课程等多维度知识扩展内容。希望你喜欢，并分享给身边的小伙伴。新年快乐!云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 4 目录目录 第一章 2021 年云原生行业趋势洞察篇.5 第二章 容器篇.9 2.1 Kubernetes 在不同场景下的实践.9 2.2 Kubernetes 系列课程.174 第三章 微服务&中间件篇.177 3.1 SpringCloud 应用在 Kubernetes 上的最佳实践.177 3.2 Dubbo3.0 前瞻.232 3.3 Dubbo-go 实践.282 3.4 Istio 实践.339 3.5 RocketMQ&Nacos&ChaosBlade 等实践.385 3.6 微服务系列课程.441 第四章 SERVERLESS篇.442 4.1 Serverless 基础.442 4.2 Serverless 轻松搭建系列.485 4.3 Serverless 迁移系列.518 4.4 Serverless 解惑.526 4.5 Serverless 实践.561 4.6 函数计算开发实践.630 4.7 Serverless 系列课程.669 第五章 架构设计篇.672 5.1 架构设计思想.672 5.2 架构设计图教学.780 第六章 技术实践篇.811 6.1 企业云原生实践.811 6.2 Nacos 实践.844 6.3 Dubbo 实践.892 6.4 Serverless 实践.927 6.5 Spring Cloud Alibaba&ChaosBlade 等实践.943 第七章 DEVOPS篇.1002 7.1 DevOps 入门.1002 7.2 敏捷研发.1023 7.3 代码管理与架构.1042 7.4 持续交付.1072 第八章 架构师与开发者成长篇.1102 8.1 成长路径规划.1102 8.2 如何快速成长.1157 8.3 代码撰写.1187 8.4 协作沟通.1213 8.5 其他知识补全.1242 第九章 温故知新.1362 云原生技术与架构实践年货小红书 生于云，长于云，爆发于云 5 第一章第一章 2 2021021 年云原生行业趋势洞察篇年云原生行业趋势洞察篇 阿里云技术专家解读：阿里云技术专家解读：2021 2021 年六大容器技术发展趋势年六大容器技术发展趋势 2020 终于过去。在这一年，特殊的环境让企业的生存和发展充满着不确定性。在持续应对由变化带来的挑战过程中，数字化创新能力对于企业来说似乎比以往任何时候都更加重要。疫情之下，越来越多的企业坚定了上云和实现数字化转型的信念和步伐，并且积极探索云原生架构转型落地。2020 年 双 11，阿里巴巴实现了核心系统全面云原生化的重大技术突破。基于云原生架构，企业可以最大化使用云的能力，聚焦于自身业务发展，开发者也可以基于云原生的技术和产品，提升开发效率，将精力更多地聚焦于业务逻辑的实现。可以看出，以容器为代表的云原生技术正在成以容器为代表的云原生技术正在成为释放云价值的最短为释放云价值的最短路径路径。作为云原生发展的基石，容器技术的新趋势和新挑战备受关注。2021 2021 年伊始，阿里云容器服务团队的技年伊始，阿里云容器服务团队的技术专家们为大家带来了他们对新一年容器技术趋势的六个重要解读术专家们为大家带来了他们对新一年容器技术趋势的六个重要解读。趋势一：以趋势一：以 Kubernetes Kubernetes 为代表的容器技术，已成为云计算的新界面为代表的容器技术，已成为云计算的新界面 在最新发布的“CNCF 2020 年中国云原生调查”中显示，有 72%的中国受访者在生产中使用了 Kubernetes。过去一年，我们观察到的阿里云上云原生生态的蓬勃发展也印证着云原生技术正成为释放云价值的最短路径。从早期的无状态应用、到 AI 大数据和存储类应用都在拥抱容器技术。可以看见，以 Kubernetes 为代表的容器技术已成为云计算的新界面，并将继续带来更大价值。1.1.企业从上云，到通过云原生加速分布式云管理企业从上云，到通过云原生加速分布式云管理 l 对于企业来讲，容器持续向下封装基础设施，屏蔽底层架构的差异性。l 而 Kubernetes 的新界面进一步促进云和边的基础能力对齐，推动“边”的产品能力丰富度和标准化，从而加速容器应用在边缘、IoT 和 5G 等场景的落地。2.2.容器应用的高密高频挑战，持续重构（容器应用的高密高频挑战，持续重构（RefactorRefactor）云计算的架构）云计算的架构 l 在容器应用的高密高频的应用场景推动下，面向容器优化的 OS、裸金属协同、硬件加速等技术持续演进，进一步催熟云计算架构的全栈优化和软硬一体，并给云计算用户带来极致的敏捷、弹性等红利。l 而在容器新界面之上的 Serverless、新一代的中间件、新一代的应用 PaaS 方兴未艾。3.3.容器大规模应用进入深水区，在自动化运维、企业容器大规模应用进入深水区，在自动化运维、企业 IT IT 治理、端到端安全等迎来挑战治理、端到端安全等迎来挑战 l 随着越来越多的工作负载、AI 大数据、数据库等应用容器化，如何统一容器和基础资源形成统一的人、财、物、权等企业 IT 治理能力，是大规模落地容器的关键述求。l 随着越来越多的自定义控制器、越来越丰富的云原生制品格式，如何保障大规模 K8s 集群的稳定性带来强需求，而数据化智能化的 K8s 自动化集群运维和细粒度的 SLO 能力更加迫切。云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 6 l 零信任安全、容器身份认证、云原生制品生命周期管理、安全容器、机密计算等 DevSecOps 实践，持续打造端到端的容器安全网。趋势二：围绕云原生应用的高度自动化趋势二：围绕云原生应用的高度自动化 得益于 Kubernetes 面向终态的理念，云原生架构天然具备高度自动化的能力。在应用云原生化的过程中会充分享用到自动化带来的优势，副本数维持、版本一致性、错误重试、异步事件驱动等能力，相比过去面向过程的运维模式而言是一次新理念、新技术带来的进步。在这片蓬勃发展的土壤之上，如何围绕云原生、为应用打造更加自动化的基础设施是未来 2021 年探索的重点方向之一：l 应用部署运维更加自动化应用部署运维更加自动化：云原生业务类型及其多样化，不管是传统 IT、互联网，还是 Web 服务、搜索、游戏、AI、边缘等细分领域，每一种都会有自身特殊应用场景，而抽象、提炼出其中核心通用的部署运维诉求并转化为更加自动化的能力则是深耕云原生的必经之路。l 风险防控能力更加自动化风险防控能力更加自动化：面向终态的自动化是一把“双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大，例如在发生操作故障时副本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩大。因此，通过防护、拦截、限流、熔断等防控自动化能力来抑制其他功能性自动化能力的缺陷和副作用，是伴随着云原生规模急剧扩大的必要防护措施。l Operator Operator 运行时更加自动化运行时更加自动化：Kubernetes 能成为容器集群调度管理引擎的事实标准，其强大而又灵活的扩展能力功不可没。Operator 既是一种特殊的应用，也是不少有状态应用的自动化管理者。而过去社区整体 Operator 趋势还停留在数量野蛮增长、周边运行时机制却无太大进步，2021 年 Operator 的运行时将会在水平扩展、灰度升级、租户隔离、安全防护、可观测性等方面获得充分的自动化增强。趋势三：以“应用”为中心构建高可扩展的上层平台趋势三：以“应用”为中心构建高可扩展的上层平台 随着容器技术的进一步成熟，越来越多的企业开始关注容器技术如何更好的为业务带来价值。我们可以看到以 Kubernetes 为交付界面的云原生生态日益庞大，越来越多的团队会基于 Kubernetes 构建上层抽象，增加更多的扩展能力，以“应用”为中心构建高可扩展的云原生平台。l 基于基于 KubernetesKubernetes 与标准应用模型构建的易用、可扩展的上层平台将取代传统与标准应用模型构建的易用、可扩展的上层平台将取代传统 PaaSPaaS 成为主成为主流流。当前云原生生态的软件虽然日益丰富，但是学习和使用门槛依旧非常高，易用性将成为“以应用为中心”的首要突破点。除此之外，在易用的同时保证可扩展性，保证以 Kubernetes 为接入点的开源软件无需或只要较小改造便可接入使用，也是这样类型应用管理平台的重要特征。l“关注点分离”的标准化应用构建方式进一步深入人心“关注点分离”的标准化应用构建方式进一步深入人心。围绕 Kubernetes 构建应用交付平台已经逐渐成为共识，任何一个 PaaS 平台都不想把 Kubernetes 屏蔽掉。但是这并不意味着直接把 Kubernetes 所有的信息暴露给用户，PaaS 平台的构建者们极度渴望给用户最佳的体验。解决这个问题的突破点就是大家使用一个标准化的、关注点分离的应用构建模型，平台的构建者们关注 Kubernetes 接口（CRD 和 Operator），而平台的用户，也就是应用开发者们关注的则是一个标准化的抽象应用模型。云原生技术与架构实践年货小红书 生于云，长于云，爆发于云 7 l 应用中间件能力进一步下沉，应用逻辑与中间件逻辑逐步解耦应用中间件能力进一步下沉，应用逻辑与中间件逻辑逐步解耦。随着云原生以及整个生态的发展，中间件领域也在逐步发展变化，从原先的中心化 ESB 到如今通过 Sidecar 模式提供能力的 Service Mesh。应用中间件不再是通过一个胖客户端提供能力，而是成为一个能力的标准接入层，能力的提供则由应用管理平台通过 Sidecar 的方式在应用运行时注入。相信 Sidecar 这种模式将在除流量治理、路由策略、访问控制之外的更多中间件场景中得到应用，“以应用为中心”，让业务更专注，更聚焦。趋势四：“云边一体”迎来快速发展趋势四：“云边一体”迎来快速发展 随着 5G、IoT、直播、CDN 等行业和业务的发展，越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的位置，以期获得很好的响应时间和成本，这是一种明显区别于传统中心模式的计算方式边缘计算。未来，边缘计算将存在三个非常明显的发展趋势：l AI、IoT 与边缘计算的融合，边缘计算场景中业务种类会越来越多、规模越来越大、复杂度越来越高。l 边缘计算作为云计算的延伸，将被广泛应用于混合云场景，这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力。l 5G、IoT 等基础设施的发展将会引爆边缘计算的增长。边缘计算的规模、复杂度正逐日攀升，而短缺的运维手段和运维能力也终于开始不堪重负。在这个背景下，“云边端一体化运维协同”已经开始成为一种架构共识。通过云原生加持，云边融合的进程也正在被急剧加速：l“云”层，让我们保留了原汁原味的云原生管控和丰富的产品能力，通过云边管控通道将之下沉到边缘，使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载。l“边”侧，通过流量管理和服务治理使其更好的和端进行交互，获得和云上一致的运维体验，更好的隔离性，安全性以及效率，从而完成业务、运维、生态的一体化。边缘计算云原生即是云原生的新边界，也是边缘计算的新未来。趋势五：云原生趋势五：云原生 AI AI 只是起点，云原生驱动数据变革是新主题只是起点，云原生驱动数据变革是新主题 数据是企业的核心资产，云原生为了更好地支撑企业 IT 数字化和智能化转型，拥抱数据驱动应用是其未来几年中最重要的使命之一。除了生在 Docker 里、长在 Kubernetes 下的云原生 AI 之外，如何能让传统的大数据和 HPC 应用也平滑迁移到 Kubernetes 平台上来，实际上也是云原生社区需要回答的问题。我们看到的趋势是致敬传统任务调度器、容器化资源精细调度、弹性数据任务全新场景、AI 与大数据的统一云原生底座。l 致敬传统任务调度器致敬传统任务调度器:Kubernetes 关注于资源调度，但是对于大数据和 HPC 的调度功能比起 Yarn 等离线传统调度器还有很多需要借鉴的地方，最近在 Kubernetes 的 Scheduler Plugin Framework 的灵活框架下，适配于大数据和 HPC 场景的批量调度，Capacity 调度正在逐步落地。l 容器化资源精细调度容器化资源精细调度：Kubernetes 利用容器特性和插件化调度策略，可以原生地支持 GPU 资源共享调度，并且可以进行 GPU 资源隔离，Nvidia Ampere 的调度也在 Kubernetes 上做了 Mig 原生云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 8 支持。这也是 Kubernetes 独特的能力。而资源共享不仅仅限于 GPU，对于 RDMA，NPU 甚至存储设备，这种调度能力都是必不可少的。l 弹性数据弹性数据任务全新场景任务全新场景：随着大数据和 AI 应用的弹性化越来越普及，如何让数据也有弹性的能力，让数据像流体一样，在诸如 HDFS、OSS、Ceph 等存储源和 Kubernetes 上层云原生应用之间，灵活高效地移动、复制、驱逐、转换和管理，推动广阔云服务场景下的大数据、AI 落地新应用。l AI AI 与大数据的统一云原生底座与大数据的统一云原生底座：基于作业调度、资源利用率优化和数据编排这些原子能力，越来越多 AI、机器学习平台和大数据分析平台构建在容器集群之上。而 AI 与大数据对数据的依赖度，对计算、网络和存储资源的需求特点、工作负载特征、运行策略、对在线服务的重要性，甚至影响企业 IT 成本的因素，都有很多相似之处。因此如何以统一的云原生底座同时支持 AI 和大数据作业，将成为企业 CTO、CIO 思考的主题之一。趋势六：容器安全成为重中之重趋势六：容器安全成为重中之重 容器已经成为应用交付的标准，也是云原生时代计算资源和配套设施的交付单元。以 runC 为代表的使用 linux container 技术实现的容器运行时，以轻量、高效、自包含、一次打包到处运行等优秀特性，深受广大容器开发者和使用者的喜爱。容器技术及应用日渐普及，正成为云计算的新界面。但云计算下的容器技术正面对新的挑战。多个容器共享了同一内核，在隔离和安全性方面必然存在天然缺陷，并进一步限制了容器的应用场景和发展，使其只能应用于企业内部环境等单租场景。但云原生产品交付给不同租户的容器，即使运行在同一台宿主机上也必须具备强隔离的安全保证；在云原生产品时代，容器运行时除了需继续保持轻量、高效、自包含、一次打包到处运行的优秀特性外，还需进一步确保良好的安全隔离性，容器安全成为重中之重。以 KATA 为代表的使用轻量虚拟化实现的容器时逐渐成为多租场景的标准容器运行时。除了运行时的安全隔离，网络、磁盘、镜像、K8s API 等层面的安全隔离也是必须要解决的问题。涉及到多租户和运行不可信代码，用户可接触到的一切资源都是需要隔离的，包含网络可达的目标，可以使用的存储，可以下载或本地访问的镜像内容都需要隔离。为了防止隔离实现本身有漏洞被用户利用，安全防护需要多层次的深度防护，网络防护除了 VPC 隔离，还需要网络策略细化隔离；计算的隔离除了虚拟化技术的隔离还需要有命名空间、系统调用等方面的隔离；存储的隔离除了有虚拟化相关的隔离，还需要在宿主机上面做 DiskQuota 隔离；镜像的隔离除了要做网络隔离，还需要做本地的镜像引用隔离。这些实现都是向强隔离、多层深度隔离方向发展。容器安全技术也面对其它新的挑战：引入虚拟化后，容器技术实现不再轻量，如何对虚拟化技术优化，并尽可能轻量、高效成为我们必须要解决的问题；业界也有像 Google 的 gVisor 和 Crosvm、Amzon 的 Firecracker 等轻量虚拟化支持容器化的技术，阿里内部也有相应的 Daishu 虚拟化容器技术来解决这个问题。云原生技术与架构实践年货小红书 生于云，长于云，爆发于云 9 第二章第二章 容器篇容器篇 2 2.1.1 KubernetesKubernetes 在不同场景下的实践在不同场景下的实践 容器技术之发展简史容器技术之发展简史 “云原生技术有利于各组织在公有云、私有云和混合云公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式容器、服务网格、微服务、不可变基础设施和声明式 APIAPI。”聊容器技术避不开云原生，聊云原生也避不开容器技术。容器技术和云原生就是一对双螺旋体，容器技术容器技术催生了云原生思潮，云原生生态推动了容器技术发展催生了云原生思潮，云原生生态推动了容器技术发展。从 2013 年 docker（container）技术诞生，到 2015 年 CNCF 这个云原生领域重量级联盟便成立，这不是历史的巧合而是历史的必然。作为云原生关键技术之一的容器，从 2013 年诞生以来一直是行业关注的焦点之一。借用一张业界广泛引用的云原生容器技术进阶图来了解一下容器技术和云原生诞生的历史背景。先让我们一起来看看容器技术发展的历史纪年表，先直观感受一下这片如火如荼的热土吧！1979 年，Unix v7 系统支持 chroot，为应用构建一个独立的虚拟文件系统视图。1999 年，FreeBSD 4.0 支持 jail，第一个商用化的 OS 虚拟化技术。2004 年，Solaris 10 支持 Solaris Zone，第二个商用化的 OS 虚拟化技术。2005 年，OpenVZ 发布，非常重要的 Linux OS 虚拟化技术先行者。2004 年 2007 年，Google 内部大规模使用 Cgroups 等的 OS 虚拟化技术。2006 年，Google 开源内部使用的 process container 技术，后续更名为 cgroup。2008 年，Cgroups 进入了 Linux 内核主线。2008 年，LXC（Linux Container）项目具备了 Linux 容器的雏型。2011 年，CloudFoundry 开发 Warden 系统，一个完整的容器管理系统雏型。2013 年，Google 通过 Let Me Contain That For You(LMCTFY)开源内部容器系统。2013 年，Docker 项目正式发布，让 Linux 容器技术逐步席卷天下。2014 年，Kubernetes 项目正式发布，容器技术开始和编排系统起头并进。2015 年，由 Google，Redhat、Microsoft 及一些大型云厂商共同创立了 CNCF，云原生浪潮启云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 10 动。2016 年-2017 年，容器生态开始模块化、规范化。CNCF 接受 Containerd、rkt 项目，OCI 发布 1.0，CRI/CNI 得到广泛支持。2017 年-2018 年，容器服务商业化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，华为 CCI，Oracle Container Engine for Kubernetes；VMware，Redhat 和 Rancher 开始提供基于 Kubernetes 的商业服务产品。2017 年-2019 年，容器引擎技术飞速发展，新技术不断涌现。2017 年底 Kata Containers 社区成立，2018 年 5 月 Google 开源 gVisor 代码，2018 年 11 月 AWS 开源 firecracker，阿里云发布安全沙箱 1.0。2020 年-202x 年，容器引擎技术升级，Kata Containers 开始 2.0 架构，阿里云发布沙箱容器 2.0.整理容器技术近 20 年的发展历史，大致可以将其分为四个历史阶段，下文将详细介绍这四个历史阶段。技术萌芽期技术萌芽期 容器技术需要解决的核心问题之一是运行时的环境隔离。容器的运行时环境隔离，目标是给容器构造一个无差别的运行时环境，用以在任意时间、任意位置运行容器镜像。由于 docker 的布道，大家习惯性认为容器的运行时环境隔离就是 OS 虚拟化，或者容器等于 namespace+cgroup+安全防护机制。我不太赞同这种看法，这个只是一段历史时期、一种容器运行时的实现技术，还有很多种其它可能的技术方案来实现容器运行环境。所以，回到需求的本源：容器需要运行时隔离技术来保证容器的运行环境符合预期容器需要运行时隔离技术来保证容器的运行环境符合预期。习惯上，大家把这种实现容器隔离技术的组件叫做容器运行时。从另外一个角度看，容器隔离技术解决的是资源供给问题容器隔离技术解决的是资源供给问题。为啥需要容器隔离技术来解决资源供给问题呢？成也萧何，败也萧何！摩尔定律实在太过强大，它让我们有了越来越多的计算资源可以使用。10 年前做小型机时，小型机的典型规格是 32 路 8 核 CPU，现在一台 4 路 PC 服务器计算能力都超过 10 年前的小型机服务器。小型机的典型用法是把整机切分为多个分区使用。观察当下云服务硬件发展趋势，越来越有熟悉的感觉，我们在把小型机相关技术“军转民”。现在我们一台 PC 服务器拥有了非常强大的、能和十年前小型机媲美的计算能力，巧合的是当下 PC 服务器的典型用法也和十年前的小型机用法类似，切割为 1-8vCPU 的虚拟机/容器使用。为什么人们总是习惯于把一个大的服务器资源切分为小的分区使用而不是研发能够充分发挥大型服务器整机计算能力的软件呢？个人认为背后有两个制约因素：云原生技术与架构实践年货小红书 生于云，长于云，爆发于云 11 l 待解决问题本身内在的并行度有限待解决问题本身内在的并行度有限。随着多核多处理器系统的日益普及，IT 行业从 2004 年开始进行串行编程到并行编程的升级改造。开始阶段针对特定行业应用的并行化改造效果非常明显，但是后来发现随着并行度提高改造成本越来越大、收益却越来越低。受阿姆达尔定律制约，解决特定问题的并行度超过一定临界点之后收益将逐渐变小。所以一味提高系统并行度并不是经济的做法。l 人类智力有限人类智力有限。受人类智力限制，系统越复杂、并行度越高，软件越容易出故障，软件维护代价成指数级增长。所以，从软件工程看，大家也趋向于接口化、模块化、单元化的软件架构设计，尽量控制软件的复杂度，降低工程成本。从经验看，1-8 个 CPU 的并行度是软件工程的舒适区，这个也是容器化、微服务等技术背后的驱动因素之一。有点跑题了。总之，基于隔离的资源供给不是伪需求。对于软件运行环境的隔离要求，从操作系统出现之初就有了。多任务分时操作系统和进程虚拟地址都是为了解决多个任务运行在同一台主机上的资源共享问题，让每个进程都以为自己独占主机。当然仅仅是进程隔离是远远不够的。纵观当前的资源隔离技术，我们大致可以将资源隔离技术分成 5 类：l 进程隔离进程隔离。OS 以进程作为 Task 运行过程的抽象，进程拥有独立的地址空间和执行上下文，本质上 OS 对进程进行了 CPU 和内存虚拟化。但是进程之间还共享了文件系统、网络协议栈、IPC 通信空间等多种资源，进程之间因为资源争抢导致的干扰很严重。这个层级的隔离适合在不同的主机上运行单个用户的不同程序，由用户通过系统管理手段来保证资源分配与安全防护等问题。l OS OS 虚拟化虚拟化。OS 隔离，也就是大家常说的操作系统虚拟化（OS virtualization），是进程隔离的升华版。进程隔离是为每个进程实现了单独的地址空间及 CPU 上下文，OS 隔离则是利用操作系统分身术为每一组进程实例构造出一个独立的 OS 环境，以进一步虚拟化文件系统、网络协议栈、IPC 通信空间、进程 ID、用户 ID 等 OS 资源。OS 隔离需要解决三个核心问题：独立视图、访问控制及安全防护。Chroot、Linux namespace 机制为进程组实现独立视图，cgroup 对进程组进行访问控制，而 Capabilities、Apparmor、seccomp 等机制则实现安全防护。当然，OS 是一个非常复杂、动态变化的系统，OS 分身术虽然让进程组感觉有了独立的 OS，但是真实实现还是一个 OS 实例，所以整体防护能力还是堪忧。l 硬件虚拟化硬件虚拟化。OS 虚拟化是实现 OS 内核的分身术，而硬件虚拟化则是实现硬件设备的分身术。硬件虚拟化技术的出现，让同一个物理服务器上能够同时运行多个操作系统，每个操作系统都认为自己在管理一台完整的服务器。不同操作系统之间是严格隔离的，Guest 操作系统对硬件的访问都是受 VMM 或 CPU 的严格监管的。硬件虚拟化既有很好的安全性，也有很好的隔离性，缺点就是引入的硬件虚拟化层导致了额外的性能开销。l 硬件分区硬件分区。这个是传统小型机体系采用的资源分隔技术，就是从硬件或固件层彻底把一台大型服务器分隔为多个硬件单元，从而获得最高等级的安全性和隔离性。但是小型机作为一个逐步没落的技术路线，其不足之处还是显而易见的：资源分隔粒度不灵活、系统成本偏高、系统可扩展性受限。云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 12 l 语言运行时隔离语言运行时隔离。对于 Java、nodejs 等需要 language runtime 的 managed language，我们还有一个选项，就是在 language runtime 里实现隔离。针对函数计算等云原生服务，理论上在语言运行时实现隔离机制是最优路径。但是这条路线目前实现上还有不少现实的制约，所以目前多数函数计算还是采用的容器/VM 技术来实现的隔离。在 OS 虚拟化这条技术路线上，最大的技术贡献来源于 Google。2003-2006 年，Google 陆续发布的“三驾马车”，奠定了大数据计算的框架，随后进一步创造了“云”的概念。也是从这时期开始，进程隔离技术进入了一个更高级的阶段。在 Google 提出的云计算框架下，被隔离的进程不仅仅是一个与外界隔绝但本身却巍然不动的 Jail，它们更需要像一个个轻便的容器，除了能够与外界隔离之外，还要能够被控制与调配，从而实现分布式应用场景下的跨平台、高可用、可扩展等特性。2006 年，Google 推出 Process Containers，用来对一组进程进行限制、记账、隔离资源（CPU、内存、磁盘 I/O、网络等）。由于技术更加成熟，Process Container 在 2006 年正式推出后，第二年就进入了 Linux 内核主干，并正式更名为 Cgroups，标志着 Linux 阵营中“容器”的概念开始被重新审视和实现。在 2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace（命名空间）的视图隔离能力组合在一起，一项完整的容器技术 LXC（Linux Container）出现在了 Linux 内核中，这就是如今被广泛应用的容器技术的实现基础。总体看，在总体看，在 2013 2013 年年 docker docker 被发明以前，被发明以前，Linux Linux 操作系统已经大体上解决了容器核心技术之一的运行操作系统已经大体上解决了容器核心技术之一的运行环境隔离技术，或者说环境隔离技术，或者说 Linux OS Linux OS 虚拟化技术已经基本上成型了虚拟化技术已经基本上成型了。虽然容器运行环境隔离技术已经基本就位，我们仍需等待另外一项关键技术才能迎来容器技术的腾飞时刻。技术迸发期技术迸发期 2013 年之前，云计算行业一直在为云原生的正确打开姿势而操心。Platform as a Service（PaaS）看起来是个有前途的方向。2006 年 Fotango 公司发布的 Zimi 服务，可以说是 PaaS 行业的鼻祖，具有按使用付费、免运维（Serverless）、API 化配置和服务等典型云原生的特征；2008 年 Google 推出 GAE；2011 年 Pivotal 发布 Cloud Foundry。这些早期的 PaaS 平台进行了非常有益的探索，推动了云计算生态的健康发展，但是这些早期探索技术并没有形成大的行业趋势，而是局限在一些的特定的领域。直到 Docker 开源，大家才如梦方醒，原来不是方向不对，而是应用分发和交付的手段不行。Docker 真正核心的创新是容器镜像（docker image），一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境运行环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版操作系统发行版无关的不可变更不可变更软件包。l 容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的操作系统，从而实现“build once，run anywhere”。l 容器镜像一旦构建完成，就变成 read only，成为不可变基础设施的一份子。l 操作系统发行版无关，核心解决的是容器进程对操作系统包含的库、工具、配置的依赖，但是容器镜像无法解决容器进程对内核特性的特殊依赖。这个在实际使用容器的过程中也经常跳进这个大坑：云原生技术与架构实践年货小红书 生于云，长于云，爆发于云 13 Docker 的宣传口号是“Build，Ship and Run Any App，Anywhere”。我们已经理解了 docker 通过container image 解决“Run Anywhere”的机制，那么“Run Any App”是如何实现的呢？其实也是依赖 container image，用户可以打包任何容器进程所依赖的环境，而不用改造应用来适配 PaaS 定义的运行环境。真是“Run Any App”一举打破了 PaaS 行业面临的困境，创造出了无限的可能性，大力推动了云原生的发展。让我们一起来向这个伟大的创意致敬！至此，容器技术体系已经解决了最核心的两个问题：如何发布软件如何发布软件和如何运行软件如何运行软件，腾飞时刻即将到来。2014 年前司前老板对我说“别成天搞 Linux kernel 了，要不你看看 docker？”经过短暂的调研，我给了前老板一个简单而清晰的回答，“无它，唯打包工具尔！”因为这个回答，云原生为我打开的一扇大门就悄悄关上了。回想一下历史，有时也挺懊悔的，因为自己太年轻而没有看清楚容器技术+编排系统的威力，更没有体会到云原生即将到来的气息！Docker 作为一个单机软件打包、发布、运行系统，其价值是非常巨大的；但是仅仅将 docker 技术局限在单机范围不能发挥这个创新技术的最大价值，自然下一步业界希望基于 docker 技术构建一个云化的集群系统，来对业务容器进行编排管理。聊到容器编排系统，我们需要从 Google 聊起。2008 年，Google 基于 LXC 推出首款应用托管平台 GAE（Google App Engine），首次把开发平台当做一种服务来提供。GAE 是一种分布式平台服务，Google 通过虚拟化技术为用户提供开发环境、服务器平台、硬件资源等服务，用户可以在平台基础上定制开发自己的应用程序并通过 Google 的服务器和互联网资源进行分发。Google 在 GAE 中使用了一个能够对 LXC 进行编排和调度的工具 Borg（Kubernetes 的前身）。Borg 是 Google 内部使用的大规模集群管理系统，可以承载十万级的任务、数千个不同的应用、同时管理数万台机器。Borg 通过权限管理、资源共享、性能隔离等来达到高资源利用率。它能够支持高可用应用，并通过调度策略减少出现故障的概率，提供了任务描述语言、实时任务监控、分析工具等。如果说一个个隔离的容器是集装箱，那么 Borg 可以说是最早的港口系统，而 LXC+Borg 就是最早的容器编排框架。2013 年 docker 推出之后迅速席卷全球，2014 年 Google 基于内部使用的 Borg 系统创建了开源项目 Kubernetes（简称 K8s），用于解决大规模集群的容器部署、运行、管理等问题。Kubernetes 在容器的基础上增加了一层的新的管理抽象 Pod，以便更好地利用容器进行应用的功能模块切分。得益于 Google 云原生技术与架构实践年货小红书 阿里巴巴云原生系列电子书 14 在大规模集群基础设施建设的强大积累，脱胎于 Borg 的 K8s 很快成为了行业的标准应用，堪称容器编排的必备工具。作为回应，Docker 公司在 2015 年发布的 Docker 1.12 版本中也加入了一个容器集群管理系统 Docker swarm，以及配套的 Docker machine、Docker Compose 等工具，力图构建完善的容器编排系统，和 Kubernetes 展开正面竞争。从此，容器江湖分为两大阵营：Google 派和 Docker 派；而容器编排系统则是 Kubernetes，Docker Swarm 和 Apache Mesos 三国并立。各大派系的竞争愈演愈烈，逐渐延伸到行业标准的建立之争。让我们一起来回忆一下这段风起云涌的江湖历史吧！2013 年 Docker 公司推出 docker 之后，紧接着 CoreOS 应运而生。CoreOS 是一个基于 Linux 内核的轻量级操作系统，专为云计算时代计算机集群的基础设施建设而设计，拥有自动化、易部署、安全可靠、规模化等特性。其在当时有一个非常显眼的标签：专为容器设计的操作系统专为容器设计的操作系统。借着 Docker 的东风，CoreOS 迅速在云计算领域蹿红，一时间，Docker+CoreOS 成为业内容器部署的黄金搭档。同时，CoreOS 也为 Docker 的推广与社区建设做出了巨大的贡献。然而，日渐壮大的 Docker 似乎有着更大的“野心”。不甘于只做“一种简单的基础单元”的 Docker，自行开发了一系列相关的容器组件，同时收购了一些容器化技术的公司，开始打造属于自己的容器生态平台。显然，这对于 CoreOS 来说形成了直接的竞争关系。2014 年末，CoreOS 推出了自己的容器引擎 Rocket（简称 rkt），试图与 Docker 分庭抗礼。rkt 和 Docker 类似，都能帮助开发者打包应用和依赖包到可移植容器中，简化搭环境等部署工作。rkt 和 Docker 不同的地方在于，rkt 没有 Docker 那些为企业用户提供的“友好功能”，比如云服务加速工具、集群系统等。反过来说，rkt 想做的，是一个更纯粹的业界标准。上面这段材料引至于“从虚拟化到云原生容器技术的发展史”，为什么大段大段地引用这部分材料呢？这里面最关键的脉络是由于技术公司之间的商业竞争，在竞争合作之间寻找平衡从而导致了标准规由于技术公司之间的商业竞争，在竞争合作之间寻找平衡从而导致了标准规范的诞生，而标准范的诞生，而标准规范的诞生是整个云原生生态最重要的基石规范的诞生是整个云原生生态最重要的基石。容器引擎（docker vs rocket）、容器编排