【cfeng work】什么是云原生 Cloud Native-Toy模板网

这篇具有很好参考价值的文章主要介绍了【cfeng work】什么是云原生 Cloud Native。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

WorkProj

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

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

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

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

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

云原生

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

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

生于云，长于云

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

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

云原生应用

采用云原生思想构建的应用，云原生应用能够部署在不同的环境中（环境无关），具有一定的可扩展性、容错性和可观察性（云操作）、应为松耦合的分布式系统（微服务）、大量技术支撑云原生应用。（常见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的环境变量配置】其它的常见的分布式微服务的概念技术就不赘述了…文章来源地址https://www.toymoban.com/news/detail-484533.html

到了这里，关于【cfeng work】什么是云原生 Cloud Native的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！