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

WorkProj

内容管理

    • 云原生
    • 云原生应用
      • 十二要素应用
      • cfeng的work理解


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


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

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

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

在这里插入图片描述

云原生

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

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

生于云,长于云

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

【cfeng work】什么是云原生 Cloud Native_第1张图片

云原生应用

采用云原生思想构建的应用,云原生应用能够部署在不同的环境中(环境无关),具有一定的可扩展性、容错性和可观察性(云操作)、应为松耦合的分布式系统(微服务)、大量技术支撑云原生应用。(常见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的环境变量配置】其它的常见的分布式微服务的概念技术就不赘述了…

你可能感兴趣的:(Work,Road,云原生,运维,java,微服务,cloud,native)