云原生应该具备以下特性：
 
存储与计算分离
 
节点对等
 
独立扩展
 
灵活扩容
 
快速容错

背景
 
近几年，云原生和容器技术非常火爆，且日趋成熟，众多企业慢慢开始容器化建设，并在云原生技术方向上不断的探索和实践。基于这个大的趋势， 2020 年底 Qunar 也向云原生迈出了第一步——容器化。
 
云原生是一系列可以为业务赋能的技术架构准则，遵循它可以使应用具有扩展性、伸缩性、移植性、韧性等特点。云原生也是下一代技术栈的必选项，它可以让业务更敏捷。通过实践 DevOps、微服务、容器化、可观测性、反脆弱性(chaos engineering)、ServiceMesh、Serverless 等云原生技术栈，我们便可以享受到云原生带来的技术红利。
 
Qunar 容器化发展时间线
 
一项新技术要在企业内部落地从来都不是一蹴而就的，Qunar 的容器化落地也同样如此。Qunar 的容器后落地主要经历了 4 个时间节点:
 
 
2014 - 2015:
 
业务线同学开始尝试通过 Docker、Docker-Compose 来解决联调环境搭建困难的问题，不过由于 Docker-Compose 的编排能力有限、无法解决真实的环境问题，因此容器化最后也没有推行起来。
 
 
2015 - 2017: 
 
ops 团队把为了提高 ELK 集群的运维效率，把 ES 集群迁移到了 Mesos 平台上。后来随着 K8s 生态的成熟，把 ES 集群从 Mesos 迁移到了 K8s 平台，运维效率得到了进一步的提升。
 
 
2018 - 2019: 
 
在业务需求不断增加的过程中，业务对测试环境的交付速度和质量有了更高的要求，为了解决 MySQL 的交付效率问题( 并发量大时，网络 IO 成为了瓶颈，导致单个实例交付时长在分钟级)，为了解这个问题，我们把 MySQL 容器化，通过 Docker on host 的模式可以在 10 秒之内就可以交付一个 MySQL 实例。
 
 
2020 - 2021: 
 
云原生技术已经非常成熟了，Qunar 也决定通过拥抱云原生来为业务增加势能。在各个团队齐心协力的努力下，300+ 的 P1、P2 应用已经完成了容器化，并且计划在 2021 年年底全部业务应用实现容器化。
 
 
落地过程与实践
 
容器化整体方案介绍
 
Qunar 在做容器化过程中，各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造，改造后的架构矩阵如下图所示。
 
 
 
Portal：Qunar 的 PaaS 平台入口，提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。
 
 
运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （Java 应用在线 Debug）、qtrace（tracing 系统）、loki/elk（提供实时日志/离线日志查看）。
 
 
中间件：应用用到的所有中间件，mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。
 
 
虚拟化集群：底层的 K8s 和 OpenStack 集群。
 
 
Noah：测试环境管理平台，支持应用 KVM/容器混合部署。
 
 
CI/CD 流程改造
 
 

 CI/CD 改造前
 
 

 CI/CD 改造后
 
主要改造点:
 
 
应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起，为容器发布提供统一的声明式配置。
 
 
授权系统: 应用所有的授权操作都通过一个入口进行，并实现自动化的授权。
 
 
K8s 多集群方案: 通过调研对比，KubeSphere 对运维优化、压测评估后也满足我们对性能的要求，最终我们选取了 KubeSphere 作为多集群方案。
 
 
中间件适配改造
 
改造关注点：由于容器化后，IP 经常变化是常态，所以各个公共组件和中间件要适配和接受这种变化。
 
 
应用平滑迁移方案设计
 
为了帮助业务快速平滑地迁移到容器，我们制定了一些规范和自动化测试验证等操作来实现这个目标。
 
 
 
容器化的前置条件: 应用无状态、不存在 post_offline hook（服务下线后执行的脚本）、check_url 中不存在预热操作。
 
 
测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级，并在测试环境部署和验证，如果升级失败会通知用户并提示。
 
 
线上验证: 第一步线上发布，但不接线上流量，然后通过自动化测试验证，验证通过后接入线上流量。
 
 
线上 KVM 与容器混部署：保险起见，线上的容器和 KVM 会同时在线一段时间，等验证期过后再逐步下线 KVM。
 
 
线上全量发布: 确认服务没问题后，下线 KVM。
 
 
观察: 观察一段时间，如果没有问题则回收 KVM。
 
 
容器化落地过程中碰到的问题
 
如何兼容过去 KVM 的使用方式，并支持 preStart、preOnline hook 自定义脚本？
 
KVM 场景中 hook 脚本使用场景介绍：
 
 
preStart hook : 用户在这个脚本中会自定义命令，比如环境准备。
 
 
preOnline hook：用户会定义一些数据预热操作等，这个动作需要在应用 checkurl 通过并且接入流量前执行。
 
 
问题点：
 
K8s 原生只提供了 preStop、postStart 2 种 hook, 它们的执行时机没有满足上述 2 个 KVM 场景下业务用到的 hook。
 
分析与解决过程:
 
 
preStart hook：在 entrypoint 中注入 preStart hook 阶段，容器启动过程中发现有自定义的 preStart 脚本则执行该脚本，至于这个脚本的位置目前规范是定义在代码指定目录下。
 
 
preOnline hook：由于 preOnline 脚本执行时机是在应用 checkurl 通过后，而应用容器是单进程，所以在应用容器中执行这个是行不通的。而 postStart hook 的设计就是异步的，与应用容器的启动也是解耦的， 所以我们初步的方案选择了 postStart hook 做这个事情。实施方案是 postStart hook 执行后会不断轮询应用的健康状态，如果健康检测 checkurl 通过了, 则执行 preOnline 脚本。脚本成功后则进行上线操作, 即在应用目录下创建 healthcheck.html 文件，OpenResty 和中间件发现这个文件后就会把流量接入到这个实例中。
 
 
按照上面的方案，Pod 的组成设计如下：
 
 
发布过程读不到标准输入输出
 
场景介绍：
 
在容器发布过程中如果应用启动失败，我们通过 K8s API 是拿不到实时的标准输入输出流，只能等到发布设置的超时阈值，这个过程中发布人员心里是很焦急的，因为不确定发生了什么。如下图所示，部署过程中应用的更新工作流中什么都看不到。
 
 
问题点:
 
K8s API 为什么拿不到标准输入输出？
 
分析与解决过程：
 
 
通过 kubectl logs 查看当时的 Pod 日志，什么都没有拿到，超时时间过后才拿到。说明问题不在程序本身，而是在 K8s 的机制上；
 
 
查看 postStart Hook 的相关文档，有一段介绍提到了 postHook 如果执行时间长或者 hang 住，容器的状态也会 hang 住，不会进入 running 状态, 看到这条信息，大概猜测到罪魁祸首就是这个 postStart hook 了。
 
 
 
基于上面的猜测，把 postStart hook 去掉后测试，应用容器的标准输入可以实时拿到了。
 
找到问题后，解决方法也就简单了，把 postStart hook 中实现的功能放到 Sidecar 中就可以解决。至于 Sidecar 如何在应用容器的目录中创建 healthcheck.html 文件，就需要用到共享卷了。新的方案设计如下：
 
 
使用上述方案后，发布流程的标准输入输出、自定义 hook 脚本的输出、Pod 事件等都是实时可见的了, 发布过程更透明了。
 
并发拉取镜像超时
 
场景介绍：
 
我们的应用是多机房多集群部署的，当一个应用的新版本发布时，由于应用的实例数较多，有 50+ 个并发从 harbor 拉取镜像时，其中一些任务收到了镜像拉取超时的报错信息，进而导致整个发布任务失败。超时时间是 kubelet 默认设置的 1 分钟。
 
分析与解决：
 
通过排查最终确认是 harbor 在并发拉取镜像时存在性能问题，我们采取的优化方案是通用的 p2p 方案，DragonFly + Harbor。
 
 
并发大时授权接口抗不住
 
场景介绍：
 
应用发布过程中调用授权接口失败，K8s 的自愈机制会不断重建容器并重新授权，并发量比较大，最终把授权服务拖垮。
 
我们的容器授权方案如下:
 
 
Pod init 容器启动时进行调研授权接口进行授权操作，包括 ACL 和 mysql 的白名单。
 
 
容器销毁时会执行 Sidecar 容器的 preStop hook 中执行权限回收操作。
 
 
 
问题点:
 
ACL 授权接口涉及到了防火墙，QPS 比较低，大量容器进行 ACL 授权时把服务拖垮 。
 
分析与解决：
 
为了解决上述的问题，限量和降低授权接口调用次数是有效的解决方式。我们采取了下面几个措施:
 
 
init 容器中的重试次数限制为 1 次。
 
 
授权接口按应用和 IP 限流， 超过 3 次则直接返回失败，不会再进行授权操作。
 
 
ACL 中涉及的一些通用的端口，我们统一做了白名单，应用无需再进行授权操作。
 
 
Java 应用在容器场景下如何支持远程 Debug
 
KVM 场景 Debug 介绍：
 
在开发 Java 应用的过程中，通过远程 Debug 可以快速排查定位问题，因此是开发人员必不可少的一个功能。Debug 具体流程: 开发人员在 Noah 环境管理平台的界面点击开启 Debug, Noah 会自动为该 Java 应用配置上 Debug 选项，-Xdebug -Xrunjdwp: transport=dt_socket, server=y, suspend=n, address=127.0.0.1:50005，并重启该 Java 应用，之后开发人员就可以在 IDE 中配置远程 Debug 并进入调试模式了。
 
 
容器场景的 Debug 方案：
 
测试环境的 Java 应用默认开启 Debug 模式，这样也避免了更改 Debug 重建 Pod 的过程，速度从 KVM 的分钟级到现在的秒级。当用户想开启 Debug 时，Noah 会调用 K8s exec 接口执行 socat 相关命令进行端口映射转发，让开发人员可以通过 socat 开的代理连接到 Java 应用的 Debug 端口。
 
问题点：
 
容器场景下在用户 Debug 过程中，当请求走到了设置的断点后，Debug 功能失效。
 
分析与解决过程：
 
 
复现容器场景下 Debug，观察该 Pod 的各项指标，发现 Debug 功能失效的时候系统收到了一个 liveness probe failed，kill pod 的事件。根据这个事件可以判断出当时 liveness check 失败，应用容器才被 kill 的，应用容器重启代理进程也就随之消失了，Debug 也就失效了。
 
 
关于 Debug 过程 checkurl 为什么失败的问题，得到的答案是 Debug 时当请求走到断点时，整个 JVM 是 hang 住的，这个时候任何请求过来也会被 hang 住，当然也包括 checkurl，于是我们也特地在 KVM 场景和容器场景分布做了测试，结果也确实是这样的。
 
 
临时解决方案是把断点的阻断级别改为线程级的，这样就不会阻断 checkurl 了, idea 中默认的选项是 Suspend All，改为 Suspend Thread 即可。不过这个也不是最优解，因为这个需要用户手工配置阻断级别，有认知学习成本。
 
 
 
 
回到最初的问题上，为什么容器场景下遇到这个问题，而 KVM 没有，主要是因为容器场景 K8s 提供了自愈能力，K8s 会定时执行 liveness check, 当失败次数达到指定的阈值时，K8s 会 kill 掉容器并重新拉起一个新的容器。
 
 
那我们只好从 K8s 的 liveness 探针上着手了，探针默认支持 exec、tcp 、httpGet 3 种模式，当前使用的是 httpGet，这种方式只支持一个 url, 无法满足这个场景需求。经过组内讨论， 最后大家决定用这个表达式 (checkurl == 200) || (socat process && java process alive) 在作为应用的 liveness 检测方式，当 Debug 走到断点的时候, 应用容器就不会阻断了， 完美的解决了这个问题。
 
 
以上就是我们落地容器化过程中遇到的几个问题与我们的解决思路。其中很重要的一点是从 KVM 迁移到容器时需要考虑用户的使用习惯、历史功能兼容等要点，要做好兼容和取舍，只有这样容器化落地才会更顺畅。
 
未来展望
 
多集群稳定性治理
 
 
让可观测性数据更全面、覆盖度更广，进而完善我们的 APM 系统，提升排查问题效率。
 
 
通过实施混沌工程来验证、发现和消除容器化场景的稳定性盲区。
 
 
提高资源利用率
 
 
根据业务指标实现弹性扩缩容。
 
 
根据应用的历史数据智能的调整 requests。
 
 
ServiceMesh 方案落地
 
我们是基于 Istio 和 MOSN 以及当前的基础架构做的 mesh 方案，目前在测试阶段，这套方案落地后相信会让基础架构更敏捷。
 
作者
 
邹晟 去哪儿网基础平台技术专家

**5月26日， 2021云原生产业大会在北京正式举办。**云原生产业大会由中国信息通信研究院主办，中国信通院云计算开源产业联盟、中国信通院云原生产业联盟、云原生计算基金会（CNCF）支持。
 来自云原生领域的顶级专家、国内外IT巨擘、云原生头部企业等近1000位嘉宾齐聚一堂，分享前沿的云原生技术与实践，共同探讨云原生发展趋势，为云原生未来发展指明方向。
 谐云作为国内最早一批进行云原生底层技术研究和行业落地的厂商，在云原生方面积累了丰富的技术成果和实践经验。2021云原生产业大会，谐云在多项成果上交出了满意答卷。
 
1
 中国工程院院士陈纯视频致辞
 
本次云原生大会特邀浙江大学陈纯院士进行开场致辞，陈院士在致辞中指出了云原生发展的重要性，并从三个方面分析了云原生产业发展的意义和趋势：从技术特征来看，云原生具有极致的弹性能力、故障自愈能力以及大规模可复制能；从应用价值来看，云原生实现了异构资源标准化，加速了数字基础设施升级，提升了业务应用的迭代速度；从产业融合来看，云原生为其他信息技术大规模应用提供了重要支撑。
 
陈纯院士还提到，云计算正面临重要发展机遇，抓住机遇实现核心技术的突破与产业的发展离不开人才的培育。浙大曾是云计算领域云原生行业的黄埔军校，为云原生行业输送了大量顶尖人才。谐云的创始团队也是来源于浙大并深根浙大，正在践行云原生时代的使命担当。
 
 
2
 谐云与上汽集团共建的网络安全应急平台荣获云原生优秀案例
 
云原生优秀案例评选作为此次大会的亮点于今日揭晓。云原生优秀案例的评选标准从企业规模与应用范围、云原生应用架构、结合行业特色的云原生服务特点、应用/技术创新点、应用效益以及企业资质等维度进行，评选出云原生应用方面成功实践的企业，特别是将传统应用架构重构为云原生应用架构的实践案例。
 
**谐云与上汽集团携手打造的网络安全应急响应平台项目荣获云原生优秀案例。**谐云根据上汽集团的特性和需求，使用微服务、DevOps及低代码集成技术，完成云原生架构升级的落地，助力上汽集团全面实现云原生化，实现降本增效，是谐云在汽车行业的又一经典标杆案例。
 
 
3
 谐云专家助力云原生行业及DevOps工作组
 
云原生成熟度高级专家授牌
 谐云CTO苌程受聘担任云原生成熟度高级专家，在本次大会上，信通院云计算与大数据研究所所长何宝宏为专家组颁发聘书。
 
 
云原生产业联盟DevOps工作组专家授牌
 谐云产品总监林科受聘担任云原生产业联盟DevOps工作组专家并领取聘书。
 
 
谐云自2011年开始云原生底层技术的研发和实践，团队有不可多得的实践及技术人才，持续不断的为云原生的落地和实践进行推广。
 
4
 《云计算开放应用架构》联合发布
 
**会上，由阿里云计算有限公司、杭州谐云科技有限公司、中国信息通信研究院等 10 余家单位联合发起的《云计算开放应用架构》标准文件在“云原生产业大会”现场发布。**该架构以阿里云、微软云联合发起的开源项目“开放应用架构模型”为实现基础，旨在为云端应用管理者提供统一的应用描述规范及开放应用程序能力管理框架，以期推动简洁、高效、可控的云原生应用管理与交付方式在更多行业和企业中的大规模落地。
 
作为核心发起单位代表，阿里云云原生产品研发负责人李小平表示：开放、标准、敏捷是云原生技术得以快速发展的关键。云原生正在帮助企业打通数字化落地的‘最后一公里’，在这样的关键节点下，需要全行业的共同定义和建设。
 
谐云一直致力于帮助企业进行数字化改革和实践，本次受邀联合发布《云计算开放应用架构》，谐云将继续深度参与云原生行业生态建设，分享云原生落地实践和经验。
 
 
5
 “后Kubernetes时代的云原生技术探索和实践”分享
 
在云原生基础设施分论坛上，谐云云原生平台产品总监徐运元分享了后Kubernetes时代的云原生技术探索和实践。
 
谐云在长达九年的技术自研道路上，坚持创新，积极探索，勇于实践，开发出了EBPF、中间件平台、边缘计算平台等产品，推出了针对各个行业的云原生解决方案，已经助力百余家企业成功实现云原生落地，全面拥抱云原生。
 
 
本次会议，谐云在多方面得到了来自行业、客户和专家们的肯定和认可。未来，谐云将继续秉承“底层核心技术+ 超前发展理念”，推动云原生技术创新和产业发展，为数字中国建设贡献力量。

 
云原生基础架构的组成以及云原生应用的特征
 
云原生的基础架构
1. 微服务
2. 容器
3. 服务网格
5. 声明式 API
  
云原生应用的特征：云原生与“12 因素”
1. 方法论和核心思想
2. 编码、部署和运维原则
3. 具体内容
  
小结

 
云原生的基础架构
 
云原生中既有指导云原生开发的方法论，也包含实践的具体技术。上一篇文章中我们介绍过CNCF 给出的云原生定义中包括微服务、容器、服务网格、不可变基础设施和声明式 API 等代表技术，构建云原生应用就主要靠这些关键技术。下面我们就来具体介绍下这 5 个关键技术。
 
1. 微服务
 
单体应用开发简单，但随着业务复杂度的提升，单体应用的弊端逐渐显现，开发效率和系统应用的可扩展性等方面出现严重问题。微服务架构的出现就解决了这个问题，它根据领域模型将巨大的单体分成界限清晰的微服务，并保持每个服务独立可以迭代（如下图）。
 
 单体应用架构 VS 微服务架构
 
相比传统的单体应用架构，微服务架构具有服务高度自治、高效迭代、易于扩展和支持多语言编程等优点。
 
但是从另一个角度来看，微服务架构的灵活、开发的敏捷也带来了一些新的问题，如数量众多的微服务运维、分布式系统固有的复杂性，以及分布式事务、服务之间的调用等。单体应用可能只需部署至“一个”应用服务器集群，而微服务架构则需要开发维护“很多个”独立的服务，并且还可能需要支持多种语言和环境，这当中的构建、测试、部署和运行成本提高了不少。
 
2. 容器
 
为了解决微服务架构下大量应用部署的问题，由此引入了容器。容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个隔离的操作系统环境，通过一系列的命名空间隔离进程，每个容器都有唯一的可写文件系统和资源配额。
 
容器化功能比较强大，不仅能解决虚拟机所能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。它具有的特点主要包括：隔离应用依赖、创建应用镜像并进行复制、创建容易分发的即启即用的应用、支持实例简单、快速地扩展等。
 
Docker 是当前流行的开源应用容器引擎，基于 Docker 容器化技术，用户可以将微服务及其所需的所有配置、依赖关系和环境变量打包成容器镜像，并轻松移植到全新的安装了 Docker 的服务器节点上，运维人员无须关心底层操作系统，且无须重新配置环境，这使得容器成为部署单个微服务的最理想工具。
 
但仅仅有容器还是不够的，毕竟人工部署成本高且易出错。
 
因此容器技术又被分为了运行和编排两层。运行层主要是指容器的基础设施，包括存储、网络、CPU 等。编排层主要是容器集群的管理，包括容器调度、服务注册与发现、资源的管理等；其相关工具有 Kubernetes 、Swarm 等，用以解决容器的管理和调度问题。其中，由 Google 开源的 Kubernetes 目前基本算是统一了容器编排的市场，实现了容器集群的自动化部署、扩缩容和维护等功能。
 
就这样 Kubernetes 与 Docker 相互配合、相辅相成，其中 Docker 是作为 Kubernetes 内部使用的低级别组件，而 Kubernetes 又可以高效管理调度 Docker 集群。
 
3. 服务网格
 
微服务架构实践主要有侵入式架构和非侵入式架构两种实现形式。侵入式架构是指服务框架嵌入程序代码，开发者组合各种组件，如 RPC、负载均衡、熔断等，实现微服务架构。非侵入式架构则是以代理的形式与应用程序部署在一起，代理接管应用程序的网络且对应用程序透明，这时开发者只需要关注自身业务即可，这种方式以服务网格（Service Mesh） 为代表。
 
服务网格产品的存在和具体工作模式，对运行于其上的云原生应用来说是透明无感知的，但是在运行时这些能力都动态赋能给了应用，从而帮助应用在轻量化的同时依然可以继续提供原有的功能（如下图所示）。
 
 服务网格的一般架构
 
服务网格提供了分布式环境中几大核心问题的解决方案，比如服务间通信、限流、统一认证等功能，使得微服务的开发者更加关注业务，降低了微服务的门槛。
 
服务网格目前的发展也比较火热，有多款开源软件，Linkerd 最早加入 CNCF，其他还有 Istio、Envoy、Dubbo Mesh 等。同时，为了让服务网格有更好的底层支撑，我们又将其运行在 Kubernetes 上。Kubernetes 对于资源的动态调度有极强的能力，用户可以快速编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些烦琐的事情，从而更专注于程序开发。
 
不可变基础设施与 DevOps
 Chad Fowler 于 2013 年提出了不可变基础设施（Immutable Infrastructure） 的构想，主要强调基础设施的状态性质。具体来说：一旦创建基础设施的实例，其将会变成只读状态，如果后续需要修改和升级，则需要使用新的实例替换旧实例。这种模式使得 DevOps 更加容易实践，可以为运维人员减少配置管理的负担。
 
而 DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。DevOps 在一定程度上可以解决开发者与运维人员之间的协作问题，增强开发团队与运维部门之间的沟通和交流。
 
 DevOps 是开发、运维和 QA 三者的交集
 
你可能对精益软件开发中的敏捷、Scrum 不陌生，Scrum 是敏捷的一种具体实践，而 DevOps 则很好地补充了敏捷。DevOps 的目标是缩短开发周期，增加部署频率，更可靠地发布升级系统应用。DevOps 和云原生架构的结合能够实现精益产品开发流程，帮助软件产品及其开发持续改进，适应快速变化的市场，从而为企业提供更小的试错成本。
 
5. 声明式 API
 
声明式设计（Declarative） 是指通过向工具描述自己想要让事物达到的目标状态，然后由这个工具自己内部去计算如何令这个事物达到目标状态。简言之，声明式设计中，描述的是目标状态，即 How；与之相对的是过程式设计（Imperative），所描述的是一系列的动作，即 What。这一系列的动作如果被正确执行，最终结果就是这个事物达到了你期望的目标状态。
 
声明式 API 和命令式 API 是两种不同的编程方式：在声明式 API 中，你声明了系统要执行的操作，然后系统将不断向该状态驱动；而在命令式 API 中，你可以直接发出服务器要执行的命令，如 “运行实例”“停止实例”等。SQL 就是一种常见的声明式编程语言，开发者可以自行指定获取所需的数据。在声明式语言中，描述一般为“创建三个 Web 实例的集群”，而不是把创建 Web 实例的命令运行三次组成一个集群。
 
声明式设计是一种设计理念，同时也是一种工作模式，它使得你的系统更加健壮。分布式系统环境可能会出现各种不确定的故障，面对这些组件故障，如果使用声明式 API ，查看对应组件的 API 服务器状态，再确定需要执行的操作即可；而使用命令式 API 时，恢复组件则会变得比较困难。
 
云原生应用的特征：云原生与“12 因素”
 
Heroku于 2012 年提出“12因素（12-Factors）” 的云应用设计理念，（HeroKu 曾于2009 年推出公有云 PaaS），这些设计理念指导开发者利用云平台来开发易于维护、更具可靠性和扩展性的云原生应用。
 
1. 方法论和核心思想
 
“12 因素”适用于任何语言开发的后端应用，并提供了很好的方法论和核心思想。“12 因素”为构建 SaaS 应用提供了如下的方法论：
 
 
使用声明式格式来搭建自动化，从而使新的开发者花费最少的学习成本来加入这个项目；
 
 
和底层操作系统保持简洁的契约，在各个系统中提供最大的可移植性；
 
 
适合在现代的云平台上部署，避免对服务器和系统管理的额外需求；
 
 
最小化开发和生产之间的分歧，持续部署以实现最大灵活性；
 
 
可以在工具、架构和开发实践不发生重大变化的前提下实现扩展。
 
 
2. 编码、部署和运维原则
 
“12 因素”理论适用于以任意语言编写，并使用任意后端服务（数据库、消息队列、缓存等）的应用程序，它是关于如何编码、部署和运维的原则。这些是软件交付生命周期里最常见的场景，为多数开发者和 DevOps 整合团队所熟知（如下图）。
 
 “12 因素”的内容
 
 
编码有关：基准代码、构建发布运行、开发/生产环境等价 ，与源码管理相关；
 
 
部署有关：显式依赖、配置、独立进程、后端服务、端口绑定，与微服务该如何部署以及如何处理依赖相关；
 
 
运维原则：并发、易处理、日志、管理进程，与如何简化微服务的运维相关。
 
 
3. 具体内容
 
12 因素的具体内容如下所示。
 
 
Codebase：基准代码。一份基准代码，多份部署。在统一的代码库中为代码配置、测试和脚本部署建立独立的项目和模块。
 
 
Dependencies：显式声明依赖关系。通过 Bundler、NPM 等工具隔离依赖性，不依赖于部署环境。
 
 
Config：在环境中存储配置。通过操作系统级的环境变量将配置信息或其他可能存在的不同信息（如开发环境、预生产环境、生产环境）应用到各个部署环境中。
 
 
Backing services：把后端服务当作附加资源。数据库、缓存等均被作为附加资源在不同环境中被同等调用，每个不同的后端服务都是一份资源。
 
 
Build, release, run：严格分离构建和运行。基准代码进行部署需要三个步骤，构建阶段，将代码仓库转化为可执行包的过程；发布阶段，将构建的结果和当前部署所需的配置相结合，并能够立刻在运行环境中投入使用；运行阶段，是指针对选定的发布版本在执行环境中启动一系列应用程序的进程。
 
 
Processes：进程。以一个或多个无状态进程运行应用。
 
 
Port binding：通过端口绑定提供服务。互联网应用可以通过端口绑定来提供服务并随时监听所有发送至该端口的请求。
 
 
Concurrency：并发。通过进程模型进行扩展。
 
 
Disposability：易处理、快速启动和优雅终止可最大化健壮性。
 
 
Dev/prod parity：开发环境与生产环境等价。保持开发、预发布、线上环境的相似性来实现持续交付与部署。
 
 
Logs：日志。把日志当作事件流，允许执行环境通过集中式服务来收集、聚合、检索和分析日志。
 
 
Admin processes：管理进程。后台管理任务当作一次性进程运行，如数据库迁移。
 
 
“12因素”对于构建 Web 应用程序或 SaaS 平台具有指导作用。虽说提出之后已有八年之久，可能有些细节跟不上最新的体系架构，但“12 因素”依旧是目前最为系统的云原生应用开发指南。你在开发时可以依旧参考它，但也不用拘泥于教条规则。
 
小结
 
以上我们主要介绍了云原生基础架构的组成：微服务、容器、服务网格、不可变基础设施和声明式 API ，这五大主要技术可以帮助你构建云原生应用；随后我们又介绍了“12 因素”的具体内容以及云原生应用具有的基本特征，它可以指导你如何去构建云原生应用。
 
工欲善其事必先利其器，从本节课的介绍你可以知道，学习云原生不是一蹴而就的事，不仅需要你掌握相关的方法论，而且还需要大量的实践。这五大代表技术，展开来还有更加详细的知识体系，通过本节课你先有个整体的把握后，在后面的学习中才能够有侧重点，更加得心应手。
 
好了，关于云原生我们暂时介绍到这里，你的云原生架构思维导图已经绘制好了吗？欢迎你在留言区分享你最熟悉的云原生技术。下节课我们将进入微服务相关的学习，这也是本课程的重点。
 
转载文章：
 
https://kaiwu.lagou.com/course/courseInfo.htm?courseId=287#/detail/pc?id=3800