什么是云原生

一、开篇浅谈

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

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

为了能够给大家尽可能说出云原生是个什么东西,我读了很多很多文章,拜访了很多名家,包括业界的知名大佬、年薪千万的骨灰级专家、名下数十万学生的成功学大师,真是生怕自己才疏学浅耽误了大家,所以我希望大家能看到最后,也希望这篇文章能够给你带来收获。

二、云计算是什么

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

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

通俗的说,把分布式操作系统聚集起来的强大计算能力像水电一样,成为大众的必需品,输送给千家万户,让每个人都可以高效利用这种计算资源。就像水龙头一样,我们什么需要水打开水龙头就好了,再也不用去井里挑水喝了;什么时候需要电直接打开开关就好了,再也不用拿两根木头磨来磨去了。但是,你要付费,你得掏钱,天底下没有免费的午餐,因为能量守恒。

三、云原生是什么

我接触云原生应该是在8年前,那时候我高二,那个时候云原生的概念比较广泛,记得那时候应该是暑假,那天很热,风扇吹着,看着qq群里的前辈们讨论着“Docker”这个字眼,真是好奇啊,听前辈们对这个赞不绝口,好奇心的驱动,让我开始了云原生之路。

初识Docker的我,还没有感受到它的强大之处,简单的过手之后,就潦草的摒弃掉了,次年,也就是我的高考前几个月吧,已经玩烂了ssm框架的我,过渡到了SpringBoot,感受到SpringBoot的强大之后,不免让我想起了Docker,这不也是开箱即用,敏捷开发么?这个时候我已经发现社区生态已经逐渐强大了。

在大家还在猛刷“三年高考,五年模拟”的时候,我将我写完的SpringBoot项目用Docker部署在Linux上,我现在还记得当时那种兴奋的感觉,不用手动部署项目,不用手动部署Nginx、Redis、MySQL...只需要用Docker拉取对应版本镜像,通过简单的命令就可以完成之前复杂的操作,再加上相关编排工具的加持,简直不要太爽。

再到高考之后,我发现当时已经称霸的k8s+拥有绝对地位Docker+SpringCloud Netflix已经可以满足企业开发,我觉得这一定是风口,你要知道,风来了,猪都会飞,我虽然数理化没学好,但我想做这只猪,这只会飞的猪。

其实,云原生从我当初刚了解的时候,就特别火,而且是一直火,没想到时至今日,才被大家所熟知。

早期,云原生架构有几个特征:

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

简单来说就是:

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

2019年,VMware Tanzu 官网给出了云原生最新定义,以及云原生的架构原则:

云原生是一种利用云计算交付模型的优势来构建和运行应用程序的方法论。当企业使用云原生架构开发和运维应用程序时,它们能更快速地响应客户需求将新想法推向市场。

虽然公共云影响了几乎所有行业对于基础设施的思维模式,但类似云的交付并不仅限于公共环境。云原生的开发同时适合公共云和私有云,你只需要关心应用程序是如何创建和部署,无需理会在哪部署。

更重要的是能够为开发人员提供按需访问计算能力以及现代数据和应用程序服务。云原生开发融合了 DevOps、连续交付、微服务和容器。

云原生架构原则:DevOps、Microservices、Containers、Security。

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

给大家看一眼CNCF的全景图吧!

image.png

2015 年 CNCF 把云原生定义为:应用容器化、面向微服务、容器编排。到了 2018 年,CNCF 更新了云原生的定义,加入了声明式 API 和服务网格(2017 年社区新技术,和微服务并列,注意它不是微服务的升级版本),这些技术能够构建容错性好,易于管理和便于观察的松耦合系统。2018年,大量科技公司开始接受云原生的概念,并纷纷加入到云原生的大家庭。此外,主流云计算供应商相继加入 CNCF,持续丰富整个云原生的生态。

四、云计算的四个层次

4.1 IaaS(基础架构即服务)

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

4.2 PaaS(平台即服务)

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

4.3 SaaS(软件即服务)

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

4.4 DaaS(数据即服务)

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

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

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

五、云原生如何构建

5.1 云原生架构

容器化的出现,一定程度上带动了微服务架构。架构演化从单体式应用到分布式,再从分布式架构到云原生架构,微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。

来看一看这个我早些年画的一个简易的架构图:

image.png

从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件,包括:服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。

image.png

Spring Cloud和Kubernetes有很大的不同,Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点,而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点,而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。看起来各取所长,充分利用这两者的优势是自然而然的趋势了。

5.2 DevOps

image.png

为了解决应用 “持续交付问题”,我们引入了 Devops。

提到交付问题,就想起大学的专业课——软件工程...这是个让人头疼的问题,我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:产品规划、开发编码、构建、QA测试、发布、部署和维护。

最初大家说到DevOps,都是指的‘开发运维一体化’,现在大家说的 DevOps 已经是扩大到“端到端”的概念了。

Devops 理念大家应该比较熟悉了,我理解它是一系列价值观,原则,方法,实践及工具的集合,目的是实现快速交付价值且具有持续改进能力,其核心是用于打破研发和运维之间的隔阂、加快软件交付流程、提高软件质量。

这里就不过多谈论了,给大家列出devops平台搭建工具

  1. 项目管理(PM):jira。
    运营可以上去提问题,可以看到各个问题的完整的工作流,待解决未解决等;
  2. 代码管理:gitlab。
    jenkins或者K8S都可以集成gitlab,进行代码管理,上线,回滚等;
  3. 持续集成CI(Continuous Integration):gitlab ci。
    开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
  4. 持续交付CD(Continuous Delivery):gitlab cd。
    完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
  5. 镜像仓库:VMware Harbor,私服nexus。
  6. 容器:Docker。
  7. 编排:K8S。
  8. 服务治理:Nacos。
  9. 脚本语言:Python。
  10. 日志管理:Cat+Sentry,还有种常用的是ELK。
  11. 系统监控:Prometheus。
  12. 负载均衡:Nginx。
  13. 网关:Kong,SpringCloud Gateway。
  14. 链路追踪:SkyWalking。
  15. 产品和UI图:蓝湖。
  16. 公司内部文档:Confluence。

六、云原生的关键技术

[图片上传失败...(image-8bf0d8-1652200764346)]

6.1 容器

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

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

它也是 “不可变基础设施” 的核心基础。

6.2 Kubernetes

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

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

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

6.3 微服务(Microservices)

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

6.4 无服务(Serverless)

根据 CNCF 的定义,Serverless 是指构建和运行不需要服务器管理的应用程序的概念。即开发人员无需关注底层的基础设施,只需要关注应用程序的业务本身就行,且该服务是可以自动扩展。

6.5 DevOps

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

6.6 ServiceMesh

ServiceMesh 核心是业务逻辑与非业务逻辑解耦,实现开发只需关注业务逻辑的伟大目标。将一大堆和业务逻辑无关的客户端 SDK(如服务发现,路由,负载均衡,限流降级等)从业务应用中剥离出来,放到单独的 Proxy(Sidecar) 进程中,之后下沉到基础设施中间件 Mesh(类似 TDDL 到 DRDS 的模式)。

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

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

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

6.7 基础设施即代码(IaC)

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

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

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

6.8 Cloud IDE

云端 IDE 深入研发的整个生命周期,提供了完整的开发、调试、预发、生产环境及CI/CD 发布一体化体验。云端可提供丰富的代码库模板,通过分布式运算提升编译速度,以 “智能” 方式实现代码推荐、代码优化、自动扫描发现 BUG、识别逻辑和系统性风险。

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

七、云计算和云原生的关系

7.1 云原生是云计算的趋势

  1. 从市场发展趋势看,云计算将是未来IT的主流。

  2. 从技术发展趋势看,更多企业将会广泛应用云原生技术。

  3. 从软件开发角度看,云原生技术为企业带来了更快进行业务创新的价值。

7.2 云原生是云计算的再升级

  1. 整个云原生技术栈都是基于开源、开放的技术标准。

  2. 云原生是对使用云的应用架构的再升级。

  3. 云原生是对云平台的技术和云服务的再升级。

你可能感兴趣的:(什么是云原生)