抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

云原生概述

在这里插入图片描述

概述

云原生的概念一直以来都很模糊,虽然云原生计算基金会(CNCF)给出了所谓的定义,但是并不能让大家很好的理解云原生的理念,为什么说是理念呢,因为云原生是一种思想,是一种解决方案,很抽象。

​ 随着云原生生态和边界不断的扩大,云原生自身的定义一直在变,不同的公司(Pivotal & CNCF)不同的人对它有不同的定义,同一家公司在不同的时间阶段定义也不一样,根据摩尔定律推断,未来对于云原生的定义还会不断变化。

云计算是什么

说到云原生,就不得不提到云计算,那么什么又是云计算呢?

​ 2006年,亚马逊把基于分布式操作系统聚集起来的强⼤计算能⼒,通过互联⽹的⽅分输送给千千万万的普通⽤户,⼈们给这种计算的在线服务,起的名字叫做云计算。

​ 通俗的说,把分布式操作系统聚集起来的强大计算能力像水电一样,成为大众的必需品,输送给千家万户,让每个人都可以高效利用这种计算资源。

​ 就像水龙头一样,我们什么需要水打开水龙头就好了,再也不用去井里挑水喝了;什么时候需要电直接打开开关就好了,再也不用拿两根木头磨来磨去了,但是,你要付费,你得掏钱,天底下没有免费的午餐,因为能量守恒。

云原生是什么

技术的变革,一定是思想先行,云原生是一种构建和运行应用程序的方法,是一套技术体系和方法论。

​ 云原生(CloudNative)是一个组合词,Cloud+Native,Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。

早期定义

Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念;2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:

  1. 符合12模式(Twelve-Factor App):云原生应用架构的模式集合
  2. 微服务架构(Microservices):独立部署的服务,一次只做一件事
  3. 自助服务敏捷基础设施(Self-Service Agile Infrastructure):用于快速、可重复和一致地提供应用环境和服务的平台
  4. 面向API接口的通信(API-based Collaboration):服务之间的交互基于接口,而不是本地方法调用
  5. 抗脆弱性(Anti-Fragility):系统能抵御高负载
中期定义

到了2017年,Matt Stine在接受InfoQ采访时又改了口风,将云原生架构归纳为:

  • 模块化(Modularity)
  • 可观测性(Observability)
  • 可部署性(Deployability)
  • 可测试性(Testability)
  • 可处理性(Disposability)
  • 可替代性(Replaceability)

而Pivotal最新官网对云原生概括为4个要点:DevOps+持续交付+微服务+容器

后期定义

​ 2015年云原生计算基金会(CNCF)成立,CNCF掺和进来后,最初把云原生定义为包括:容器化封装+自动化管理+面向微服务;到了2018年,CNCF又更新了云原生的定义,把服务网格(Service Mesh)和声明式API给加了进来。

​ 可见,不同的人和组织对云原生有不同的定义,相同的人和组织在不同时间点对云原生也有不同的定义,真是乱的一匹,搞得鄙人非常晕菜,我的应对很简单,选一个我最容易记住和理解的定义:DevOps+持续交付+微服务+容器。

总而言之,符合云原生架构的应用程序应该是:采用开源堆栈(K8S+Docker)进行容器化,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

云原生的四要素

img

微服务

​ 几乎每个云原生的定义都包含微服务,跟微服务相对的是单体应用,微服务有理论基础,那就是康威定律,指导服务怎么切分,很玄乎,凡是能称为理论定律的都简单明白不了,不然就忒没b格,大概意思是组织架构决定产品形态,不知道跟马克思的生产关系影响生产力有无关系。

​ 微服务架构的好处就是按function切了之后,服务解耦,内聚更强,变更更易;另一个划分服务的技巧据说是依据DDD来搞。

容器化

​ Docker是应用最为广泛的容器引擎,在思科谷歌等公司的基础设施中大量使用,是基于LXC技术搞的,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,谷歌搞的,Docker和K8S都采用Go编写,都是好东西。

DevOps

​ 这是个组合词,Dev+Ops,就是开发和运维合体,不像开发和产品,经常刀刃相见,实际上DevOps应该还包括测试,DevOps是一个敏捷思维,是一个沟通文化,也是组织形式,为云原生提供持续交付能力。

持续交付

​ 持续交付是不误时开发,不停机更新,小步快跑,反传统瀑布式开发模型,这要求开发版本和稳定版本并存,其实需要很多流程和工具支撑。

云原生范畴

云原生不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。

​ 采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。

方法论与原则 12要素,声明式API
流程规范 DevOps,持续交付,自动化测试,Code Review
软件架构 微服务,服务网格,无服务
基础设施 敏捷基础设施,如K8S、Docker、云服务器、云数据库、云存储等
工具集 Prometheus,Envoy,Jaeger等

云原生应用和传统应用的区别

云原生与传统应用有比较明显的区别,云原生更倡导敏捷、自动化、容错,而传统应用则大多还处于原生的瀑布开发模型和人工运维阶段

传统应用 云原生应用
开发语言 C/C++、企业级Java编写 Go、Node.js等新兴语言编写
依赖关系 单体服务耦合严重 微服务化,高内聚,低耦合
部署方式 对机器、网络资源强绑定 容器化,对网络和存储都没有这种限制
运维方式 人肉部署、手工运维 自动化部署,支撑频繁变更,持续交付,蓝绿部署
开发模式 瀑布式开发 DevOps、持续集成、敏捷开发
扩展性 运维手工扩容 动态扩缩容
可用性 故障后可能影响业务 无状态,面向失败编程
可靠性 本地资源,故障率高 云资源,可靠性高

CNCF是什么

云原生技术图谱 https://landscape.cncf.io/

​ 上面提到云原生计算基金会(CNCF),是由开源基础设施界的翘楚 Google、RedHat 等公司共同牵头发起的一个基金会组织,其目的非常明确,就是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面。CNCF 通过 Kubernetes 项目在开源社区编排领域一骑绝尘,之后就扛起了云原生定义和推广的大旗,风光无限。

img

云计算的四个层次

img

IaaS(基础架构即服务)

IaaS(Infrastructure as a Service,基础架构即服务)是基础层

​ 在这一层,通过虚拟化、动态化将IT基础资源(计算、网络、存储)聚合形成资源池。资源池即计算能力的集合,终端用户(企业)可以通过网络获得自己需要的计算资源,运行自己的业务系统。这种方式使用户不必自己建设这些基础设施,而是通过付费即可使用这些资源。

PaaS(平台即服务)

在IaaS层之上的是PaaS(Platform as a Service,平台即服务)层

​ 这一层除了提供基础计算能力,还具备了业务的开发运行环境,提供包括应用代码、SDK、操作系统以及API在内的IT组件,供个人开发者和企业将相应功能模块嵌入软件或硬件,以提高开发效率。对于企业或终端用户而言,这一层的服务可以为业务创新提供快速、低成本的环境。

SaaS(软件即服务)

最上层是SaaS(Software as a Service,软件即服务

​ 实际上,SaaS在云计算概念出现之前就已经存在,并随着云计算技术的发展得到了更好的发展,SaaS的软件是“拿来即用”的,不需要用户安装,软件升级与维护也无须终端用户参与,同时,它还是按需使用的软件,与传统软件购买后就无法退货相较具有无可比拟的优势。

DaaS(数据即服务)

越来越多的数据沉淀、抽象形成了新的服务——DaaS(Data as a Service,数据即服务)

​ 数据聚合抽象,把数据转换成通用信息,从而为公众提供公共信息服务。例如,对于天气信息,可能A需要根据天气信息来判断出门穿着,B需要根据天气信息判断是否洗车,C需要根据天气信息判断是否准备防洪防涝设施等。不同用户均可利用DaaS满足自己的诉求。

​ 此外,通过对各类数据信息进一步加工形成信息组合应用,会进一步盘活数据,提升数据价值,这就像搭积木一样,对基础数据信息块以不同的方式进行组装,可以达到千变万化的效果,DaaS服务已成为当下数字化转型的重要抓手。

云原生的关键技术

img

容器化

容器雏形最早出现在 1979 年叫 Chroot Jail ,定义于 2008 年 即 LXC(Linux Container),将 Cgroups 的资源管理能力和 Namespace 的视图隔离能力组合在一起,实现进程级别的隔离。

img

​ 然而容器最大的创新在于容器镜像(即集装箱,Docker “现象级” 开创),它包含了一个应用运行所需的完整环境(整个操作系统的文件系统),具有一致性、轻量级、可移植、语言无关等特性,实现 “一次发布,随处运行”(开发、测试、生产),使应用的构建、分发和交付完全标准化,它也是 “不可变基础设施” 的核心基础。

Kubernetes

Kubernetes 是云计算和云原生时代的 Linux,是 Google 基于 Borg 开源的容器编排调度系统,让容器应用进入大规模工业生产

img

​ 声明式的 API 与可扩展(CRD + Controller)的编程接口,先进的设计思想使其在容器编排大战中(Kubernetes、Swarm、Mesos)处于王者地位,成为容器编排系统的事实标准。

​ 通过采用 Kubernetes 平台,用户不必操心资源管理问题,使基础设施更加标准化,复杂度降低,资源使用率提升,同时 Kubernetes 也简化了混合云,多云,边缘云等跨数据中心的部署成本。

微服务(Microservices)

img

​ 微服务则是一种用于构建应用的架构方案,微服务架构有别于为传统的单体应用的是将应用拆分成多个核心功能,每个功能都被称为一个独立的服务,可以单独构建和部署,其中某个服务出现故障也不会影响其他的功能模块,这句体现了其针对特定服务发布,影响小,风险小等特点。

无服务(Serverless)

根据 CNCF 的定义,Serverless 是指构建和运行不需要服务器管理的应用程序的概念

img

​ 即开发人员无需关注底层的基础设施,只需要关注应用程序的业务本身就行,且该服务是可以自动扩展。

​ Serverless被翻译为“无服务架构”,这个概念在2012年时便已经存在,比微服务和Service Mesh的概念出现都要早,但是直到微服务概念大红大紫之后,Serverless才重新又被人们所关注。

​ Serverless(无服务器架构)并不意味着没有任何服务器去运行代码,Serverless是无需管理服务器,只需要关注代码,而提供者将处理其余部分工作。

​ 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

DevOps

img

​ 早期的项目使用的是‘瀑布模型’进行软件交付,即一个阶段所有的完成工作之后再往下一个阶段,但这样的模式无法满足业务快速开发交付及变更需求的情况,于是后面就出现了敏捷开发这一概念,即一种快速应对需求变化软件开发能力,而DevOps就是基于敏捷开发将软件开发/测试人员/IT运维关联在一起,通过工具、组织等方式使开发、测试、发布流程自动化,软件发布频繁,高效。

ServiceMesh

将一大堆和业务逻辑无关的客户端 SDK(如服务发现,路由,负载均衡,限流降级等)从业务应用中剥离出来,放到单独的 Proxy(Sidecar) 进程中,之后下沉到基础设施中间件 Mesh(类似 TDDL 到 DRDS 的模式)

img

​ 针对应用减少了系统框架变更带来的风险、瘦身后变的干净和轻量化,加快了应用的启动速度,使得应用往 Serverless 架构迁移变得轻松。

​ 针对 Mesh 可以根据自身需求自行迭代和升级功能,更加利于全局服务治理、灰度发布、监控等。

​ 同时,Mesh 边界可以扩展到 DB Mesh,Cache Mesh、Msg Mesh等,真正做到服务通信的标准化即服务之间通信的 TCP/IP。

服务网格(Service Mesh)很多人将之称为下一代微服务,或直接称之为微服务2.0。

微服务1.0

微服务1.0时代的主要问题主要包括如下三方面:

  • 技术门槛高:开发团队在实施微服务的过程中,除了基础的服务发现、配置中心和鉴权管理之外,团队在服务治理层面面临了诸多的挑战,包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等,这对开发团队提出了非常高的技术要求。
  • 多语言支持不足:对于互联网公司,尤其是快速发展的互联网创业公司,多语言的技术栈、跨语言的服务调用也是常态,但目前开源社区上并没有一套统一的、跨语言的微服务技术栈,而跨语言调用恰恰是微服务概念诞生之初的要实现的一个重要特性之一。
  • 代码侵入性强:Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性,技术升级替换成本高,导致开发团队配合意愿低,微服务落地困难。

为了解决微服务1.0时代的诸多问题,Service Mesh概念开始走入了开发者的视线中。

微服务2.0

服务网格service-mesh是一个形象化的词语表达:service(服务)-mesh(网格),它描述了服务间的依赖形态,就像下面这张网一样:

服务网格

​ 其中,深色的是我们平时工作中接触最多的业务微服务,旁边蓝色的被称为边车(sidecar)服务,sidecar作为业务微服务的“代理”,处理与其他业务微服务sidecar之间的非功能需求,如网络通信、安全、监控、流量控制等。多个sidecar之间的连接和交互组成了“网格(mesh)”。

基础设施即代码(IaC)

将基础设施及其完整的生命周期(创建、销毁、扩容、替换)以代码的方式进行描述、通过相应的工具(terraform、ROS、CloudFormation等)编排执行和管理。

img

​ 比如应用用到的所有基础资源(如:ECS、VPC、RDS、SLB、Redis 等),无需在控制台不停的切换页面申请购买,只需定义相应代码,一键创建。

​ 这样做的受益是基础设施代码版本化,可 Review,可测试,可追溯,可回滚,一致性、防止配置漂移,方便共享、模板化和规模化,提升了运维整体效率和质量,通过代码也可以轻松了解基础设施的全貌。

Cloud IDE

云端 IDE 深入研发的整个生命周期,提供了完整的开发、调试、预发、生产环境及CI/CD 发布一体化体验

img

​ 云端可提供丰富的代码库模板,通过分布式运算提升编译速度,以 “智能” 方式实现代码推荐、代码优化、自动扫描发现 BUG、识别逻辑和系统性风险。

​ 可以想像云时代开发模式与本地开发完全不同,拥有更高的研发效率,更快的迭代速度,更完善的质量控制。

云计算和云原生的关系

云原生是云计算的趋势

  1. 从市场发展趋势看,云计算将是未来IT的主流。
  2. 从技术发展趋势看,更多企业将会广泛应用云原生技术。
  3. 从软件开发角度看,云原生技术为企业带来了更快进行业务创新的价值。

云原生是云计算的再升级

  1. 整个云原生技术栈都是基于开源、开放的技术标准。
  2. 云原生是对使用云的应用架构的再升级。
  3. 云原生是对云平台的技术和云服务的再升级。

云原生成熟度模型

我们可以通过云原生成熟度模型来衡量我们系统目前所处的阶段,借助于云计算平台,我们可以比较容易把我们的云原生成熟度提高到第三级别。

成熟度 描述 关键技术点 效果
第一级 单体架构或者大粒度拆分;应用运行在虚拟化环境中;应用可以通过镜像或者脚本自动化部署; 负载均衡服模块化虚拟化隔离 瀑布式开发系统维护性差系统可用性严重依赖运维人员
第二级 微服务架构、服务满足无状态、自治、隔离的条件;服务根据业务划分等级;非核心业务可以实现快速降级;不受服务失败的影响,快速隔离; 微服务框架持续交付流水线调用链分析分布式配置自动化测试监控系统 交付周期提升明显小团队开发,效率提升对测试人员依赖降低
第三级 可编程基础设施;中间件作为后端服务提供;任何时刻业务无中断;实现1%-100%的灰度发布流程;自动扩缩容;自动化降级;开发、测试、生产环境统一;全球化的业务发布能力,异地多活; 分布式数据库分布式缓存分布式消息队列灰度发布平台全局容灾方案全局一致性方案混沌测试容器资源调度平台 不需要择时发布开发人员专注于业务,架构能力由基础设置提供公共基础服务共享重用
第四级 系统具有自学习、自诊断、自调整、自恢复能力;高度可视化、自动化;实现自动发布(AI选择发布时间)、自动降级、自动回滚;可根据AI自动调整参数、如超时时间;所有公共服务形成统一的整体,通过接口实现数据共享; 人工智能决策强大的公共基础服务智能化运维高度自动化能力可实现Severless架构 AIOps/NoOps资源利用率极大提升瞬间扩展能力强大的可用性强一致性

评论