写点什么

Serverless 奇点已来,下一个十年将驶向何方?

作者:Serverless Devs
  • 2023-01-10
    浙江
  • 本文字数:5072 字

    阅读完需:约 17 分钟


本文整理自 QCon 上海站 2022 丁宇(叔同)的演讲内容。


以前构建应用,需要买 ECS 实例,搭建开源软件体系然后维护它,流量大了扩容,流量小了缩容,整个过程非常复杂繁琐。


用了 Serverless 服务以后,这些问题都简化了,从半托管到全托管,所有服务 API 化,无限容量充分弹性,可以组装使用,生产力大幅改变。同时推动软件研发模式升级,组装式研发将成为主流。


基于阿里云全面 Serverless 化的经历,阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇(叔同)阐述了企业应用架构的演进历程,以及 Serverless 兴起带来的行业变化。过去十年,上云成为确定性的趋势。


在上云阶段,企业关注点在于如何实现平滑上云,因此云厂商将云托管(Cloud-Hosting)作为核心策略。云的主要形态是资源型服务,以虚拟机的形式为企业提供海量的算力。


对开发者而言,虚拟机的功能和使用方式和 IDC 中的物理服务器没有区别。原有的应用、技术栈不需要改变就可以平滑上云。云托管的策略很好地满足了企业在上云阶段的核心诉求,因此取得了成功。


随着越来越多的企业上云,甚至很多企业系统第一天就是在云上构建,企业的核心关注点转变为如何更好地利用云的能力,将产品快速推向市场,从而实现业务成功。


这促使云在下一阶段发展的主要目标转变为利用云自身的优势,解决大规模复杂应用的开发和运维挑战。但是,如果算力的呈现形式仍然是服务器这样的资源形态,它的使用门槛依然很高。算力和业务相隔太远,企业需要有一整套支撑应用的基础设施来用好算力。


如何让算力像电力一样的普及,云计算需要新的形态。


云服务的角色将发生巨大的变化,不再是单纯的提供资源,而是要成为企业构建应用的新平台,要帮助企业尽可能减小机器运维等低价值重复工作,聚焦于业务的创新。


下一个十年,是云演进自身能力,帮助企业用好云的阶段,而云厂商的核心能力就是 Serverless 云服务。


为什么选择 Serverless

Serverless 服务是全托管的

云厂商可以通过存储计算分离,软硬协同优化等底层技术,大规模提高服务的资源效率和性能。以阿里云存储服务为例,自 2018 年开始大规模使用 RDMA 技术,自研了 Solar-RDMA 协议,以及 HPCC 流控和端网融合技术。


通过网络和存储的协同设计,结合 FPGA 硬件加速压缩算法等能力,实现了稳定的微秒级的读写性能。企业只需要调用服务 API,就能使用云厂商在相关领域的专业能力,享受到技术红利。


Serverless 服务具备自适应弹性,让企业的应用更平稳的应对业务负载不可预测或者突然爆发的情况。


一个典型的业务系统可划分为应用层、接入层、资源层。资源型的云服务只提供了资源层面的弹性能力,企业还需要实现接入层和应用层的弹性能力,才能做到业务的全链路弹性。


1)架构设计阶段根据各个组件的依赖关系,制定弹性伸缩和限流降级方案。对于关系型数据库等几乎没有弹性能力的服务,一般需要预测未来 3 年对数据库的写入和读取规模,进行分库分表。


2)资源规划阶段权衡各个组件的扩缩容难易度、伸缩速度、业务负载变化速度等因素,通过冗余资源实现相应的弹性能力。接入层资源占比在整个系统不高,维持较高冗余资源成本不高,也比较容易扩容。应用层的资源规划最具挑战。应用层是资源消耗大头,一般不允许通过很高的冗余资源来扛住负载峰值,此外应用层的扩缩容牵扯上下游链路,复杂度很高。最后,应用层不同服务的流量规模不同,需要梳理清楚,重点做好热点链路的冗余资源规划。


3)线上运行阶段通过完整的可观测能力,建立量化链路的流量,检测热点,进行动态扩缩容,再量化热点链路流量,再判断是否进行动态扩缩容的闭环。此外,完整、及时的监控报警也是十分必要的,为不同组件设定不同的热度阈值,检测到热度流量后,系统要及时的广播给关联组件的开发、运维人员,根据预定方案进行处理。



可见,在资源层的弹性能力上构建整个业务的弹性能力复杂度非常高。Serverless 服务的自适应弹性目标就是为了简化复杂度,帮助企业更容易实现业务弹性。


首先云厂商会将大量中间件、数据库、大数据等 BaaS 化的服务 Serverless 化。以数据库为例,不但提供 NoSQL 等天然具备高弹性能力的数据库服务,也将传统的关系型数据库 Serverless 化。


其次, Serverless 计算服务通常具备百毫秒到秒级的实例启动速度,每秒钟启动数千甚至上万实例,以及高度自动化的弹性伸缩能力,配合 Serverless 化的 BaaS 服务,将实现全链路的业务弹性。


最后,Serverless 服务通常内置了限流降级的能力,让企业资源可控,更容易应对系统雪崩的问题。


如何高效的利用好资源,是企业面临的一个普遍的难题。业界数据中心的统计数据表明,企业整体平均资源利用率是不高的,一般小于 15%。要提高资源利用率,企业一般面临以下挑战:


  • 各个业务部门资源使用相互独立,没有资源并池,没有统一调度。

  • 出于对性能、负载峰值以及业务未来发展保障等因素的考虑,业务部门一般倾向于多申请资源,通常是实际使用资源的 3-5 倍。

  • 非核心应用碎片化的资源消耗导致了大量资源浪费。大量非核心应用为了满足高可用的要求,至少需要 2-3 台机器,而这些应用很多时候是长尾、低频调用的,甚至业务下线但服务器忘了释放,造成资源浪费。在阿里巴巴集团,非核心应用消耗的资源甚至超过了核心应用。

  • 不同性质的应用没有共享资源,没有削峰填谷,集群整体资源利用率不高。


容器化是提高资源利用率的有效手段,但实施的复杂度较高。阿里巴巴集团通过全栈容器化,统一调度和离在线混部来提升资源的整体利用率,涉及到容器性能的优化、租户隔离、底层服务器算力归一化、定制的资源统一调度和离在线混部等等。


Serverless 的目标让企业用更简单的方式提高资源利用率,降低成本。


以函数计算为例,企业不需要为闲置资源付费,而是根据实际使用的资源付费。这意味着大量测试、预发甚至生产环境,大量非核心应用碎片化资源的使用场景,使用 Serverless 后资源利用率会非常高。


如果从性能角度考虑,需要预留一些资源,函数计算的闲置资源费用也比服务器更低。函数计算内置了多 AZ 容灾能力,企业不需要为容灾准备冗余资源。函数计算支持百毫秒级别的弹性伸缩速度和丰富的伸缩规则,企业不需要为峰值负载预留资源。


当云服务演进为 Serverless 形态后,企业的使用门槛大大降低,Serverless 将让算力像电力一样普及。

驱动研发模式升级

应用架构和研发模式的演变主要是由企业的业务发展诉求推动的。企业总是期望能够更敏捷的应对业务规模和复杂度的增长,更快的将产品推向市场,加快业务创新的速度,这就要求技术能支持大规模、复杂软件的快速迭代。


传统的企业级应用架构,通常是单体的,所有模块都耦合在一起,同时发布。这种单体架构应用在一开始是易于管理的,但随着业务发展,会带来巨大的复杂度。这种强耦合的架构带来开发、测试和运维过程中大量的冲突,拖慢了整个迭代速度。


例如整个应用的开发要求所有模块采用统一的语言和框架技术栈,如果一个基础库被多个模块共享,其中一个模块想要升级到新版本,则需要说服所有人同时升级,即便其他人并不需要新版本。所有模块的发布节奏被强行拉齐,一个模块的问题会影响整个应用的发布。


想要快速修复某个模块的线上问题也变得非常困难,因为这需要和其他模块正在进行中的变更合并,解决冲突,重新发布整个应用,运行所有测试,才能重新发布上线。单体应用架构已经不能满足软件研发效率的要求,被以微服务为主要特征的互联网分布式架构取代。采用微服务架构后,应用程序由独立的服务组成。这些服务是松耦合的,通过 API 调用、事件触发或者数据流的方式交互。每个服务都完成一个特定的功能,独立开发、运行和发布。


微服务解决了单体架构的研发效率瓶颈,但是对应用的基础设施提出了非常高的要求。


例如,为了确保独立开发的微服务能够按预期协调配合,需要进行详尽的集成和端对端测试。测试环境中的应用部署次数通常是生产环境的 10 倍。如果应用基础设施不能快速提供独立的测试环境,那么大量的测试时间将消耗在环境稳定性问题的解决上。


根据阿里巴巴集团的研发统计数据,1 人日的研发,通常对应 5-7 人日的测试。测试环境已经成为阿里巴巴集团研发提效的最大痛点。


微服务的松耦合,也对数据库使用、状态管理、问题诊断、应用交付流水线带来了很大的挑战。关于微服务的复杂度以及解决方案,业界已经有非常多的讨论,这里不再赘述。


以微服务为核心的互联网分布式架构,实施的复杂度较高,必须有很好的工具、平台的支撑,这是业界的共识。



除了微服务架构,企业也广泛使用反应式架构、事件驱动架构等模式,这些架构都带来了松耦合、敏捷开发等好处,但相应的落地复杂度也变高了。


事实上,业界在应用的构建、编排、运行、BaaS 服务、基础设施管理等每一方面,都提供了丰富的产品和解决方案,建立了庞大的生态。但企业要整合这些软件/服务,让它们弹性、稳定、相互集成良好,加速应用开发迭代,这绝非易事。


而在用好云的阶段,云的使命就是要消除这种复杂度,带来大规模复杂软件开发质的突破,助力企业打破技术鸿沟。


每一个 Serverless 服务都是厂商领域能力的输出,通过服务 API 透出功能,承诺可靠性、弹性、性能等能力指标,因此他们是高质量的应用构建块(building blocks)。


例如阿里云对象存储(OSS)服务,承载着 EB 级的海量数据,承诺 11 个 9 的数据可靠性,99.95% 的可用性,以及多样化的数据分级存储和处理能力。


阿里云消息队列 RocketMQ 历经双十一万亿级消息洪峰的锤炼,承诺 10 个 9 的数据可靠性,99.95% 的可用性。这些云服务和企业基于开源软件自建的系统相比,在弹性、可靠性等方面有明显的优势。



不只是云厂商,大量的开源商业产品也采用了 Serverless 模式,包括 Confluent Cloud、MongoDB Atlas、Snowflake、Databricks 等。


随着厂商在存储、计算、中间件、大数据等领域推出越来越多的 Serverless 服务,并且这些服务通过事件驱动等方式紧密集成,云逐渐变成了应用构建和运行的超级平台,应用的研发模式也升级为组装式研发。


让云成为应用构建最佳平台

随着阿里云提供越来越全面的 Serverless 产品以后,很多云产品都变成模块化、API 化、服务化,它可以进行组装,通过拖拉拽的方式就能够构建应用。


在 Serverless 架构下,研发方式升级为组装式研发,可以做到流程编排、事件驱动,甚至可以做成可视化,这就彻底颠覆了原有的软件研发方式,大幅提升研发效率,灵活应对业务挑战。根据权威机构调研统计,组装式研发相比传统模式,可为研发提效 50% 以上。


从新兴的互联网创业公司,到传统企业构建大型软件,都可以使用 Serverless 架构和组装式研发。


以高德为例,高德的投放业务和用户生活场景紧密相关,功能多变;推荐的下游业务品类快速增长,投放的业务策略多变;而且整个业务和用户出行紧密相关,有明显的峰谷属性。


随着业务的增长,投放平台原有的架构面临一些明显的痛点:


  1. 重客户端。卡片处理、导航规划、页面展示等逻辑都放在 Web 或者移动设备上,导致客户端发版缓慢、代码臃肿。

  2. 业务功能紧耦合,跟不上业务迭代要求。投放策略多变,每次发布影响面大。

  3. 负载有明显的峰谷,常驻实例,资源利用率低。


Serverless 架构能很好地解决上述痛点。首先为客户端瘦身,将端上的逻辑大量的移到 BFF 层(Backends for frontend)。


由于 Serverless 计算零运维,只需要开发业务逻辑,完全由客户端人员发布,避免了团队协作问题。借助平台内置的应用平滑发布的能力,客户端的人员可以快速迭代,安心发布。



投放策略等后端服务也解耦为函数的形式,包括规则过滤函数、疲劳提醒函数、内容组装函数等等。这些函数作为独立的后端服务开发迭代,每次发布影响面不大,控制了爆炸半径。


通过仔细梳理热点逻辑以及上下游依赖,实现了全链路弹性以及接口级流控能力。弹性伸缩不但快速,而且安全,资源用量和负载峰谷匹配,效率高。


目前基于 Serverless 架构的高德业务投放平台已经承载了 100% 的生产流量,业务规模达到百万 QPS,功能交付从原来的数天降低到数小时,整体成本降低了 38%。

Serverless 奇点已来

云计算的探索者认为,云计算的下一个十年默认的计算范式就是 Serverless 。


2021 年 DataDog 发布 Serverless 研究报告,数据表明,从云原生初创公司到大型企业都在关注 Serverless,Serverless 生态已经超越了 FaaS,包含数十种服务,可以帮助开发人员构建更快、更动态的应用程序。


从 2012 年提出 Serverless 到今年 2022 年刚好十年,Serverless 已经成为今天 IT 开发的主流,也是云服务器商提供能力的主流。


我们相信,Serverless 奇点己来,所谓奇点,是由平稳发展转向高速发展的转折点,预示着行业落地将开始全面爆发。而我们也将成为见证这个变化的一代技术人。

用户头像

All in Serverless 2018-09-12 加入

更多内容关注 Serverless 微信公众号(ID:serverlessdevs),汇集 Serverless 技术最全内容,定期举办 Serverless 活动、直播,用户最佳实践。

评论

发布
暂无评论
Serverless 奇点已来,下一个十年将驶向何方?_Serverless Devs_InfoQ写作社区