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

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 说，可视化是亚马逊云科技提供服务的一大特点，而大部分开发者应该也认为可视化是个让人十分心安的标签。

回过头看，无论是 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 技术的畏惧程度，某种程度上也就是加速了企业的创新速度 —— 当然，这也需要企业充分理解云理念，并对云原生相关技术有相对成熟的运用经验。

在 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 更全面的信息资讯，扫描上方二维码或点击【阅读原文】即可访问。