大家好,我是大厂后端程序员阿煜。回望这一路的学习和成长,我深知技术学习过程中的难点与迷茫,希望通过文章让你在技术学习的路上少走弯路,轻松掌握关键知识!
当我们还在争论"Java牛逼还是Go牛逼"的时候,全球IT巨头们已经悄悄开启了新基建竞赛——不是修铁路,也不是盖房子,而是把计算资源变成乐高积木。
- 谷歌工作日每秒有50万次请求搜索请求,全靠云原生架构撑着
- 2023年中国云计算市场规模约6000亿人民币,同比增长35%,预测到2027年将达2万亿人民币
- 微软CEO纳德拉说:微软战略重心是构建AI时代的云原生基础设施(翻译:不转云原生就炒人)
- …
好,既然大势已定,咱们就开开心心搞明白:这到底是啥?跟我有啥关系?
云计算到底是什么?
云计算小故事
我们下面先看下民间故事版,顺便体验下当老板的感觉:想象你要开一家软件公司,采用传统的创业模式。
首先,你得搞服务器采购——光是买几台高性能电脑和数据库服务器,应该就能掏空半年工资吧。
然后得长期养着一帮程序员小哥,工资包吃住还得配咖啡机,人力成本能占到公司总开支的三分之一。
这还没算房租、水电、网费这些固定支出,哪怕公司放假,打印机也得开着待机费电……
那如果你采用云计算的创业模式呢?
服务器?我租的是"云端别墅"
以前买服务器的钱够买辆小轿车,现在打开网页控制台就能生成虚拟机,构建虚拟机房。
想开发新功能?云端秒开10台机器给你跑测试;双十一流量暴增?立刻从"蜗居"搬进"CBD写字楼",连运维小哥都不用请,系统自动帮你监控故障。
最离谱的是月底收到账单,发现当月只用了20块钱——相当于在网吧包夜只花了星巴克的钱。
程序员?AI才是隐藏MVP
以前招人要斗智斗勇,现在云端AI客服24小时接需求,连产品经理都能被替代。
想做个节日活动?系统自动弹窗:“老板!建议临时调用3个写促销文案的外包程序员,预估增收50%”。
大胆一些,外包程序员都可能省了,直接上deepSeek、cursor、ChatGPT…
固定成本?不存在的!空调费都能省!
以前总纠结"下班后关服务器会不会丢订单",现在云端系统会像老妈子一样唠叨:“亲,凌晨两点后访问量低于10次,建议进入节能模式哦~” 关机那刻,电费突然不跳的感觉,就像工资卡里凭空多了笔奖金!
官方定义
现在,我们再来看看云计算维基百科的定义:
云计算(英语:cloud computing),也被意译为网络计算,是一种基于互联网的计算方式,通过这种方式,共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备,使用服务商提供的电脑基建作计算和资源。
云计算具有以下主要特征:
-
按需自助服务(On-demand Self-service: 用户可以自主地根据需求选择和使用计算资源(如存储、网络、计算能力等),而无需与服务提供商进行人工交互,且可以根据业务负载的变化随时调整资源配置。简言之,你的虚拟机房怎么建随便你。
-
广泛的网络接入(Broad Network Access:云计算资源可以通过互联网或专用网络随时随地访问,支持多种设备通过标准机制访问云服务。简言之,你打开手机电脑就能访问到远方的机器~因为远,所以叫做云端嘛。
-
资源池化(Resource Pooling):云计算将大量的计算资源集中管理,并形成一个共享的资源池,这些资源可以动态分配给不同的用户,提高了资源利用率,资源池可能包括服务器、存储、网络带宽等。简言之,云厂商把他们的资源分门别类集中在一起了
-
快速弹性伸缩(Rapid Elasticity):用户可以根据实际需求快速增加或减少资源容量,这种弹性伸缩能力使得企业能够应对流量高峰或低谷,优化成本。简言之,云厂商帮你调控你的虚拟机房大小。
-
可度量的服务(Measured Service):云计算服务通常以某种计量方式(如存储容量、带宽使用量、计算时间等)来计费。简言之,用多少付多少。
-
高可靠性与容灾能力:云计算平台通常采用分布式架构和冗余设计,确保数据和服务的高度可靠性和可用性。即使部分硬件发生故障,系统也能自动切换到其他可用节点,保证业务连续性。简言之,虚拟机房有机器坏了,云厂商马上给你换。
-
多租户支持(Multi-tenancy):多个用户可以共享同一套基础设施,但每个用户的资源和数据是隔离的。简言之,大家都能申请虚拟机房,但都只能访问自己的。
-
位置无关性(Location Independence):用户不需要知道具体的数据中心位置,也不需要关心资源的具体物理分布,数据和服务可以在全球范围内的数据中心之间无缝迁移。简言之,你的虚拟机房现实是啥样,不用管。
现在,我们再结合官方定义,将云计算的定义总结为一句相对好理解的话就是:云计算就是指云厂商给用户提供灵活的、按需分配的弹性计算资源,并协助他们完成在云端进行处理的服务。
现在有帮助到各位理解到什么是云计算以及云计算的好处了吗?
服务模式:IaaS、PaaS、SaaS
服务模式就是指云计算以怎样的方式提供服务给用户,云计算的服务模式有:
- Iaas(Infrastructure-as-a-service,基础设施即服务)
- Paas(Platform-as-a-service,平台即服务)
- Saas(Software-as-a-service,软件即服务)
听上去有点高大上,但其实很好理解,假设你想要做饭,找我寻求帮助。
锅碗瓢盆灶台等等,这就是基础设施。我给你用锅碗瓢盆,这就是给你提供基础设施的服务,这就是Iaas。
锅碗瓢盆加葱姜蒜肉等食材,这就是平台。我不仅给你用锅碗瓢盆还给你用葱姜蒜等食材,这就是提供给你平台作为我的服务,这就是Paas。
用锅碗瓢盆加葱姜蒜肉等食材做出来的菜,这就是软件**。如果我直接做好给你端上来,这就是将提供软件作为我的服务,这就是Saas。**
现在我们把思路转移到云服务场景:
-
IaaS 是云服务的最底层,主要提供一些基础资源,例如存储、网络、计算资源等等。
-
PaaS 提供软件部署平台, 抽象掉了硬件和操作系统细节,这样开发者关注自己的业务逻辑即可,例如运行时环境、数据库软件等等。
-
SaaS 是软件的开发、部署、维护都交给第三方,不需要关心任何技术问题,普通用户可以拿来即用。所有我们能接触到的互联网服务都是Saas,例如公众号创作平台、小红薯平台等等,所以Saas不是什么新东西。
部署模式:各种云
其实部署模式的概念是通过消费者来源进行划分的,包括私有云、公共云、混合云、社区云。
-
私有云: 企业自建或托管的"专属机房",数据完全掌控在自己手中,消费者来自同一组织。 例如政府机构涉密数据必须本地化。
-
公有云: 由第三方云厂商搭建的"共享机房",所有用户按需付费使用,消费者是所有互联网用户。 例如华为云、腾讯云等等。
-
混合云: 公有云+私有云组合拳,业务自由切换,部分消费者来自某一组织,其他来源用户也能访问一些资源。例如零售企业日常运营用公有云,大促期间调用私有云等。
-
社区云:多个组织共享的"行业云",满足特定领域需求,消费者来自多个组织,组织集合外的消费者无法访问。 例如医疗行业,患者数据本地化,科研分析上云等等。
什么是云原生?
现在我们已经从各个方法理解了云计算,那么什么是云原生呢?
云原生这个概念是建立在云计算之上的,云计算是云原生的土壤。
其中,“云”表示应用程序位于云端(通过互联网连接到的远方主机群~)*, 而不是传统的数据中心。
“原生”就是土生土长的意思,即应用一诞生就是基于云的,可以直接在云上运行或非常轻松地迁移到云上。
云原生是一种构建和运行应用程序的方法,强调应用从设计之初就考虑到了云计算环境的特点,并充分利用了云平台提供的各项能力。
应用因云而生就是云原生。
是不是还有点抽象?什么叫做“一诞生就是基于云的”?
举一个栗子,如果是传统的文件管理软件,比如Windows Explorer,从架构上来说通常是一个整体式的应用程序,所有功能都被打包到一个可执行文件中。同时,开发周期较长,每次更新都需要经过复杂的测试流程,并且可能需要用户手动安装补丁或升级。当然,需要使用要在每台计算机上单独安装,无法轻松实现跨设备同步。依赖于用户的系统设置和个人习惯,缺乏集中化的管理和支持。
然而,如果是基于云的软件:
-
架构:云计算强调资源弹性伸缩,但传统单体应用所有功能耦合在单一进程中,无法实现细粒度扩展。所以,应用需要使用微服务架构,将不同的功能模块化,每个服务都可以独立扩展和更新。
-
开发方式: 采用DevOps实践,开发团队能够快速迭代并自动部署新版本。
-
部署方式:传统虚拟机部署存在资源浪费,启动慢等问题。利用容器化技术(如Docker),确保应用在不同环境中的一致性,并通过Kubernetes进行编排和管理。
-
维护方式: 自动化监控和日志收集帮助运维人员及时发现和解决问题,同时支持弹性伸缩以应对流量波动。
这样的云原生软件有什么优势呢?
主要目的是为了让程序员或者企业更专注于业务,运维、扩容缩容等和业务无关的操作都交给“云”。
背后的趋势就是:能自动化就自动化,提高开发效率。
实现云原生包含哪些关键技术?
如果要应用从设计之初就适应“云计算”这样的土壤,需要用一些方法对应用将进行改造:
-
面向微服务架构:云计算强调资源弹性伸缩,但传统单体应用所有功能耦合在单一进程中,无法实现细粒度扩展,所以应用需要设计为微服务架构。 就像把大超市拆成多个专卖店。每个小店(微服务)专注卖一类商品(功能),独立经营(部署),通过快递(API)互相合作。这样某个小店装修(故障)不会影响整个商场运营。
-
容器化技术:相当于用标准集装箱运输货物。传统虚拟机部署存在资源浪费,启动速度慢的问题,容器化技术将应用与依赖环境打包为标准化单元来解决。每个集装箱(容器)里装着货物(应用)和包装说明书(依赖环境),无论用轮船、火车还是卡车(不同服务器),打开就能直接使用,保证货物不变质(环境一致)。
-
服务网络:相当于给所有快递员配对讲机。 微服务间通信复杂度呈指数增长,通过Sidecar代理统一处理流量管理、熔断降级等非业务功能。 每个微服务配备一个贴身助理(Sidecar代理),自动处理包裹路线规划(流量控制)、检查包裹安全(身份验证)、记录物流信息(监控),老板(开发者)不用亲自盯每个快递。
-
不可变基础:像一次性餐具。 传统服务器"热补丁"方式会导致环境配置残留,这通常是故障根源。 现在,服务器配置好后直接"塑封"(镜像化),需要修改时就换套新餐具(新建实例),而不是洗洗重复用(修改原有服务器)。避免残留油渍(配置残留)导致食物中毒(系统故障)。
-
容器编排技术:类似物流调度中心。 当有成千上万个集装箱(容器)需要运输时,Kubernetes这类工具会自动决定哪个港口(服务器)卸货、如何分配卡车资源(CPU/内存),还能在堵车(故障)时自动改道,而不是人工协调。
-
声明式API:类似告诉导航"我要去机场",而不是指挥"左转200米再右转"。云环境下存在数千节点动态变化,传统命令式运维肯定无法应对。现在,有了容器编排技术的自动化,你只需说最终目标(如"需要5个副本"),容器编排系统自己规划如何实现,即使遇到封路(节点故障)也会自动绕路达成目标。
现在,对于这些概念是不是好理解多了?
我会在之后的文章实践这些技术,相信你阅读并操作之后会有更深的理解。赶紧上车,可以关注下我,朋友~
云计算和云原生有什么区别?
最后,再来总结一下云计算和云原生的区别:
-
云计算是一种基础设施和服务交付模式,关注资源的提供和管理。
-
云原生是一种应用开发和运行的理念,强调通过现代技术(如微服务和容器,现在基本指docker和k8s)充分利用云计算的优势。
它们和业务程序员有什么关系?
如果你也许会想,嗯,写的很好,但是:
咱们天天写业务逻辑的,这和我有什么关系呢?
关系可太大了,朋友~
首先,云原生技术会使得开发模式开始重构。
传统的开发范式:
云原生时代开发范式:
例如,当你要实现订单服务的限流功能时:
传统方式是在Java代码中嵌入Guava RateLimiter,调整参数需重新编译打包,云原生方式是通过Kubernetes Ingress的annotations配置限流策略,修改后马上生效。
这就要求需要以下技能:
- 基础设施即代码(Terraform编写云资源模板)
- 配置即代码(Helm Chart管理K8s配置)
- 策略即代码(OpenPolicyAgent编写安全规则)
另外,云原生技术会使得运维能力的渗透。
以前的开发职责是:
现在的开发者需关注:
例如,现在程序员开发完之后需要思考如何编写一个Deployment声明:
resources: # 直接影响成本与稳定性
limits:
cpu: "1"
memory: "2Gi"
requests:
cpu: "0.5"
memory: "1Gi"
autoscaling: # 流量突增时的自救机制
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
这也是DevOps理念的具象化。
进入云原生时代之后,程序员是代码运维双栖动物,既能写Java/Go等业务代码,也能写Dockerfile定义环境;
是YAML语言专家,能够熟练编写K8s资源配置,甚至比写XML更频繁;
是混沌工程实践者,主动注入故障测试系统韧性(如使用Chaos Mesh);
是可观测性设计师,在代码中埋入Prometheus指标、OpenTelemetry追踪;
是云经济学精算师,优化容器规格配置,平衡性能与云成本。
在云原生时代,软件开发的战场已经从"实现功能"升级到"构建具有弹性、自愈能力的数字生命体"。
就像生物进化出细胞膜(容器)、神经网络(服务网格)、DNA复制机制(不可变基础设施)一样,今天的工程师正在用代码创造具备云原生基因的数字生命系统。
这不仅是技术升级,更是一场开发哲学的范式革命。
参考
- https://www.ruanyifeng.com/blog/2016/07/google-monolithic-source-repository.html
- https://m.163.com/dy/article/JJHDQCGE05534HHB.html?clickfrom=subscribe
- https://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html
- 《云计算通俗讲义》
- https://time.geekbang.com/column/intro/100114501
评论记录:
回复评论: