立即咨询

电话咨询

微信咨询

立即试用
商务合作

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

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的托管服务网格,图片来源于网络)

三、总结

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

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

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

更多产品了解

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

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

都在这里!

 

热门数字化产品

句子互动SCRM系统句子互动SCRM系统,把企业微信账号变成机器人,实现更效率和高频次的触达。基于预设规则和对象特征,让消息推送更智能更精准。 帮助企业打通内外部系统的数据系统,实现更多灵活、更个性化的营销和服务能力开发。同时支持私有部署、iframe嵌入等多种系统接入方式。
携客云采购管理系统SRM携客云的每个应用功能都经过用户的千锤百炼,无论是大型的集团,或是快速成长的企业,都能够为您企业供应链每个管理环节,找到最佳的业务管理方案,并配置您所需要的管理流程和业务细节。
绿云软件酒店管理系统绿云软件酒店管理系统,符合大住宿业数字化建设集中化、一体化、平台化、大数据发展趋势,稳定、经济、开放,支持集中+分布式混合部署。基于绿云开放平台,行业上下游合作伙伴均可接口对接,形成智慧互联 。无须担心“数字孤岛”,各系统和场景的数据在保证安全的前提下互联互通 。
i人事HR SaaS软件i人事HR SaaS软件,实时监控组织发展关心的关键指标,组织整体战斗力、效能与效率,关键岗位的引入、留用与激励。人力预算支出过程管控与预测参考,成本中心与财务科目的灵活匹配,投入产出比核算效率提升。雇主品牌、快速上岗,移动办公,高效协同,员工体验、持续绩效提升。
DuoPlus云手机DuoPlus云手机是云端操控,拓展全球商机,简化多设备跨平台社媒操作,专注打造全球社媒营销、Tiktok、WhatsApp专用云手机!
为你推荐
2025腾讯产业合作伙伴大会|云巴巴荣获双项大奖,载誉而归

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

2025-01-17
传统AI代码工具效率低下?TAPD MCP Server让开发效率与质量双倍飙升

腾讯TAPD作为国内领先的敏捷研发管理平台,可以说是最早拥抱MCP的研发管理工具之一,凭借其全生命周期的研发管理能力,成为AI代码助手的“最强外挂”,其创新功能直击开发痛点。

2025-04-25
如何提升政企客户服务效率?协同管理+规模触达成政企服务质量选型新标准

基于预设规则和对象特征,让消息推送更智能更精准,帮助企业打通内外部系统的数据系统,实现更多灵活、更个性化的营销和服务能力开发。

2025-04-25
如何利用数据分析做好活动营销?海纳嗨数让活动策划执行更加高效便捷

海纳嗨数凭借其专业的数据分析能力,为企业提供从数据采集到深度洞察的一站式解决方案,助力活动策划与执行实现质的飞跃。

2025-04-25
复杂网络环境下,如何通过弱网加速与源站高可用技术架构保障业务零中断?

网宿科技全站加速产品以弱网优化与源站灾备技术矩阵,构建全链路加速体系,通过核心技术为多场景提供端到端保障,实现弱网效率跃升、源站切换无感,助企业突破网络桎梏。

2025-04-24
查看更多