【cfeng work】什么是云原生 Cloud Native

WorkProj

---

本文introduce 云原生 Cloud Native相关内容

---

随着技术的迭代，从最初的物理机—> 虚拟机，从单机 —> 分布式微服务， 现在的热门概念就是云☁（cloud）， 云原生，云计算，云服务，云主机，云…， cfeng在work接触的全部就是云☁，所以借此分享一下个人对于云原生的理解

Cloud Native，服务围绕Cloud， 而程序设计之初就Native是考虑云， 充分发挥云平台的弹性和分布式优势

以前企业的服务基本都是直接部署在公司的物理机上面，单机架构，所以性能不好，一个应用可能就一台服务器， 随着云计算的普及， 应用一般都会上云，慢慢就出现了云原生

云原生

云原生最早由Pivotal的Matt Stine提出，值得一提的是，云原生与微服务类似，不是特指某种技术，而是一种思想

云原生技术有利于各组织在公有云、私有云和混合云等新型环境中构建和弹性扩展应用， 代表技术包括容器、服务网格、微服务、不可变基础设施、声明式API

生于云，长于云

云原生应用 通常采用了DevOps、CICD、微服务和容器技术

云原生应用

采用云原生思想构建的应用，云原生应用能够部署在不同的环境中（环境无关），具有一定的可扩展性、容错性和可观察性（云操作）、应为松耦合的分布式系统（微服务）、大量技术支撑云原生应用。（常见docker、k8s、jenkins + git仓库…）

云原生应用运行的云环境可以构建在主流的PaaS和IaaS， 与k8s等容器技术结合【并不是发明新技术】

主流观点认为，云原生的四要素为

• 微服务： 云原生定义包括微服务，组织架构决定产品形态【服务编写语言可不同】 比如一个用python、另外一个用go、java都可以
• 容器化： 主要就是为了让应用部署在不同的环境，常见docker （容器）+ k8s（容器编排系统）
• DevOps： Dev & Ops 开发运维一体化，这个dev应为开发 + 测试（maybe)， 尽可能降低应用开发完成 ----> 部署成功之间的流程， 所以应当使用相关的流水线技术实现【一键部署】
• 持续交付 ： 一种开发思想，区别于传统的瀑布开发模型，不误时开发，小步快跑，【开发版本和稳定版本并存】 — 这个只要长期维护一般都是，支持频繁更新

云原生不只是简单的服务上云，而是Native就考虑云，更好利用云

云原生对基础设施要求较高，不只是云平台，周边生态亦是，java中Spring Cloud可以让基于Spring 开发的应用快速满足弹性、可伸缩、高可用等多项要求

对于非spring cloud、java应用，对应的概念就是将应用SDK剥离到独立的side Car（系统独立运行进程）中， 比如Envoy， 最流程的服务网格的试下Istio就依赖Envoy

ODCA发表的云上应用成熟度模型：

• 虚拟化： 应用可以运行在不同的环境 【通过镜像实现】
• 松耦合： 应用和底层设施分离，比如【应用程序和数据库分离，应用程序和文件存储分离】
• 抽象化： 运行环境抽象、相关流程也需要抽象 【部署、弹性扩容】 — 服务无状态且容灾
• 适应性： 自动适应各种环境变化、自动弹性伸缩…

十二要素应用

十二要素应用指的是云上运行应用遵守的12条最佳实践

• 基准代码： 一份基准代码，多份部署 【就是代码的版本管理做好】， 因为实际开发对应多中环境，像dev、sit、uat、灰度、生产，可能应用的版本号不同的
• 依赖 ： 显式声明依赖关系， 比如java中使用maven， 环境依赖放在dokcerFile
• 配置 ： 在环境中存储配置； 对于java来说，项目yaml中配置项做成变量的形式，之后在环境中配置这些变量，不在代码中控制【当然可以利用Spring Cloud的Nacos云配置】， 比如可以配置在Potainer或者k8s中
• 后端服务： 后端服务当作附加资源，这个后端服务指的是服务依赖的服务，比如数据库、消息队列等，最好能够做到松耦合，比如改一个配置，就启用了不同的组件， work中出现的信创生态的国产化组件替换就体现了该思想
• 构建、发布、运行： 严格分离构建和运行， 就是说流程应当严格遵守，不能说打包之后在包里面修改
• 进程： 以一个或者多个无状态进程运行应用 【主要就是无状态，不同进程内存由不同内容不符合要求，最好就是分布式的缓存】
• 端口绑定： 通过端口绑定提供服务 ； 比如docker构建，通过端口就能访问服务
• 并发： 通过进程模型进行扩展； 比如部署集群多节点方式进行水平扩展【无论是同一台机器启动更多进程，还是Kubernetes集群启动更多Pod】— 依赖于无状态
• 易处理： 快速启动、终止的最大化健壮性 【物理宕机等通过各种手段降低故障】
• 开发环境与线上环境等价： 尽可能保持开发环境与线上环境等价 【==cfeng咋work时就有由于不等价造成的问题】， 最常见的就是线上集群部署，而开发是单节点的
• 日志： 把日志当作事件流 ； 不建议通过应用管理日志，而是输出到STDOUT，比如统一的日志管理，cfeng在work时就利用ELK进行日志收集管理
• 管理进程： 后台管理任务当作一次性进程运行

cfeng的work理解

cfeng做的就是云原生应用【基于云原生架构】， 满足了容器化、微服务、Devops和持续交付

在work中的体现：

• 不需要停机更新，由于部署在☁上，直接更新版本号即可，同时更新较为频繁，uat/di环境的部署可能半天就从160版本迭代到170版本，每次都是直接换一个镜像版本号即可

• 不依赖网络资源，比如ip和端口都是无限制的

• 应用自动化部署和运维，运维全自动，流水线部署

• 使用docker+ k8s镜像技术， 有很好的移植性

• 应用微服务，松耦合，各种微服务 + 底层基础设施分开部署

  …

云原生架构也就好理解了，就是Native Cloud的架构设计，整个应用设计之时就考虑到Cloud，整体架构上满足云原生思想，最终构建出云原生应用，分布式微服务、容器化加容器编排、自动化流水线

cfeng目前了解的云原生的相关技术： docker + k8s（容器化 + 容器管理）， jekins + github（流水线构建 + 代码托管）【potainer和k8s的环境变量配置】其它的常见的分布式微服务的概念技术就不赘述了…