立即咨询

电话咨询

微信咨询

立即试用
商务合作

一文看懂云原生架构的演变过程

2021-12-16

人类的需求始终是技术快速发展的内置动力,云原生的快速发展也在于此。从去中心化、微服务到Serverless,服务在变、架构在变,新技术应用所带来的问题也在不断变化。云原生生态体系中的任何一项技术、任何一家厂商、任何一个终端用户,都在解决、适应乃至拥抱这种变化。用技术解决技术所带来的问题,由此出现了云原生“可观测性”。但在云原生庞大的生态体系中,K8s也好、可观测性也好,都属于冰山一角,背后有更多复杂的技术作为支撑。当我们在“享受”云原生所带来的变化的同时,也理应追溯云原生技术的演进脉络,思考云原生的技术价值与发展未来。

图片

(K8S技术分水岭,图片来源于网络)

从楼上这张图说起吧~要想完全掌握如图K8S的技术拓扑,毫不客气的讲:实在太难了! 然而,K8S也只是云原生体系中的一环。

譬如诺豆公司「化名」使用K8S已经2年了,而最近遇到的 Node 节点 NotReady 的问题,还不能完全凭借自有运维团队的能力解决,最终还是依靠公有云技术支持才得以定位到问题,在解决问题的过程中有如下插曲:

  • 根据日志报错,完全搜索不到相关技术贴「怀疑公有云厂商修改了K8S的调度脚本」;

  • 大量非关键日志掩盖/var/log/message中K8S pleg核心报错,经验不足,忽略关键日志,错失关键切入点;

  • 某公有云厂商的首次诊断结果是:runc 通道阻塞,需更换自研OS方可解决;

  • 方案被严厉拒绝后,派遣高工介入,修改结论为:docker 19.3.5 版本  runc 有BUG,升级至 19.3.15 可解决。

  • 核因并未找到,怀疑 max_pid 和 ulimit不足、机器负载高、及container频繁exec health check导致 runc hang,但无实据,而服务器状态很健康。

继而引发的思考:

  • 问题一:如何在公有云上获得更自主可控的运维管理能力;

  • 问题二:版本升级成本高昂,如何平滑升级;

  • 问题三:「上述问题出现在测试环境」,生产环境出问题的SLA如何保障。

问题一和三很容易解决,多云或者混合云方案,加强对供应商管理与对接。问题二很难,纵观整个行业,少有公司掌握自我升级能力,基本都要依赖公有云方案或者第三方协助。核心原因依旧在于K8S和云原生的技术门槛太高。但云原生和K8S大火是客观存在的事实,今天我们来聊聊云原生时代下技术演进

一、架构演变

图片

(大型机到微服务架构演变,图片来源于网络)

自20世纪70年代开始,无论是软件架构还是服务托管,都在逐步从中心化向去中心化转变,从宏服务向微服务转换,从大型机到微型机转换。在中国去IOE指导方针下,该现象尤为突出。

1.1 中心化->去中心化

70年代,早期的IT基础设施不成熟,以大型机为主,中心化运算、存储、调度,客户端终端只具备最基础的输出和展示功能。

该思想一直沿用至今,软件工程上诸如:Satstack、Puppet、OpenStack等。去中心化的代表:Ansible、Git、P2p协议、区块链技术、共识机制。前两者具备去中心化思想,后两者属于完全去中心化。两者没有绝对的好与坏。现代工程软件多为两者结合。

1.2 IaaS->PaaS->SaaS->Serverless

互联网早期以机房托管为主,即IaaS。随着公有云发力与成熟,逐步向云托管转向,有如下优势:

  • 各职能各司其职,关注各自领域即可;

  • 资源按需付费,相对自建,中小规模下有较大成本优势;

  • 弹性架构设计;

  • 服务开箱即用等。

近年云原生概念逐步普及并落地,强调软件应用应该生于云上,长于云上 。云原生本质并非一门确切的技术或者定义, 而是整套完整的生态体系,或者理解为愿景。

云原生给予的标准化架构及解决方案、高度运维自动化、自愈及配套基础设施等运维能力,倒逼运维向更高层领域转向。据公有云财报,目前,IaaS仍在市场上占据最大份额,云原生协助厂商打造不可变基础设施,本质上讲云原生是系统化能力,因此,未来PaaS、SaaS一定会后来居上。

1.3  All in One->微服务 

PMP提出的软件开发模式主要有

  • Build-and-Fix Model模型

  • 瀑布模型

  • 迭代模型

  • 增量模型

  • 喷泉模型

  • 演化模型

  • 敏捷开发模型

  • 混合模型

无论哪种模式均不是万能解药,最终目标都是准确快速交付。交付结果通常依赖:

  • 软件开发模型

  • 项目周期长短

  • 技术人员水平

但以上都无法解决“1个孕妇10个月生一胎,10个孕妇1个月生一胎”的问题。微服务解决了如上问题,且提供各接口遵循gRPC或Restful接口。但在服务切割、解耦、依赖关联上无法细化,经验主义。

  • 过粗的拆分效果不佳;

  • 过细的拆分,导致微服务爆增,资源浪费严重,接口和服务维护成本高昂;

  • 需求变更导致过去拆分策略不佳;

无论以上哪种情况,最终都要面临微服务暴增导致的“死星”式调用链。该情况并非只发生在巨头身上的极端情况。

图片

(死星调用链路,图片来源于网络)

最终,还是要回归到去中心化思想,回归到云原生。

我们一再强调,云原生提供的解决方案,是系统不可变基础设施服务网格(Service mesh)、边车(Sidecar)、服务编排和容器之类的新兴架构模式可以有效地阻止基于云的世界中出现的各类错误实践

二、云原生的架构

随着云平台的面世,尤其是出现了像 Kubernetes这样的容器编排技术后,服务网格就开始引起人们的关注。服务网格是应用程序服务之间的桥梁,它带来了许多附加功能,如

  • 流量控制

  • 服务发现

  • 负载平衡

  • 弹性

  • 可观察性

  • 安全性等

它使应用程序可以从应用程序级库中卸载这些功能,并允许开发人员专注于业务逻辑。

图片

(云原生技术应用演进,图片来源于网络)

诸如Istio之类的某些服务网格技术还支持混沌注入之类的功能,以便开发人员可以测试他们的应用程序,以及多达数十种相互依赖的微服务的弹性和健壮性。

应用和云通过Sidecar旁路容器作为桥梁交互,每个容器通过代理应用将本身所需要的进出,所以云就可以非常容易地通过这样一个代理,调节流量、做流量切分,这也是 Service Mesh 的基本原理。

服务网格非常适合放在平台即服务(PaaS)和容器即服务(CaaS)之上,并通过这些通用平台服务提升推行云计算过程的体验。

2.1 无服务器架构

在最近的云原生演进中,另一个备受关注的趋势是无服务器架构,也称为无服务器计算,基于公有云厂商算力,运行coding。无服务器比 PaaS 模型更进一步,因为它将服务器基础架构从应用程序开发人员那里完全抽象出来。开发只需关注代码即可。

在无服务器中,我们将业务服务编写为函数,并将这些函数部署到云基础架构中。无服务器技术的一些例子包括Amazon Lambda、Spring Cloud Function、Google Cloud Functions和Microsoft Azure Functions等。

无服务器模型位于云托管范围内的 PaaS 和 SaaS 之间,如下图所示:

图片

(各类服务架构,图片来源于网络)

对比单体服务与微服务,并非所有解决方案都应作为函数来实现。我们也不应使用无服务器函数替换所有微服务,就像我们不应替换所有单体应用,或将其分解为微服务一样。只有诸如用户身份验证或客户通知之类的细粒度业务和技术功能,才应该设计为无服务器函数。小结:合适的才是最重要的,无所谓先进 。

根据我们应用程序的功能性和非功能性需求(例如性能和可伸缩性以及事务边界等),我们应该为每个特定用例选择适当的单体、微服务或无服务器模型。常见的情况是,我们可能需要在一个解决方案架构中使用所有这三种模式。

如果设计不当,无服务器解决方案最终将变成纳米片,其中每个函数都与其他函数或微服务紧密结合,并且无法独立运行。

2.2 服务编排

当我们在说容器编排的时候,我们在说什么?

在传统的单体式架构的应用中,开发、测试、交付、部署单个组件不存在编排概念。而云原生时代,主要为了解决微服务和容器通信和HPA、VPA场景,运维将面临新挑战我们需要将单体式的架构拆分成越来越多细小的服务,运行在各自的容器中,那么该如何解决它们之间的依赖管理、服务发现、资源管理、高可用等问题?

在容器环境中,编排通常涉及到三个方面:

  • 资源编排

  • 负载编排

  • 服务编排

Kubernetes常见控制器编排方式:

  • Deployment

  • StatefulSet

  • DaemonSet

  • CronJob

  • Job

图片

(K8S编排调用链,图片来源于网络)

2.3 服务网格

与传统的微服务架构相比,基于服务网格的解决方案在连接性、可靠性、安全性和可观测性方面提供了诸多好处。

连接性:

  • 流量控制(路由、分流)

  • 网关(入口、出口)

  • 服务发现

  • A/B 测试、金丝雀

  • 服务超时、重试

可靠性:

  • 断路器

  • 故障注入/混沌测试

安全性:

  • 服务间身份验证(mTLS)

  • 证书管理

  • 用户身份验证(JSON Web Tokens)

  • 用户授权(基于角色的访问控制)

  • 数据加密

可观测性:

  • 监控

  • 遥测、仪表盘、指标

  • 分布式跟踪

  • 服务图

服务网格技术常见实现:

  • Istio

  • Linkerd

  • Consul Connect

图片

(面对K8S的托管服务网格,图片来源于网络)

三、总结

  • 互联网技术日新月异,技术不是终点,只是工具的一种,协助达成目标的过渡过程;

  • 云原生不是工具,而是体系架构和生态,是一套系统解决方案,更是标准基础设施;

  • 架构是演变出来的,不是设计规划出来的。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里!

 

热门数字化产品

分贝通企业支出管理平台分贝通企业支出管理方案,全面满足企业费用支出管理需求。一站式企业支出管理平台,体验全新企业支出体验,全流程费控,全场景支付,提供整合的数据及流转。为高成长企业带来一站式的企业支付体验,帮助财务更高效、更数字化的管理费用支出。
有成CRM有成CRM是一款SaaS模式的客户关系管理软件,以客户管理为核心,包含客户管理、销售全流程管理,合同订单、项目管理、工单管理、呼叫中心、移动审批、数据分析八大模块。旨在助力企业销售全流程精细化、数字化管理,全面解决了企业销售团队的全流程客户服务难题,帮助企业有效盘活客户资源、量化销售行为,合理配置资源、建立科学销售体系,提升销售业绩。
连连国际外贸支付连连国际外贸支付专注于提供一站式跨境支付解决方案,服务包括全球收款、阳光结汇、多币种汇兑等,满足不同进出口场景的合规申报需求。一站式外贸收付兑服务,打造极致用户体验。
DuoPlus云手机DuoPlus云手机是云端操控,拓展全球商机,简化多设备跨平台社媒操作,专注打造全球社媒营销、Tiktok、WhatsApp专用云手机!
上讯信息敏捷数据脱敏系统SDM敏捷数据管理平台软件(ADM)是上海上讯信息技术股份有限公司(以下简称“上讯信息”)自主研发的,主要面向金融、运营商、政府、能源、医疗等行业打造的全生命周期数据安全管理软件产品,用于数据备份、备份数据恢复验证、测试数据交付和静态数据脱敏等应用场景,可为企业上、中、下游数据的高效使用和安全管控提供一套整体解决方案。
为你推荐
2025腾讯产业合作伙伴大会|云巴巴荣获双项大奖,载誉而归

1月16日,2025腾讯产业合作伙伴大会在三亚召开。云巴巴,荣膺“2024腾讯云卓越合作伙伴奖—星云奖”和“2024腾讯云AI产品突出贡献奖”双项大奖

2025-01-17
数智化转型下,AI如何重塑供应链管理新生态?洞隐赋能端到端协同

洞隐科技以AI驱动的端到端供应链数智化解决方案为核心,通过整合“供应链管理云平台+行业数字化方案”,构建覆盖从原材料采购到终端交付的全场景协同网络,为制造企业提供从流程优化到智能决策的一体化破局路径。

2025-04-02
打破传统枷锁,MeFlow携手DeepSeek,如何重塑合同管理“不可能三角”

如何在严控合规风险的同时,实现合同全流程自动化与数据穿透?这需要一款深度融合法律专业性与AI技术落地能力的系统。

2025-04-02
如何选择高效的企业知识管理方案?腾讯乐享+DeepSeek让知识库活起来!

如何让AI变得又聪明又懂企业,真正成为企业数字化转型的生产力引擎?

2025-04-01
40万条信息被卖!物流行业如何自救?网宿云WAF三招筑牢物流Web防线

在物流行业实践的基础上,网宿云Web应用防火墙(WAF)凭借部署简易、精准防护、弹性架构、智能双引擎等核心能力,为其他数据密集型行业构建全场景安全防线,其技术优势深度适配各行业数字化转型需求。

2025-04-01
查看更多