2月5-7日QCon全球软件开发大会携手100+位大咖讲师落定北京,点击查看完整日程>> 了解详情
写点什么

有些代码可以少写,它们未必会是你的未来

  • 2022-12-03
    北京
  • 本文字数:4877 字

    阅读完需:约 16 分钟

有些代码可以少写,它们未必会是你的未来

11 月 16 日,亚马逊副总裁兼 CTO Werner Vogels 发布了一篇名为《分布式计算宣言》的文章,为人们揭示 24 年前的亚马逊研发团队,是如何在业务发展、架构迭代面对巨大阻力时,思考引入 SOA 架构和分布式思想,完成自我“革命”的。读罢令人感叹,每一个开发者都希望获得成就感,去做一些真正有创造力的工作,做一些 24 年后仍然令 CTO 引以为豪,并转述给百万开发者的工作,而不是把时间和精力消耗在写千篇一律又无法复用的“胶水”代码,或是在越来越复杂软件栈面前,疲于奔命地写业务流程并尽量减少 Bug。


更加不堪的是,有时仅仅是因为同一项目的两个成员使用的库版本不同,我们就不得不消耗大量的精力去解决冲突。当然,那些成功的团队和开发者往往也处理过同样的问题,但这种成就感的到来未免门槛过高。


不过,在太平洋时间 12 月 1 日的 re:Invent 大会上,Werner 展示了另一种可能 —— 一名开发者可以把精力放在更有价值的工作,而不必重复低效的劳动,在一系列 Serverless 工具的帮助下,一些代码可以少写,因为未来你可能再也不需要写它们了。如果我们抛开它们作为商业软件的盈利属性来看,这恐怕是自云原生理念普及以来,最能利好开发者的产品发布。

自动化创建状态机和工作流,并彻底干掉“胶水”代码


对有限状态机最简单的理解是“if……else……”,但代入到负责研发场景里时,要实现有限状态机可不那么简单。


英国卫报是世界最大的英文媒体之一,在全球拥有几十万订阅用户,每周至少要为 60000 名用户准时送达订阅信息。不管支撑英国卫报的软件系统是如何构建的,可以确定的是,这里一度存在相当多的技术问题 —— 卫报的高级开发经理 Paul Brown 曾在采访中提到,卫报主数据库系统和所有第三方系统之间的数据流编排非常困难,且系统之间相互依赖,一个系统出问题就会产生连锁反应。如何编排所有分布式系统,保证报纸的正确、及时交付,变成了一个棘手问题。


马修国际旗下的一家子公司 SGK 遇到的则是另一个技术问题——他们要为甲方交付 ETL 管道,但是需要每天至少刷新两次输出数据,因此要跨多个数据库进行数据管理和复制;其交付数据的业务规则在不断更新;需要集成来自 10 多个不同数据源的输入数据。每个数据源大概有 1–20K 行,85 列。如何搭建 ETL 管道,又变成了一个棘手问题。


这两种问题有一个共性,单纯用状态机做一个订阅流程或是 ETL 或许不难,但放在具体场景中则要考虑太多因素,且要承担系统维护的责任。Amazon Step Functions 最初诞生时,就是为了解决类似的问题,通过可视化拖动云服务的方式,构建事件驱动的工作流 —— 你当然可以选择从头 coding,但也可以拖一拖搞定这个事。



为流式数据构建数据处理管道


这听起来很性感,但实际能支撑的并发工作复杂有限,一次有效的最大并发数仅为 40,另外仅接受 JSON 数组作为输入源,整体还是比较受限的。本次re:Invent发布的 AmazonStepFunctionsDistributedMap 重点搞定了并发问题,从 40 提升到 10000,让 Step Functions 真正变得通用。下图为新老 Distributed Map 的一些关键数据对比:



表格作者:Sébastien Stormacq


在 Keynote 中,Werner Vogels 多次以“异步”、“事件驱动”等关键词来描述 Amazon Step Functions Distributed Map 的设计理念,但对于开发者来说,可能更吸引的人是,如果你已经会写 ETL ,那就可以少做一些重复工作,多去考虑一些能给业务、技术架构带来增量的研发工作。


除了烦人的业务流程外,另一个降低研发效率的工作是写“胶水”代码。所谓“胶水”代码,就是指互不兼容的模块间(接口不同、语言不同等),需要写一些代码做连接才能正常工作。这类代码对业务没有任何价值,纯粹是软件工程的副产品。


相信 Werner Vogels 和亚马逊云科技是看到了对这一问题的反馈,所以才发布了 Amazon EventBridge Pipes 这一产品 —— 它是 Amazon EventBridge 的一项新功能,提供针对生产者、消费者的点对点流程,自动完成模块集成,不需要编写“胶水”代码。



这个点对点流程的创建,需要重点考虑事件源、事件目标两个主要问题。


事件源发布时,Amazon EventBridge Pipes 支持以下服务作为事件源:Amazon DynamoDB、Amazon Kinesis、Amazon MSK 、Apache Kafka、Amazon SQS(标准和 FIFO)和 Amazon MQ(均用于 ActiveMQ 和 RabbitMQ)等。


事件目标则包括:AWS Lambda、Amazon API Gateway、Amazon SNS、Amazon SQS 和 AWS Step Functions 等。


尽管现在在行业内的应用情况有待检验,但 Amazon Step Functions Distributed Map 和 Amazon EventBridge Pipes 实际传达了一种趋势:类似的服务在未来几年可能会越来越多,越来越成熟,告别低价值代码这件事是绝对靠谱的,云原生时代开发者的技术栈需要做相应的调整。


如果在未来,我们可以不用处理经常见到的业务流程或 ETL 流程,也不用写“胶水”代码,那将有大量的时间可以来思考业务、架构及流程本身的合理性。


避免更糟糕的时间浪费


如本文开头所提,比起写一段 ETL 代码,或是写一段模块集成代码,更糟糕的是,将时间消耗在协作问题而非技术问题上。


这年头各企业的业务压力永远越来越大,需求能三天上线就不会拖到一周,大部分时间里可能不会有工程设计这个概念,中间遇到的各种协作问题只能是“在起飞的过程中换轮胎”。


所以当 Werner Vogels 在本次 re:Invent 上发布 Amazon CodeCatalyst 时,台下的掌声十分热烈。


Amazon CodeCatalyst 的功能包括:


  • 项目资源蓝图——不仅是新项目的脚手架,还包括支持软件交付和部署所需的资源

  • 统一开发环境,保持项目组环境一致

  • 管理 issue、pr、部署跟踪等

  • CI/CD

  • 显示项目仪表板

  • 通过一封电子邮件即可邀请他人就项目进行协作

  • 统一搜索,跨用户、问题、代码和其他项目资源检索内容


这里的资源蓝图包括启动代码、示例代码和云服务相关配置的最佳实践,其他几项也都是软件研发项目管理的必需品。另外一大特色在于 CodeCatalyst 本身集成的第三方工具是高度灵活的,是不是要用 GitHub 和 Jira,完全和团队的习惯有关。Werner Vogels 说,可视化是亚马逊云科技提供服务的一大特点,而大部分开发者应该也认为可视化是个让人十分心安的标签。



Serverless 是所有构想的核心


回过头看,无论是 Amazon Step Functions Distributed Map 还是 Amazon EventBridge Pipes, 其核心始终是 Serverless,是 Lambda 这一产品本身。


Lambda 在 2014 年的发布,虽然展示了亚马逊云科技对 Serverless 愿景理念的深度洞察,但不可否认的是,当时的 Serverless 技术仍存在问题。直到本次 re:Invent,Serverless 的冷启动速度得到大幅优化,大数据核心产品全面 Serverless 化完成,才宣告 Serverless 技术发展的又一里程碑到来,云产品全面 Serverless 化只余时间问题。


而 Serverless 从技术、产品两个方面的成熟,也直接为以上发布铺平了道路。试想如果这些产品不是围绕 Serverless 技术来进行设计的,那么所有构想都将成为灾难 —— 没人能够忍受自动化创建业务流程的同时,还要关心服务器的配置问题。


这不只是在说 Serverless 技术好不好用,也是在说创新的门槛到底是高是低 —— 如果你有了一个创意,Serverless 是最简洁的实现和验证手段,降低 Serverless 的使用门槛,就是在降低企业内的创新门槛。而亚马逊是一家尤其关注创新的企业,因此,Application Composer 应运而生。


Application Composer 的特点,在于可以帮助生成部署就绪的项目,例如 IaC 定义文件和 Lambda 函数代码脚手架。


在传统开发工作里,配置 Serverless 服务需要理解 IaC (基础设施即代码)的概念,并写一些机器可读的定义文件。这个概念作进一步延展,就变成了“基础设施可编程”,听起来是比较吓人的。


Application Composer 无疑大大降低了开发者内心对 Serverless 技术的畏惧程度,某种程度上也就是加速了企业的创新速度 —— 当然,这也需要企业充分理解云理念,并对云原生相关技术有相对成熟的运用经验。


3D 世界的构建正成为主流


在 Keynote 的末尾,抬头看路,Werner Vogels 给出一个大胆判断:未来 3D 会像视频一样普及。


去年,亚马逊发布具有 3A 游戏开发能力的开源游戏引擎 Open 3D Engine(O3DE)。O3DE 的核心特色是高度灵活的模块化功能,适合做 3A 级网游,完全免费,支持到位、更新简单。保证模块化功能的核心是带有源码和资源的 Gems 系统,不需要的功能可以完全不编译,极大提升了灵活性。


因此在发布后,O3DE 立即引起了热议。


究其根本,O3DE 其实是亚马逊的 Lumberyard 的继承者,Lumberyard 引擎是 2016 年亚马逊与德国著名引擎技术开发商 Crytek 达成的一项交易,彼时深陷财务危机的 Crytek 以具体数字不详(传闻为 5000 万 -7500 万美元)的价格向亚马逊完整授权了 CryEngine 的所有代码,而 Lumberyard 便是 CryEngine 经过修改的免费版本。


到去年年底,开放 3D 基金会 (O3DF) 宣布推出 O3DE 的第一个稳定版本,这是一个 Apache2.0 许可的多平台 3D 引擎,可让开发人员构建 AAA 级游戏、用于视频制作的电影级 3D 世界,以及不受许可费或商业条款影响的非游戏使用案例模拟。


而本次 re:Invent 上的最后一个发布,也与 3D 有关 —— Amazon SimSpace Weaver。Amazon SimSpace Weaver 是一种全新的完全托管仿真服务,可帮助用户在云中部署大规模空间模拟。借助 SimSpace Weaver,用户可以创建具有数百万个对象的无缝虚拟世界,这些对象可以实时相互交互,而无需管理后端基础设施。


结合去年发布的 Amazon IoT TwinMaker 来看,当下的 3D 技术脱胎于游戏,但已不止于游戏,以 SimSpace Weaver 为例,数百万个对象,已经对以智慧城市为典型的行业应用产生实际助推作用。


对智慧城市的建设仍然只是未来畅想的第一步,计算的未来在于对物理世界的极致模拟。当下的“绿色科技”,对于全世界都是一个挑战,那么应该如何最高效地应用技术手段达成“碳中和”?量子计算或许是关键一环。Werner 以八年前他在夏威夷和 Terraformation 公司的讨论作为案例来解释这一问题。


大规模种植林木是实现“碳中和”的直接手段,但如何高效经济地种植出一座森林,则是个复杂问题。模拟仿真,可以让我们这座森林未来的状态、规模、效用以及内部生态系统的变化有更明确的认知,但整体计算量将是恐怖的,量子计算机比经典计算机更适合这种仿真需求。


如果将问题迁移到生命科学、材料科学,全面深入分子结构,计算量将以指数级增长,可能会迅速超过行业的算力储备,量子计算机的优势会变得更加明显。这也是为什么量子计算能成为当今学术研究的主流 —— 我们可以通过量子计算机彻底迭代计算能力和模拟能力,而不是通过算法研究做有限的迭代和逼近。


Werner 在演讲的最后以量子计算为核心,展望了将物理世界数字化的可能与前景。他提及亚马逊云科技量子计算中心学者、世界知名的量子信息科学先驱人物 John Preskill 在 Youtube 已有许多优质视频发布,阐述了利用量子计算来解决行业难题的思路和方法,并热情地推荐大家也去了解了解。


这样看来,尽管量子计算如今仍处于研究的早期阶段,但应用思路已经具备,前景是明朗的。从研发基础设施到 3D 仿真 ,再到量子计算,形成了一条清晰明朗的未来科技演进之路。


这是本次 re:Invent 带给我们的另一重惊喜。

与开发者一起构建未来


亚马逊云科技 Heroes 项目是社区最重要的组成部分之一,该项目表彰了全球充满活力的亚马逊云科技专家群体,他们对知识分享的热情在社区中产生了真正的影响。



亚马逊云科技的 Heroes 能够以各种方式分享知识,包括通过社交媒体、博客文章、开源项目、视频和论坛进行在线分享,或亲自参加会议、研讨会和用户组活动。


在此次 re:Invent 2022 大会中,Heroes 的身影无处不在。Werner Vogels 博士也在 Keynote 演讲中提到:“对于开发者而言,除了可以在亚马逊云科技为了帮助开发者成长提供的 500+ 精心打造的课程中进行学习外,向你身边的技术专家请教也会是一个很好的方式。”


亚马逊云科技今年也重大发布了中国开发者官网,提供一站式平台,帮助开发者学习成长及交流并链接全球技术资源,助力开发者使用亚马逊云科技获得成功,与开发者一起构建未来。


在亚马逊云科技开发者社区官网,我们发布了关于本次 re:Invent 更全面的信息资讯。


2022-12-03 13:274789

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论 3 条评论

发布
用户头像
了解一下

TO 引以为豪,并转述给百万开发者的工作,而不是把时间和精力消耗在写千篇一律又无法复用的“胶水”代码,或

2022-12-06 18:26 · 山西
回复
如果真的,大数据平台将迎来新的机遇……
2022-12-07 07:31 · 上海
回复
还要等主流云厂商全部跟进这个趋势,基础设施就成熟了
2022-12-21 14:11 · 北京
回复
没有更多了
发现更多内容
有些代码可以少写,它们未必会是你的未来_AI_王一鹏_InfoQ精选文章