据云原生计算基金会 CNCF 公布的第六次年度考察，96% 的企业正在应用或评估 Kubernetes，国内外很多企业更是将所有的利用都容器化，Docker 和 Kubernetes 等云原生技术曾经是泛滥企业的事实标准。
云原生其实是“以利用为核心”的，蕴含一整套围绕应用程序的设计、开发、部署、运行、保护的流程，技术栈，文化理念等，而国内九成以上的程序员是从事利用程序开发，比方从事前端、后端、挪动端等。那 云原生利用 又与 传统利用 有哪些区别与劣势？又须要程序员在其中表演什么角色？云原生时代，程序员应该把握哪些云原生常识？
1、什么是云原生利用
云原生应用程序通常来说遵循 十二因素应用程序 的方法论，基于 容器 的基础架构和侧重于 微服务 的体系结构，充分利用云计算的劣势，进步开发效率，晋升业务麻利度、弹性、可用性、资源利用率，从而达到企业的降本增效。
相比于传统开发方式和传统利用，云原生的开发方式和云原生利用的劣势和特点体现在：
- 疾速开发、迭代且独立：基于微服务构建的应用程序以及与生产部署集成的测试零碎，开发团队之间能够更快、更频繁、更独立地更新、修复和公布应用程序。
- 自动化、可扩大：每一项服务都是高可用的，不会因为某个基础设施的故障而导致利用无奈应用；平台自动化可轻松构建和运行易于治理的利用，打消因人为谬误造成的停机；
- 伸缩性：云原生利用的每个服务能够独立依据业务负载弹性伸缩，而云计算资源通常是按量付费的，这让云原生利用可能主动高峰期扩大，在低谷期膨胀，在简单业务场景都能失常运行的同时还能够降低成本；
- 凋谢且灵便：云原生应用程序通常宽泛采纳开源技术，独立的团队之间也能够应用不同的编程语言与技术栈，同时企业能够构建无需批改便可反对跨私有云、公有云、混合云的利用；
而程序员所要做的就是充分利用云原生的劣势如何把现有的利用平滑迁徙到云原生环境中，因而对程序员来说，对于云原生利用比较简单而具体的表述是：如何将软件我的项目拆分为多个分布式的微服务，整个我的项目基于容器来构建、公布、运行；应用 Kubernetes 来编排与调度这些容器；应用 DevOps 和 GitOps 工作流来治理和自动化部署，以及应用 Prometheus、ELK 等对利用的运行状况进行监控等。
2、程序员须要把握的云原生技术
因而，云原生时代程序员根本须要把握四个方面的技术技能：微服务 、 容器化 、GitOps 与 Kubernetes 根底 以及 服务 API 接口化与服务治理，还须要理解云原生利用的方法论：十二因素应用程序。
首先是要可能依据业务，将我的项目形象、解耦，将公共性能通过合成为更小的、模块化的独立服务来简化代码复杂性，这些服务提供间接构建到应用程序的监控、指标和弹性。构建微服务的模块要做到一个服务只实现一个工作，程序之间可能提供一个通用的接口来协同工作。
采纳微服务的益处是，应用程序能够互相独立开发（自由选择技术）与部署，模块化强、可替代性强、可继续开发与继续交付，可能缩短软件公布工夫，可依据业务负载独立伸缩等。而要想让微服务架构可能失常运行，各个服务之间必须通过音讯、REST 等机制实现的显示接口互相通信，而通过在利用中构建一层服务网格能够简化服务间通信。
3、如何开始学习
对程序员来说，最简略且最容易动手且最应该先去把握的，当然是实战性比拟强的容器化、Kubernetes 根底和 GitOps 了。至于微服务、服务治理以及十二因素应用程序这些偏方法论的常识，则都能够建设在 Docker 和 Kubernetes 的根底上。
对于云原生应用程序来说，容器不仅只是我的项目的代码打包和部署的单位（容器化），也是模块、服务复用的单位（微服务），同时也是利用伸缩以及资源分配的单位（Kubernetes 编排容器），所以容器以及容器化对云原生开发十分根底且重要。
而云原生中最为重要的产品还是号称云计算时代的操作系统 Kubernetes，云原生利用泛滥劣势的体现都与 Kubernetes 的编排调度非亲非故，因而只管程序员最次要的工作还是云原生利用开发，而 Kubernetes 的集群治理如同也是运维工程师的职责，然而程序员还是须要理解一些 Kubernetes 的根底。
而 GitOps 则是一种实现继续交付的模型，它的核心思想是将应用程序及其基础架构配置（如利用所须要的 CPU、内存、存储、网络、权限等配置）寄存在 Git 的版本控制库中，通过版本控制库的变更，来实现利用和基础架构的变更。
在这个过程中，程序须要把握如何将利用打包成容器并通过 GitOps 流水线的形式一键主动公布到线上的容器服务集群（比方腾讯云的容器服务 TKE、弹性容器服务 EKS 或微信云托管）上。
对于 Docker 和 Kubernetes 的学习，只管官网技术文档是一个不错的入门教程，然而依然存在很多老手 不可避免 的一些“坑”，让本来简略且有意思的入手变得艰巨，有的人甚至连装置配置环境就阻力重重。
只管 Docker 和 Kubernetes 官网技术文档是一个不错的入门教程，然而依然存在很多老手 不可避免 的一些“坑”，让本来简略且有意思的入手变得艰巨，有的人甚至连装置配置环境就阻力重重。
为此腾讯云【燎原社】推出了一套学习门槛更低、步骤性更强、内容更为具体且更加适宜国内用户学习的云原生技术工坊，旨在帮忙更多对云原生技术感兴趣的开发者疾速且零碎的把握 Docker 与 Kubernetes。作为一款入门课程，对初学者十分敌对，不仅收费，还配有专门的学习交换群，群内学员打卡分享，气氛超棒！
详情可戳链接： 腾讯云燎原社技术工坊
无论是容器的构建，还是 GitOps，还是十二因素应用程序，置信只须要通过短暂十几天业余的学习，程序员就应该能够感触到云原生开发方式相比传统形式全新的畅快体验。
4、十二因素应用程序方法论
十二因素应用程序是一套准则，一种软件工程的方法论，从源代码治理、架构体系、利用状态、开发部署等方面疏导团队疾速适应并构建优雅、可保护、易扩大的云原生利用，后由 Kevin Hoffman 并减少了三个额定的因素，是如何构建云原生应用程序十分值得参考的意见。
对于十二因素应用程序方法论的具体表述，能够参考 12factor；而对于十五因素的具体表述，能够参考[Beyond the
Twelve-Factor App](https://hackweek-1251009918.c…)
对于十二因素应用程序的核心思想，在 O ’reilly 出品的《云原生 Java》这本书里，有一个比拟提炼式的解读：
- 应用 申明 的形式来搭建自动化环境，最大限度地缩小新退出我的项目的开发人员的工夫和老本；
- 与底层操作系统之间建设清晰的约定，在执行环境之间提供 最大的可移植性；
- 适宜 部署 在古代的 云平台上，毋庸提供服务器和系统管理工具；
- 最大水平缩小 开发环境与生产环境之间的 区别 ，通过 继续部署 取得最大的灵活性；
- 能够在不对工具、架构或开发实际带来重大变动的前提下，进行 程度扩大。
十二因素应用程序涵盖了所有古代应用程序的常见问题，是构建云原生应用程序的一些束缚意见：
| 因素 | 阐明 |
|---|---|
| 基准代码 | 一份应用版本控制系统治理的基准代码，多份部署 |
| 依赖 | 显示申明依赖关系，通过依赖清单，确切地申明所有依赖项 |
| 配置 | 在环境中存储配置，与代码拆散，如数据库、证书、每份部署特有的配置等 |
| 后端服务 | 将程序运行所须要的，通过网络调用的各种服务，如数据库、音讯 / 队列零碎，缓存零碎等当做附加资源 |
| 构建、公布、运行 | 严格拆散构建、公布和运行的代码版本 |
| 过程 | 以一个或多个无状态过程运行利用，任何须要长久化的数据都要存储在后端服务 |
| 端口绑定 | 通过端口绑定提供服务，申请对立发送至公共域名而后路由至绑定了端口的网络过程 |
| 并发 | 通过过程模型进行扩大，将不同的工作调配给不同的 过程类型 |
| 易解决 | 利用的过程能够疾速启动和优雅终止，这既有利于利用的弹性伸缩，也能迅速部署一直变动的代码或配置 |
| 开发 / 生产环境统一 | 尽可能保障开发环境、预发环境和线上环境的一致性 |
| 日志 | 日志应该是事件流的汇总，将所有运行中过程和后端服务的输入流依照工夫程序收集起来 |
| 治理过程 | 把后盾治理工作当作一次性过程运行 |
这里有一份计算机顶级名校 CMU 的十二因素应用程序打分表，打分越高阐明越合乎云原生应用程序的束缚（表格内 1,2,3 为评分）：
| 12 因素 | 评分 |
|---|---|
| 基准代码 | 1. 应用电子邮件发送不同名称的代码 zip 2. 频繁地提交代码更新到代码控制系统（我的项目代码应用的同一个代码仓库） 3. 应用程序拆分成独立的局部，每个局部都是一个利用，都有自有的仓库 |
| 依赖 | 1. 手动下载代码依赖，比方下载 jar 到 lib 文件夹； 2. 应用软件包管理器（如 mvn、npm），或 curl 来下载治理依赖 3. 应用容器镜像制品治理仓库如 Artifactory 来治理 DevOps 流水线 |
| 配置 | 1. 在代码中硬编码 URL、明码，应用 if(Mode.PROD)来治理代码分支 2. 应用配置文件，不同环境应用多种配置文件 3. 应用配置服务（Spring Cloud Config、Zookeeper） |
| 后端服务 | 1. 供应商特定的连贯库，硬编码连贯字符串 2. 连贯参数存储在配置文件中 3. 动静发现资源，独立地更新后端服务 |
| 构建、公布和运行 | 1. 开发从本地构建和部署代码，生产环境由手动推送 2. 应用构建 / 公布工具(如 Jenkins，TravisCI)，清晰地拆散构建和部署阶段 3. 有一键点击就可公布的流水线，每个公布都用版本控制并保留用于回滚，没有人工干预 |
| 过程 | 1. 粘滞会话，将应用程序的数据、状态写入到本地文件系统 2. 利用的过程不依赖本地存储的数据 3. 无状态，将会话数据存储在数据存储中(redis)，缓存两头事务的步骤 |
| 端口绑定 | 1. 应用程序不提供对外的服务 2. 单机模式，但监听特定的端口来提供服务 3. Web 服务器是应用程序的一部分(node，netty)，利用通过 HTTP 提供服务 |
| 并发 | 1. 必须程序运行的阻塞式工作 2. 非阻塞式 IO 服务器（node、netty）3. 程度扩大，小型、独立的微服务 |
| 易解决 | 1. 须要开发人员来协调重启服务 2. 利用可能疾速启动 3. 应用程序能优雅终止，且低于 1 秒疾速重启，存储状态能疾速复原 |
| 开发环境与线上环境等价 | 1. 开发人员对线上环境不理解，开发环境和线上环境不同 2. 开发时用轻量级的产品来代替线上环境里比较复杂的产品 3. 开发环境与线上环境是等价的 |
| 日志 | 1. 通过代码如 System.out.print() 来输入日志 2. 将日志文件写入到 web 服务器 3. 将日志当作流式数据来解决(ELK) |
| 治理过程 | 1. 数据迁徙时，手动批改数据库的条目 2. 将利用的迁徙脚本存储在仓库中 3. 应用框架的工具链 |
Kevin Hoffman 在十二因素之上新增了如下三个因素，也就是说现实状况下，云原生利用应该具备这 15 个特色：
- API 优先准则
微服务架构的利用应用公开 API 来作为服务的对外接口；在利用的设计阶段，应该首先设计 API 并确定 API 的细节。 - 遥测数据
云原生利用须要收集一系列遥测数据，包含利用性能指标、运行状态和日志等；云平台能够用性能指标来进行主动程度扩大 - 认证与受权
云原生利用应该是平安的，能够应用基于角色的访问控制（RBAC）来爱护 API
腾讯云【燎原社】还推出了为期 3 天的线下【云原生技术实战营】，腾讯云技术专家团队会面对面倾囊相授一线云原生实战经验，手把手教你业务容器化革新的“最佳实际”，参与者不仅能够和社区各畛域程序员一起提高，还能与腾讯资深架构师、产品继续交换。
详情可戳链接：腾讯云燎原社云原生技术实战营
5、书籍举荐
一般来说，程序员更聚焦于云原生利用的开发以及相应的软件工程办法，下列举荐书籍也次要聚焦于微服务、Docker、Kubernetes 的根底，以及如何基于 Java 生态构建云原生利用：
- 《微服务：灵便的软件架构》
- 《Docker 实战(第 2 版)》(Docker in Action)，清华大学出版社
- 《深刻分析 Kubernetes》（其实这是一本入门的书籍）
- 《云原生 Java》