【QCon】精华内容上线85%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

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

  • 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 更全面的信息资讯。


公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2022-12-03 13:276602

评论 3 条评论

发布
用户头像
了解一下

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

2022-12-06 18:26 · 山西
回复
如果真的,大数据平台将迎来新的机遇……
2022-12-07 07:31 · 上海
回复
还要等主流云厂商全部跟进这个趋势,基础设施就成熟了
2022-12-21 14:11 · 北京
回复
没有更多了
发现更多内容

Java日志的心路历程

程序猿阿星

Java log4j logback log4j2框架 Java日志

从一面就被拒到收割字节offer,我花了一年时间,功夫不负有心人

Java架构师迁哥

拼多多电商部java岗三面落选,记下的面试题,不睡觉都要背下来!

Java 程序员 架构 面试

博云容器云 3.2 发布:核心能力再提升,易用性再升级

BoCloud博云

容器

新手小白必须知道的Linux基础:常用命令(1)

学神来啦

Linux linux命令 linux运维 linux 文件权限控制 Linux教程

【案例】构建应急指挥体系,实现生产过程实时监控

星环科技

2021年阿里/腾讯/美团/字节1万道Java中高级面试题汇总,新鲜出炉

Java架构师迁哥

联邦学习这件小事

趣链科技

区块链 联邦学习 技术架构

奉劝各位准备面试的Java程序员耗子尾汁,赶紧扔掉网上那些千篇一律的面试题

Java架构之路

Java 程序员 架构 面试 编程语言

贝特瑞新能源汽车的速度与激情

亚马逊云科技 (Amazon Web Services)

前后端分离浅析以及分离教程

北游学Java

前后

华为云IoT设备接入服务全体验

华为云开发者联盟

物联网 IoT 华为云 智能IoT边缘服务 华为云IoT云服务

什么是交叉编译

IT蜗壳-Tango

IT蜗壳教学 6月日更

Fabric架构演变之路

趣链科技

区块链 fabric 联盟链架构 演变

迎战大厂!“金九银十”和秋招通过率达95%的Java面试要点集锦

Java 程序员 架构 面试

难忘阿里,4面技术5面HR附加笔试面,走的真艰难真心酸

Java 编程 程序员 面试 架构师

毕业5年的同学突然告诉我,他已经是年薪50W的Java架构师了

Java架构师迁哥

三位一体:打造软硬服一体化的区块链平台

趣链科技

区块链 联盟链 Baas 一体机 底层平台

大专学历成功拿下阿里offer,分享面经及我的Java面试复习资料

Java架构之路

Java 程序员 架构 面试 编程语言

Polkadot“升级”之道

趣链科技

区块链 区块链技术 polkadot

勒索病毒卷土重来?看亚马逊云科技如何保护你的网络安全!

亚马逊云科技 (Amazon Web Services)

一文回顾 Java 入门知识(中)

逆锋起笔

Java 后端 JAVA开发 java基础 javase

小树量化机器人系统开发(马丁策略)

薇電13242772558

区块链 数字货币

移动端iOS组件化

Geen练

ios CocoaPods 组件化 iOS Developer 路由

将DataX执行结果通过钉钉上报

白粥

DataX

【融云技术】超大规模并发下自定义属性的设置与分发

融云 RongCloud

【星环案例】我们用TDH+Sophon把工厂“搬”进高校实验室,推进产学研一体化

星环科技

Java“圣经”学累了?那就看看这些通俗易懂的内容吧

Java架构师迁哥

GitHub火到糊!这份阿里内部10W字Java面试总结,让你薪资翻倍

Java架构追梦

Java 架构 面试 跳槽

一周信创舆情观察(5.24~5.30)

统小信uos

有道精品课全链路测试的改进和思考

有道技术团队

测试 有道精品课

有些代码可以少写,它们未必会是你的未来_AI&大模型_王一鹏_InfoQ精选文章