06 | 无服务时代:“不分布式”云端系统的起点
- 深入了解
- 翻译
- 解释
- 总结
无服务架构是近年来兴起的一种新型架构,旨在让开发者专注于业务逻辑而不必关心技术组件、部署和运维。该架构的核心是后端设施和函数,分别对应后端即服务和函数即服务。云计算的成功落地为无服务架构提供了相对无限的性能支持,使得云服务提供商能够满足系统对性能的需求。尽管无服务架构在降低开发和运维成本方面具有优势,但其天生的一些特点,如冷启动、无状态和运行时间限制,使其并非适用于所有应用场景。然而,随着云计算的持续发展,无服务架构有望成为一种主流的软件架构形式。与微服务架构不同,无服务架构并非微服务的替代品,而是“不分布式”的云端系统的起点。未来,多种架构风格将会融合互补,软件开发将呈现多样化并存的形态。文章指出,无服务架构的兴起与当年微服务架构相似,对其未来推广持谨慎乐观态度。在架构演进之路上,未来还会出现更多形式的架构风格,呈现多样化并存的趋势。
请先领取课程
全部留言(25)
- 最新
- 精选
- 大D一口气读完老师的这8讲,有些酣畅淋漓。2011年刚毕业开始使用MuleESB做集成,当时对WebService那一套东西也是初次接触,soap、wsdl、wadl等等那一套东西,用了一年也没用搞明白都是干啥用的,就是俩字"复杂“。多年后虽然明白了那一套东西,但回想起来也是心有余悸。再后来公司的产品采用osgi的方式,自己通过订制eclipse插件的方式开发了一套IDE,每次打包要勾选一堆的依赖,解决依赖冲突、查找依赖,苦不堪言。这些东西本身就有很多技术壁垒和学习成本。再后来maven流行,开始各种分模块,再后来公司用mq实现了一套总线,现在看来类似老师讲的事件驱动架构,这架构要自己解决很多负载、补偿、事务等问题,总的来说还是比之前有进步。知道微服务的出现,感觉轻松了很多,框架层面的东西已经有很多解决方案,选择一个合适的就行,其它的专注于业务开发即可。现在的年轻人确实赶上的一个好时代,不用理解那么多的复杂实现,更多的磨练自身编码能力。但经历过的都是财富,不然也不会对老师的课程产生强烈的共鸣。 期待老师后续的课程,期待学习更多的知识。
作者回复: 感谢认可
2020-11-3057 - walkingonair首先,感谢老师的分享。我正在腾讯云上摸索无服务的架构模式,完全赞同老师的说法。选择无服务的初始原因是由于微信小程序生态的强大,在腾讯云开发上来进行产品的开发能大大降低人力成本、运维成本,提高产品开发速度,能让一般创业小公司度过艰难的初期。同时,无服务的架构模式,也能在业务量快速上升时,只需要简单增加成本投入即可快速提高整个架构的业务承载能力,满足未来更大的业务增长。 但是这种架构模式的不足也是十分明显的: 1、我虽然是一个全栈开发工程师,但是平常使用最多的还是java语言,而java的运行离不开java虚拟机,那么在这种架构下使用java开发的云函数性能上能得到保证吗?这个问题我保持怀疑态度,这也导致我在语言方面选择的是node,另外一方面也更适合小程序开发者。 2、虽然,无服务与编程语言无关,但是工程师的开发能力与语言有关,代码的规范、设计、管理方面与语言有关,像老师所说,做到普世性还有很长的路要走。 3、由于无服务架构对非业务层(云函数)的封装,一些特殊需求变得难以实现。例如云数据库的封装和限制,使基于云函数的开发,批量数据变得难以处理,函数运行的超时时间限制和数据库对大批量获取的限制,都是瓶颈。 待续
作者回复: 关于第1点,正好前这个月初QCon深圳站时,和朋友吃饭闲聊有讨论到,我分别问了在腾讯云、阿里云负责Serverless的同学怎么看。大致的观点是“单纯的Java”作为云函数使用,还算是有可能,如果对启动性能确实敏感,也可以通过长期维持一个最低实例数来变通解决。但问题是单纯的Java能做的事情太局促了,要想让主流的Spring生态在Serverless上跑起来,大家认为还不太现实,等过两年SpringFU、Spring Graal Native这样的项目成熟之后在看看。
2020-12-31220 - lmdcx老师对事物(技术)的洞察,总是那么清明透彻 感觉我是技术迷雾中迷失的人,而老师是站在上帝视角看技术的人
作者回复: 感谢认可
2020-11-30214 - 李雷软硬界限再改变,更多的东西划入基础设施,慢慢的我感觉程序员要失业了
作者回复: 要有信心。
2020-12-092 - Jxin回答: 1.略懂,在用。 2.公司有内部的,其他我只用过AWS的Lambda。 疑虑: 1.使用sls去做bff层的流程编排和数据聚合,那是真的香。但用sls去实现微服务架构,这就很尴尬,哪怕有健全的接口树(发布faas需要维护一个接口树的结构),你也会发现,整个基建很松散,无法像oo那样做到结构性的复杂性屏蔽,顶多只能算封装了一定的实现复杂性。所以,现实中真的用sls去实现微服务架构,倒是真想看看是如何做的,期待在周大佬后续章节中获得答案。(对象具备多个相关性强的功能,而函数只有一个功能,在设计上这是个问题)
作者回复: 你的疑惑并不是你没想清楚,而是目前serverless自身的局限。现在的仍然是只当游击队,不做正规军的状态,我也期待后续的演进发展。
2020-11-301 - Wacky小恺之前在朋友的介绍下只了解Serverless是一个叫做“云函数”的名词,但不明白背后的工作原理和这样做的意义。 今天这一讲获益匪浅,熟悉了无服务背后的运作关系。虽然无服务现在价格还比较昂贵,但我相信它在未来的互联网发展中会慢慢成为“水,电,煤气”这样的基础设施,运营商会降低它们的成本,就像当时的4G一样,慢慢推广普及到千家万户。
作者回复: 很好的总结
2020-11-301 - hqx有个小问题: 从描述来看,无服务架构对公有云厂商是很有利的,可以很好的吸引用户。但对软件解决方案提供商来说,对无服务该怎么去拥抱呢?也是做一套后端的基础设施吗?
作者回复: 无所谓拥抱,适合serverless的应用会用得很爽,不适合的也不可能强求。
2020-12-03 - 李皮皮皮皮皮我试过使用aws部署过一个简单的web应用。唯一的感觉就是简单,自己只需要编写逻辑处理代码,剩下的完全自动化了。随之而来的就是疑惑,程序优化(性能优化,数据库优化,io优化)都不用做吗?难道又回到了上个世纪大家都迷信摩尔定律,让硬件性能的提升来代替软件优化?未经优化的程序运行占用的时间和空间相比优化之后的程序,将是数量级上的差别。想象一下,顺序查找100w行记录和加索引的查找。所以肯定要有优化逻辑,至于能优化到什么程序,未来会不会有新的概念和技术来解决这些问题。我持有和老师一样的谨慎的乐观态度。2020-11-3039
- STOREFEE用过无服务函数,aws 的应该是目前最完善的。整个环节配置也是最复杂的。国内的两大厂商应该算是追随它的脚步在前进。 就目前看,实操过程中,大规模复杂的应用不是很适合,需要函数间互调很麻烦,容易超时。部署代码容易,但是线上调试更麻烦,特别是云环境本身环境问题时。2020-12-034
- Mr.Chen【产生“无服务比微服务更加先进”的错误想法】要不是老师特别提醒,由于对无服务比较陌生,果真产生了这种错误想法!2020-12-013