架构师-极客传媒（2023年2月）

CONTENTS/

目录热点

|Hot每个月在云上“狂烧”180万，Ruby

On

Rails之父：我们要直接买硬件！用自研Pingora替代Nginx后，Cloudflare成为了最受欢迎Web服务器44.7

GB！遭前雇员“叛变”，俄版百度Yandex几乎所有源代码泄露为降低“遗留技术成本”，Capital

One裁掉了整个敏捷部门，可能涉及1100人GraalVM

Java编译器将于2023年加入，与OpenJDK的发布节奏和流程保持一致React

18：新玩具、新陷阱以及新可能性访谈文章

|Interview指导了上百万程序员，《代码大全》之父和你聊聊软件开发素养｜独家探访“编程圣经”背后故事DevOps缺少定义，平台工程需要指导性路线图案例研究

|CaseStudy我用Rust改写了自己的C++项目：这两个语言都很折磨人！从ClickHouse到StarRocks，易点天下数仓平台建设漫谈钉钉单元化推荐文章

|Article一个科技新时代开启，硅谷五巨头将何去何从为什么谷歌和苹果都要杀死移动Web？资深工程师揭秘大厂从吹捧到扼杀“内幕”Cloud

IDE是不是一个伪命题2023中国技术成熟度评估曲线发布，六大发展趋势将影响软件研发行业特别专题｜

ChatGPT内幕故事全球爆红的ChatGPT是如何诞生的？（上）全球爆红的ChatGPT是如何诞生的？（中）全球爆红的ChatGPT是如何诞生的？（下）架构师2023

年

02

月刊本期主编

蔡芳芳流程编辑

丁晓昀发行人

霍泰稳反馈

feedback@商务合作

hezuo@内容合作

editors@卷首语卷首语作者：蔡芳芳最近在朋友圈和技术新闻里频频看到ChatGPT的身影，自11月30日发布之后，关于它的报道几乎从未断过。如今的ChatGPT和AIGC，有点像一年前的Web3，科技圈无人不知无人不晓。从绘画、写作到编程，延展至职业咨询、情感咨询，ChatGPT在应对超百万使用者的花式提问中展现出了相当令人惊艳的强大能力。比如InfoQ最新这篇报道，在近期一项研究中，ChatGPT尝试查找示例代码中的bug并给出修复建议，整体表现优于现有同类程序，成功修复了40个bug中的31个。面对编程能力越来越强大的AI，不少人再次忧心忡忡：“AI会取代程序员吗？”更有相当激进的声音认为，在人工智能驱动的未来，“编写程序的传统想法即将消失”。人们常常倾向于高估短期变化，而低估长期变化。我们并不认为短期内ChatGPT会完全取代程序员，但长期来看，它确有可能颠覆一部分简单的编程工作。从2017年前端智能化兴起，到2021年GitHub

Copilot火爆，再到现在的ChatGPT，AI毫无疑问正在改变编程工作流，这已经不是会不会的问题，而是改变的程度到底会有多大的问题。未来程序员们势必需要学习如何在工作中跟AI“协作”、如何基于AI更好更高效地完成自己的工作，所以程序现在最要紧的是让自己做好准备迎接可能到来的软件开发新范式，而不是焦虑恐慌或嗤之以鼻。除了可能革新编程工作流，ChatGPT又会对科技行业格局带来什么样的影响？这也是近期科技创投圈的热议话题。不久前在一篇文章中看到一个挺有意思的观点，作者认为：OpenAI会颠覆亚马逊云在内的计算平台。可ChatGPT（以及OpenAI的其他产品）本2InfoQ架构师2023年02月身跑在微软的Azure云平台上，怎么理解“OpenAI会颠覆亚马逊云在内的计算平台”呢？该文章作者认为，这取决于未来10-20年人们是否还会主要基于亚马逊云平台构建软件，他更倾向于会出现一个新的“智能平台层”。业内还有另一个相对普遍的观点认为，微软（云服务）的未来会取决于OpenAI。国外知名科技圈投资机构a16z在1月19日发布的文章《Who

Owns

the

GenerativeAIPlatform?》中表示，基础架构供应商（其实就是云厂商）可能是AIGC市场迄今为止的最大赢家，据他们猜测当下AIGC市场总收入的10-20%流向了云提供商。恰恰最近微软也宣布将把ChatGPT加入Azure云服务，未来云计算市场格局会如何变化？或许我们可以有更加大胆的想象。3热点

|

Hot每个月在云上“狂烧”180万，RubyOnRails之父：我们要直接买硬件！作者

褚杏娟

核子可乐2022年10月，运营项目管理平台Basecamp背后的37Signals公司首席技术官兼RubyOn

Rails之父David

Heinemeier

Hansson发文表示将要“下云”。近日，37Signals官博发文总结了自己在2022年的云支出情况。这是一个得令人瞩目的云账单，该公司2022年在云上的支出费用大约为320.15万美元（约合人民币2170万元），即每月26.67万美元（约合180万元人民币）。其中大部分支出（75.99万美元）花在了AmazonWeb

Services的EC2和EKS服务。4InfoQ架构师2023年02月“恐怖“的云账单现在的37Signals主要经营两款产品：Basecamp和HEY，这也是他们的核心产品，对应的客户规模和收入水平也是最高的。另外，他们还运行着不少遗留服务，包括Basecamp

Classic、Basecamp

2、Highrise、Backpack、Campfire、Writeboard，甚至是Ta-da

List。这些服务已经不再继续出售，但仍有几万甚至几十万用户在用，利润贡献在数百万美元上下。对此，37Signals表示“打算永久提供支持，直到互联网不复存在。”上述的不少应用程序并非运行在云端。以规模最大的应用程序Basecamp为例，它的最新版本和之前的Basecamp

2几乎都运行在37Signals的自有服务器上，对应应用本体、数据库和缓存服务器。在这些服务上，只有搜索（OpenSearch）、文件存储（S3）和CDN服务（CloudFront）由云端提供。HEY则基本完全依赖于云服务（除了某些电子邮件和图像处理服务，这部分由其自有硬件支持）。在HEY当中，37Signals通过AWS

EKS在Kubernetes集群上运行完整的Rails应用程序，借助Aurora

RDS建立MySQL数据库服务器，在Elasticache上运行Redis，还通过OpenSearch实现搜索服务。另外，37Signals的其他遗留应用程序也都运行在EKS上，数据库用的则是RDS。“2022年全年，我们的所有云服务总开销为3,201,564美元，每月是266,797美元。吓不吓人！”37SignalsSRE工程师FernandoÁlvarez在博文里说道。下面，我们看下37Signals的详细开销：•

单看HEY，纯用于生产工作负载的全年开销为106.6万美元（合每月8.88万美元）。这一项服务的成本来源可参考下图：5热点

|

Hot•

至于其他各独立服务，37Signals

2022全年为所有应用程序数据库在RDS上花费了约47.3万美元（合每月3.9万美元）。这还不包括最新的Basecamp和较早的Basecamp

2版本，它们用的自有硬件。所以其中大部分还是来自HEY，全年数据库支出为35.59万美元（合每月2.96万美元），其余部分就是支持其他遗留服务的开销了。•

至于OpenSearch，37Signals主要用来托管应用程序搜索集群和日志记录管道中的索

引

存

储

，

全

年

共

花

掉

51.99

万

美

元

（

合

每

月

4.33

万

美

元

）

。

Basecamp

和Basecamp

2也在使用这项云服务，所以其中大部分成本就来自这两者，外加HEY和BasecampClassic。•

亚马逊云科技的Kubernetes服务EC2和EKS，在2022年内共花掉75.99万美元（合每月6.33美元）。其中大部分用作HEY的生产和登台环境，总计27.23万美元（合每月2.26万美元），其余的用于其他遗留应用程序。但同样地，Basecamp和Basecamp2不在其中。•

37Signals在Elasticache身上花掉了12.38万美元（合每月1.03万美元）。其中最大占比再次来自HEY，它要借助这项服务来获取Redis支持的缓存。•

最后，37Signals在S3上存储了约8

PB的文件，2022年内总开销高达90.78万美元（合每月7.56万美元）。Hansson透露，这是单笔花费最贵的项目。值得注意的是，37Signals使用了双区域副本策略来避免AWS整个区域及其中各可用区的突发6InfoQ架构师2023年02月故障。为了交付这些文件和其他静态资产，其2022年在CloudFront

CDN服务身上花掉了66742美元（合每月5562美元）。实际上，37Signals为了将巨额支出削减至320万美元，做出大量努力。运营团队开展一项审慎的成本核查计划，每月上报并跟踪。公司还通过预留实例和长期使用承诺等方式签订了长期协议，借此享受更低的定价优惠。“但即便如此，我们在2022年内还是花掉了如此恐怖的云服务支出！”新的”省钱计划”：购买硬件在新的一年，37Signals表示，计划把大量服务和依赖项从云端转移到内部硬件上，借此大幅削减这笔费用。但这个公司并不打算亲自运营数据中心，而是与Deft合作租赁其机架空间、带宽、供电和托管服务。“虽然按我们的业务规模计算，这样的支出同样不低，但已经远优于公有云上的花费。”Álvarez说道。虽然还没有详细的账单出来，但Hansson在推特上将这一成本与购买戴尔包含288个vCPU的服务器所需的支出进行了对比：第一组，R6525有256GB内存、3TB

NVM、2x10G网络、2倍AMD

EPYC

7513。第二组除了是2x

AMD

EPYC

7443之外，其他都相同。所以288

vCPU、15

TB

NVM、1.3TB

RAM，3年每个月只要1287美元！7热点

|

Hot37signals表示，新方案并不会给带来太多额外的运营负担，他们不需要在数据中心架设和部署硬件或者线缆。所有设备都可以从戴尔那边直接订购，发往Deft数据中心，等到服务器显示在线后即可直接使用。可以看出，37signals在“下云”上表现出了非常大的决心。正如Hansson当时所说，云计算在两种极端情况下大有裨益：其一是应用程序极其简单且流量很低的情况，这时选择完全托管服务能摆脱大部分复杂性要素；其二是负载波动几乎毫无规律可言、大家不知道该部署多少服务器的情况，这时上云是最好的选择。但如今37signals已经不适用于上述两种情况。“Basecamp多年的商业模式跟自有硬件都能良好协同，业务的增长轨迹也有很好的可预测性。”8InfoQ架构师2023年02月事实上，虽然近年来云计算加速增长，但企业并没有放弃本地数据中心，很多企业继续依赖传统数据中心来处理其关键任务工作负载。根据Uptime

Institute

2022年的研究，只有36%的组织会将关键任务工作负载放入公共云中。虽然这一比例高于2019年的26%，但企业越来越担心公共云服务的可见性和弹性。2022年，超过四分之一

(26%)

的公司表示，出于此类担忧，他们不会将关键任务工作负载放到公有云上，这一比例高于2019年的22%。企业在延长硬件的使用周期那么，企业总是想要最新、最好的技术来为其数据中心提供动力吗？

实际上并不是。根据Uptime

Institute的研究，硬件更新周期在普遍延长而非缩短。在其2020年数据中心调查中，最常见的更新间隔时间为五年，而2015年时为三年。这表明在相对较短的时间内就发生了重大转变。根据Uptime的说法，五年或更长时间的硬件生命周期正在成为常态。是什么推动了这种延长效应？Uptime

Institute表示，数据中心硬件的电源使用效率(PUE)

的下降削弱了更频繁更新服务器的主要动力。平均PUE从2007年的2.5暴跌至2014年的1.67，但此后改善停滞不前，当前平均PUA为1.55。9热点

|

Hot注：PUE

=

数据中心总能耗/IT设备能耗，其中数据中心总能耗包括IT设备能耗和制冷、配电等系统的能耗，其值大于1，越接近1表明非IT设备耗能越少，即能效水平越好。随着效率提高的放缓，企业对昂贵的硬件进行更换的经济动机也在放缓。摩尔定律带来的回报越来越少。“正是这种每瓦特性能的翻倍，为增加计算能力同时通过硬件更新提高效率提供了重要机会。但在过去五年中，英特尔（以及直接竞争对手AMD）要保持改进的步伐变得更加困难。这就提出了一个问题：我们是否还能从最近几代和即将到来的几代中央处理器中看到这些改进？否则，硬件更新的理由将被削弱。”UptimeInstitute2020数据中心报告PUE是更新周期延长的因素之一，还有一些其他的因素：•

硬件即服务：供应商越来越喜欢将他们的硬件产品捆绑在订阅模式中。某种程度上，他们正在响应客户的需求。但当技术格局变化如此之快时，谁愿意锁定所有的资本支出呢？•

提高硬件利用率：超大规模（hyperscalers）已经证明商品硬件足以运行工业级工10InfoQ架构师2023年02月作负载。关键在于应用正确的软件层来充分利用可用硬件。中型和企业CIO密切关注着这些发展。•

预算限制：新IT设备的商业用途总是受到审查，毫无疑问，疫情的发生将优先事项进行了重新排列。随着远程工作成为常态，各种规模的企业都重新审视了对专有硬件的需求。针对云优先工作负载的服务和咨询支出也越来越多。当然，硬件供应商仍然希望缩短硬件升级周期。以戴尔为例，该公司在2019年委托Forrester发布的一份报告中警告说，不及时升级设备会带来机会成本。“老化的基础设施和进展有限的SDDC（软件定义的数据中心）使用，阻碍了IT组织满足业务需求。”但硬件使用者正在主动延长使用周期。比如微软目前在其庞大的数据中心产品组合中运营着400万台服务器（并且还在增加）。微软首席财务官Amy

Hood最近宣布该公司将其服务器的使用寿命延长至六年，而在此之前的更新周期为四年。Hood表示，通过对软件的投资、服务器和网络设备运营效率的提高以及技术进步，微软能够将其服务器的使用寿命再延长两年。因此，该公司估计2023财年第一季度可节省11亿美元，整个财政年度总计可节省37亿美元。另外，为实现其循环经济实践的承诺，从现在到2030年，微软的目标是将其数据中心的电子垃圾通过维修管理、回收再利用等方式降低90%。这种维修和再利用的趋势不仅会进一步延长硬件更新的时间范围，还将支持二手数据中心设备市场的扩张。结束语在企业不断追求“降本增效”，而云成本不断上升的情况下，“下云”采用传统硬件设备成为一些企业的选择。但真要下云的话，企业需要考虑是否像37Signals一样业务可预测、没有意外的流量涌入，同时也要算好自己的账，比如要更换的设备价值多少，如何收回部分投资以抵消升级的前期成本，哪些设备可以在内部重新部署、哪些可以退役等。世界上没有完美的解决方案，企业还是要做好评估后，根据自身业务需要进行选择。11热点

|

Hot参考链接/our-cloud-spend-in-2022//news/data-center-hardware-refresh-cycles/12InfoQ架构师2023年02月用自研Pingora替代Nginx后，Cloudflare成为了最受欢迎Web服务器作者

Tina1月27日消息，据Netcraft对上百万个站点的调查数据显示，在2023年1月，Cloud-flare从第3位跃升至第1位，即在一个月内超过了Apache和Nginx，成为了最受欢迎Web服务器。Cloudflare市场份额这个月增长了0.56个百分点，目前为21.64%，其次是Apache，为21.40%，以及Nginx，为21.20%。Cloudflare成立于2009年，是美国的一家网站安全和托管服务提供商。2011年，黑客组织LulzSec使用Cloudflare来保护自己的网站不被他人攻击，并在Twitter上赞扬了Cloudflare的产品，此举让Cloudflare受到大量媒体关注。2019年，Cloudflare成功IPO，当日收盘上涨20%。13热点

|

HotCloudflare的核心可以说是Nginx，但在2022年9月，Cloudflare宣布用新的内部HTTP代理Pingora取代了Nginx。Pingora是Cloudflare工程师用Rust编写的全新HTTP代理系统，专为Cloudflare用例及业务规模设计。Cloudflare

CTO

John

Graham-Cumming曾阐述Nginx对Cloudflare的重要性：“Cloud-flare将Nginx用于其提供的所有Web服务，并在世界各地的数千台机器上使用它作为反向代理服务器。”但随着Cloudflare的发展壮大，Nginx已经无法满足他们的现实业务需求。“虽然Nginx多年来一直表现良好，但时间推移之下，Nginx的种种局限性已经严重影响到我们的业务运营。虽然先后优化或缓解了部分限制，但仍有一部分问题始终得不到完美解决。”所以，Cloudflare舍弃了Nginx的worker（进程）架构，自研了Pingora。据介绍，Pingora每天处理超过1万亿条请求，提高系统性能之余，也为Cloudflrae客户带来不少新功能。更重要的是，它运行所占用的CPU和内存资源只相当于原有代理基础设施的三分之一。14InfoQ架构师2023年02月44.7GB！遭前雇员“叛变”，俄版百度Yandex几乎所有源代码泄露作者

刘燕1月28日，据外媒报道，俄罗斯最大的IT科技公司之一Yandex发生了源代码泄露事故。Yandex几乎所有源代码泄露据称，一名前雇员泄露了Yandex的源代码存储库，其中泄露了Yandex在其搜索算法中使用的1,922个排名因素。目前，被泄露的Yandex源代码存储库已在一个流行的黑客论坛上以BT种子的形式泄露。15热点

|

Hot1月26日，泄密者发布了一个磁力链接，声称这是““Yandex

git

sources”，其中包含2022年7月从公司窃取的44.7

GB文件。据称，这些代码存储库包含公司除反垃圾邮件规则之外的所有源代码。软件工程师Arseniy

Shestakov分析了泄露的Yandex

Git存储库，并表示其中包含有关以下产品的技术数据和代码：•

Yandex

searchengineandindexingbot•

Yandex

Maps•

Alice(AIassistant)•

Yandex

Taxi•

Yandex

Direct(adsservice)•

Yandex

Mail•

Yandex

Disk(cloudstorage

service)•

Yandex

Market•

Yandex

Travel

(travel

bookingplatform)•

Yandex360(workspacesservice)•

Yandex

Cloud•

Yandex

Pay

(payment

processingservice)•

Yandex

Metrika

(internet

analytics)Shestakov还在GitHub上分享了泄露文件的目录列表，供那些想查看哪些源代码被盗的人使用。“至少有一些API密钥，但它们可能仅用于测试部署，”Shestakov谈到泄露的数据时说。Yandex否认黑客入侵，将源代码泄露归咎于前员工在给Bleeping

Computer的一份声明中，Yandex表示他们的系统没有被黑客入侵，一名前雇员泄露了源代码存储库。“Yandex没有被黑。我们的安全服务从公共领域的内部存储库中发现了代码片段，但内容与Yandex服务中使用的存储库的当前版本不同。存储库是用于存储和使用代码的工具。大多数公司在内部通过这种方式使用代码。代码仓库的作用是处理代码，而非存储个人用户数据。我们正在对向公众发布源代16InfoQ架构师2023年02月码片段的原因进行内部调查，但我们没有发现对用户数据或平台性能有任何威胁。”-Yandex。增加黑客暴露风险Yandex前高级系统管理员、开发副主管兼传播技术总监Grigory

Bakunov向Bleep-ingComputer评论此次泄密事件表示，他对泄露的代码非常熟悉，他曾在2002年至2019年期间在这家科技巨头工作。Bakunov认为，数据泄露的动机是政治性的，导致数据泄露的“流氓”Yandex员工并未试图将代码出售给竞争对手。这位前高管补充说，泄露不包含任何客户数据，因此不会对Yandex用户的隐私或安全构成直接风险，也不会直接威胁和泄露专有技术。“Yandex使用名为‘Arcadia’的单一存储结构，但并非公司的所有服务都使用它。此外，即使只是构建服务，也需要大量内部工具和专业知识，因为标准构建程序并不适用。泄露的存储库仅包含代码；另一个重要部分是数据。神经网络的模型权重等关键部分都没有，所以几乎没有用。尽管如此，仍有许多‘有趣’的文件，其名称如“blacklist.txt”可能会暴露正在运行的服务。”不过Bakunov也提醒，泄露的代码使黑客有可能识别安全漏洞并实施有针对性的漏洞利用活动。现在，这只是时间问题。这位前高管还评论了Yandex的声明，称泄露的代码可能与公司工作服务中使用的当前代码不相同，但相似度可能高达90%。因此，对泄露代码开展全面检查后，恶意黑客很可能会从Yandex系统中发现可供利用的缺口。17热点

|

Hot为降低“遗留技术成本”，CapitalOne裁掉了整个敏捷部门，可能涉及1100人作者

Tina核子可乐敏捷交付（ADL）已经过时了？今天，据《福布斯》报道，Capital

One正在裁撤敏捷交付团队，涉及到1,100多名技术员工，以寻求降低“遗留技术成本”。Capital

One是一家专注于信用卡、汽车贷款以及银行和储蓄产品的美国公司，是以专注于技术而闻名的金融企业，也是第一家全面采用云技术的美国银行。裁员举措是在多年来投入巨资发展其云系统之后做出的，该公司在一封电子邮件中将这一努力描述为对Capital

One的“技术转型”至关重要。受裁员影响的员工将被要求18InfoQ架构师2023年02月申请公开的内部职位，全公司有数百个空缺职位，而那些无法找到新职位的员工，公司将给他们提供至少16周的遣散费。Capital

One希望工程师和产品经理能自己负责“敏捷交付”职责，“我们技术组织中的敏捷角色对我们早期的转型阶段至关重要，但随着我们组织的成熟，下一步自然是将敏捷交付流程直接集成到我们的核心工程实践中，”CapitalOne说。随后，该消息在Linkedin、Reddit以及上得到了证实，自述被裁员的人中，其职位描述包括：“Certified

SAFe

Scrum

Master”、“Capital

One首席助理、敏捷交付负责人（ScrumMaster）”、“ScrumMaster(ADL)”、“Scrum大师、发布培训工程师、产品经理”有人评论道：“我被裁了。我其实是一名项目经理，负责一些产品和技术工作。除了在头衔中有‘敏捷’这个词之外，我实际上并没有做任何跟敏捷相关的事情。公司瞎了眼，自从一年前来到CapitalOne，我就忙得喘不过气来。”“对，是真的。我是受影响的ADL之一。他们正在消除整个敏捷工作系列，包括ADL、敏捷项目负责人、敏捷投资组合负责人、PO等。”还有说：“确认，我是ADL之一。我们做了很多幕后工作，但这些工作的价值不容易被看到。ADL并不是Capital

One里最重要的职务，但团队肯定会受到严重影响，无论是在日常层面，还是在组织/公司层面。”19热点

|

Hot当然也包含一些对敏捷有偏见的评论：“不幸的是，ADL已经过时了。”……负责“赋能”的敏捷团队Capital

One是敏捷和SAFe的早期采用者。从2010年初开始，Capital

One投入巨资推动组织内的敏捷实践。经过多年发展，Capital

One的敏捷团队已经相当成熟，曾以其优异的敏捷实践而闻名于整个行业。“2010年左右，我们意识到公司当时还没找到适合未来需求的正确模式。我们发现，传统的瀑布式方法无法适应未来业务需求。所以我们需要建立敏捷的工作方式，吸纳更多现场工程人才，借员工之手实现工作交付。于是我们全面转向更敏捷的交付方式。2011年底，我们开始采用Scrum、试行敏捷，同时为需要参与敏捷Scrum的团队招聘新成员。我们的试点主要侧重于数字功能，之后快速将敏捷扩展至整个技术部门。我们发现，敏捷其实是一种跨技术门类的工作方式，有着广泛的适用性。总体来看，敏捷是种通用的工作形式，能够不断迭代、根据市场需求或客户需求检查当前进展，最终构建并更新出足以占领市场的强大产品。”2016年，Capital

One的CIO

Rob

Alexander在接受《福布斯》采访时说道。据早期的报道，Capital

One在2011年的时候，敏捷开发只占交付软件的百分之一。2014年左右，85%的软件是通过敏捷方法交付的，并借助敏捷每月发布大约400个产品版本，将交付时间缩短到三到六个月，“显著地降低了成本”。Capital

One不仅在整个组织中利用了SAFe，还进行了一些特定的定制。在Capital

One技术组织内，每个敏捷团队由5或6名软件工程师、一名产品负责人（也称为PO）、一名ADL（敏捷交付负责人，或广为人知的ScrumMaster）和一名团队负责人组成。虽然工程师只专注于特定团队，但PO和ADL角色同时支持多个团队的情况并不少见。其中，敏捷管理需要负责“建立领导力，包括培训、绩效管理、薪酬决策等”，“负责团队的交付”、“与其他敏捷角色协作以消除障碍”、“人员配备”、“负责平台/应用程序健康”、“建立信任、协作和心理安全的文化”。在CapitalOne招聘网页上，是这样描述AgileDeliveryLead的职责的：20InfoQ架构师2023年02月•

与倡议领导和团队合作，拆分工作内容并确定事务优先级，积极管理团队并保持对最高优先级事务的关注。•

针对需求收集与管理、积压工作细化和优先级排序等工作，为计划/项目负责人、责任主管和团队提供指导。•

使用Jira建立工作流程与管理实践，并利用Confluence推动工作流程、知识共享和协作的可见性。•

负责流程和倡议的变革管理与沟通计划。•

指导并敦促团队定义交付目标与关键结果，并据此衡量绩效。•

组织交付会议，主动管理依赖关系/障碍并上报风险。•

通过制定交付指标和准确报告，实现交付目标、承诺和进度的可见性。•

妥善管理和负责必要的运营流程，并通过适当的控制和风险缓解策略确保运营流程的高质量持续交付。•

利用团队反馈与指标（质量、交付率等）确定机会空间，并与团队协同以持续改进。•

通过影响力、问题解决和创新等手段，积极改进跨EDRM（电子发现请求）的敏捷交付实践。•

能够向团队成员和利益相关方解释并倡导敏捷和精益实践的助益。据称，Capital

One总共有50,000人，其中包括10,000多名工程师，这次裁员没有涉及到任何“软件工程师”职位。CapitalOne的技术转型从2010年到2020年，Capital

One发生了几个重要的变化：采用敏捷实践、迁移到公有云、构建DevOps实践。Rob

Alexander当时表示：“继敏捷转型之后，我们的下个阶段就是DevOps转型。这项理念的核心，就是如何打造一个生产力更高、绩效更强的组织。我们认为，转向DevOps是我们建立软件自动化构建流程，由此将软件开发、推送、测试、部署和安全保护等各个环节的执行效率全面推向顶点的关键。而其中最重要的组成部分，当然就是自动化交付管道。”21热点

|

HotDevOps这种新文化也改变了开发者对于代码质量、代码交付，特别是在生产环境下大规模可靠运行的基本态度。“高效环境不仅有助于提高生产力和质量，同时也能改善员工满意度。我们正身处这段旅程，而且作为技术领导团队，我们需要跟整个组织开展沟通——由此实现的，就是卓越软件交付。我们坚信这是一种强大的工作方式，对企业客户大有裨益，最终推动服务和被服务双方发展成高价值、高效能组织。这也再次证明了我们按照科技巨头规划自身运营的思路是正确的——要想在银行业领域胜出，我们就必须遵循这样的行事之道。”在IT转型过程中，除了快速增加软件工程人员之外，Capital

One意识到“要提高生产力，还得认真规划基础设施的交付方式。因此我们决定迁移至公有云。”亚马逊云科技（AWS）是Capital

One的主要云合作伙伴，随后他们开始在云端构建所有新软件，也开始将应用程序从内部数据中心迁移至云上。2021年，Capital

One宣布关闭了自己的数据中心。根据资料显示，在交付上，Capital

One也已经过渡到使用自动化交付工具上。比如采用Jenkins，这是用于构建持续集成和交付管道的行业标准工具。基于Jenkins的管道帮助将整个过程分解为“应用程序构建”、“集成测试”和“部署”等阶段，每次代码更新都经过一系列严格的自动化测试，包括集成测试、单元测试、安全扫描和质量检查。一旦代码通过所有测试，管道就会自动部署一个版本。22InfoQ架构师2023年02月某云服务所提供的敏捷工具而且，目前主流DevOps平台其功能已经发展得相当强大，可作为一个自助化的研发管理平台，实现缺陷管理、业务需求管理、软件需求管理、需求跟踪、代码分析、应用架构管理、代码统计等等。一般云服务所提供的DevOps平台，还包含了敏捷工具规划和跟踪工作部分，并配备图表、仪表板和报表来帮助团队监视和共享进度。Capital

One敏捷团队的职责中，关于“负责平台/应用程序健康”等就可以被工具所取代，在DevOps文化中被归属到开发人员身上，由开发人员自行负责，但是文化构建、领导力等也许依然是无法替代的。参考链接/business/us-credit-card-giant-capital-one-cuts-more-than-1100-tech-jobs/t/1kKf9jXi/t/1kLSSHrI/news/story/capital-one-to-cut-1100-tech-jobs-6130482//r/nova/comments/10g15mh/capital_one_layoffs_agile_divi-sion_1100_employees//channels/capital-one-delivers-85--of-software-through-agile/d/d-id/1296926.html/resources/experience-reports/the-evolution-of-people-man-agement-in-agile-organizations//capital-one-closes-its-data-centres-and-goes-all-aws23热点

|

Hot/sites/peterhigh/2016/12/12/how-capital-one-became-a-leading-dig-ital-bank/blog/capital-one-devops-case-study/24InfoQ架构师2023年02月GraalVMJava编译器将于2023年加入，与OpenJDK的发布节奏和流程保持一致作者

Karsten

Silz

译者

张卫滨作为GraalVM

22.3版本的一部分，甲骨文详细阐述了将两个GraalVM项目转移至OpenJDK的计划。在2023年的某个时间点，社区版本的即时（Just-in-time，JIT）编译器（“Graal编译器”）和用于原生操作系统可执行文件（“原生镜像”）的提前（Ahead-of-Time，AOT）编译器的代码将会转移至一个新的OpenJDK项目。现有版本、GraalVM企业版功能和其他GraalVM项目将保留在GraalVM中。甲骨文最初在2022年10月份的JavaOne上宣布了这一举措，但是没有提供具体的细节。在2022年12月中旬，OpenJDK提议新建Galahad项目来实现这次转移。GraalVM项目是Oracle

Labs的一部分，因此不在OpenJDK的管理之下。GraalVM目前25热点

|

Hot每年有四个特性版本，遵循与OpenJDK不同的发布过程。在OpenJDK，GraalVM

Java编译器会与Java的发布节奏保持一致，即每年两个特性更新版本和四个补丁更新版本，每两年一个长期支持版本（Long-Term

Support，LTS）。GraalVM

OpenJDK项目将使用OpenJDK社区流程，并提交JDK增强提议（JDK

EnhancementProposal，JEP），以便于将其纳入OpenJDKJava版本中。Graal编译器是使用Java编写的，并在Java运行时环境（Java

Runtime

Environment，JRE）中使用Hotspot

VM。它取代了使用C++编写的C2

JIT编译器，大多数Java发行版中都包含该编译器。GraalVM原生镜像AOT编译器会生成原生可执行文件，通常来讲，与运行在JRE中，使用JIT编译器的Java应用相比，它们启动更快，使用的CPU和内存更少并且占用的磁盘空间也更小。这使得Java在云中更具竞争力。GraalVM原生镜像通过删除未使用的代码并预先计算应用的堆快照实现了这些优化，在幕后它会使用Graal编译器。但是，这也将一些Java应用排除在GraalVM原生镜像的使用范围之外。InfoQ最近发表了关于该话题的系列文章。企业版提供了原生镜像性能的改进，比如用于运行时剖析的Profile-Guided优化，但是它不会转移到OpenJDK中。其他的GraalVM项目也不会进行转移，包括对其他语言（如JavaScript或Python）的支持和Java

onTruffle（对整个HotspotVM的Java替代方案）。GraalVM社区版本基于GNU通用公开许可证（GNU

General

Public

License）第二版，该协议具有类路径例外（Classpath

Exception）条款。许多OpenJDK发行版，包括甲骨文的OpenJDK构建版，都使用同样的许可证。而甲骨文的Java发行版使用的是“甲骨文免费条款和条件（Oracle

No-Fee

Terms

and

Conditions）”许可证。甲骨文宣布，“从许可证的角度来看，所有的GraalVM技术都与Java一致[]"，并承诺“在未来几个月内提供更多的细节”。GraalVM

22.3发布，支持JDK19并改善了可观测性GraalVM

22.3是2022年最后一个特性发布版本。它对JDK

19提供了实验性的支持，包括来自Loom项目的虚拟线程和结构化并发。对JDK

19的完整支持会在2023年1月底的26InfoQ架构师2023年02月GraalVM23.0中提供。该版本包含了原生可执行文件监控方面的大量改进，这是一个落后于在JRE中运行Java程序的领域。JDK工具jvmstat现在可以监控原生可执行文件的性能和资源使用，并收集堆转储，以便于使用VisualVM进行探查。原生可执行文件还可以为免费的JavaFlight

Recorder

（

JFR

）

工

具

记

录

JavaMonitorEnter、

JavaMonitorWait和ThreadSleep事件。GraalVM原生镜像编译器需要所谓的hint，以获取Java代码中对反射的使用。与Spring和Micronaut框架协作，GraalVM在2022年7月推出了一个面向Java库hint的公共仓库。这个名为“GraalVM

Reachability

Metadata”的仓库现在已经包含了针对Hibernate、Jetty、JAXB和Thymeleaf的条目。GraalVM原生镜像AOT编译器在选定的基准测试上要快2到3倍。原生可执行文件运行时需要更少的内存，运行整数的最小/最大操作的操作要更快。在22.2中添加了两个实验性的优化，StripMineCountedLoops和EarlyGVN，它们现在已经稳定并默认启用。原生可执行文件现在可以包含软件物料清单（SoftwareBillofMaterial，SBOM），并且通过更好地识别内存使用和内存泄露，调试体验得到了改善。在GraalVM生态系统的新闻中，当前IntelliJ

2022.3版本提供了调试原生可执行文件的实验性支持，JUnit5.9.1也提供了注解包含或排除它们。GraalVM中的Python实现改名为GraalPy。它在兼容性和性能方面有很多改善，就像Ruby的实现TruffleRuby一样。GraalVM中的Python和其他语言得益于Windows上LLVM运行时的实验性可用性。该GraalVM版本通过一行shell脚本为macOS和Windows提供了新的下载方案：bash

<(curl

-sL

/jdk)Leyden项目通过Condenser优化JavaLeyden项目是OpenJDK的一项倡议，其使命是“改善Java程序的启动时间、达到性能峰值的时间和占用空间”。甲骨文澄清了GraalVM与该项目的关系：它“计划在OpenJDK27热点

|

Hot社区中发展原生镜像技术，以跟踪Leyden项目的规范”。Leyden项目最初的目标是在Java语言规范中增加原生可执行文件，比如GraalVM原生镜像AOT编译器产生的可执行文件。在2020年6月正式创建后，该项目在两年内没有任何公开活动。在2022年5月，Leyden项目再次出现并带来了第二个目标：对于在带有JIT编译器的JRE上运行的Java应用，为它们识别和实现广泛的优化。它之所以这样做，是因为GraalVM

AOT编译器有一个强制的封闭性假设，也就是在构建时必须具有应用的所有信息，比如它的类和资源。有些Java应用和库使用了Java中的动态特性，这些特性在该限制下无法正常运行。第二个目标的一些优化需要对Java语言规范进行一些修改。它的实现将依赖于现有的工具，比如HotspotVM和jlink工具。2022年10月，Leyden项目详细介绍了如何实现这两个目标。它引入了在编译时和运行时之间运行的condenser的概念。它能够“将程序转变为一个新的、更快的、可能更小的程序，同时保留原程序的含义”。Java语言规范将进行改进，以包含condenser。Condenser将会定义AOT编译和原生可执行文件如何适应Java，以实现Leyen项目最初的目标。但是condenser还会改善在带有JIT编译器的JRE中运行的Java应用，以服务于第二个目标。GraalVMJava编译器、JRE和HotSpotJIT编译器将继续获得独立于Leyden项目的特性和升级。所以，condenser提供了一个额外的优化层。截止2022年12月份，condenser的开发尚未开始。这使得Leyden不太可能在2023年9月份发布的下一个Java

LTS版本中交付condenser。所以，有Leyden项目成果的最早的JavaLTS版本可能是2025年9月的Java

25。Java社区对甲骨文转移GraalVM的反应Spring

Boot刚刚在2022年11月发布了3.0版本，Spring

Boot加入了在生产环境中支持GraalVM原生镜像AOT编译的Java框架大家庭，其他框架还包括Quarkus、Micronaut和Hel-idon。InfoQ就甲骨文的公告采访了这四个框架的代表。第一个回应来自Red

Hat

Java团队的卓越工程师Andrew

Dinn，以及Red

Hat的首席软件工程师Dan

Heidinga。2022年5月他们在InfoQ发表过文章，主张OpenJDK和GraalVM之间要更加紧密地结合。28InfoQ架构师2023年02月InfoQ：你们在2022年5月份的文章中提到，“原生Java需要纳入到OpenJDK中，以实现与其他正在进行中的功能增强的共同演进”。从这个角度来讲，你们是如何看待甲骨文的声明的？Andrew

Dinn

&

Dan

Heidinga：我们对甲骨文的声明和Leyden项目最近的进展都持非常乐观的态度。将GraalVM的关键部分，即JIT编译器和原生镜像，纳入OpenJDK项目，有助于将它们的开发和用户社区更好地结合在一起。在OpenJDK项目下，采用共同的开发模型以及现有的OpenJDK管理方式，能够让GraalVM开发人员与更广泛的OpenJDK社区进行更好的沟通和协作。而且，这能够让这些组件更容易地影响其他Java项目的设计，如Valhalla或Amber，使它们更适应AOT编译。最后，它将GraalVM直接纳入Java规范流程的管理之下，并确保Java和GraalVM在相同的方向上共同发展。InfoQ：甲骨文还宣布，GraalVM原生镜像AOT编译器将会实现OpenJDK中Leyden项目的规范。Leyden最近推迟了原生Java的标准化，而选择了优化JIT编译。鉴于新的进展，你们如何看待这个决策？Dinn

&

Heidinga：Leyden项目最近提出了针对Mark

Reinhold关于如何解决这个问题的设想。他建议使用Condenser，将计算从应用的一个阶段转移至另外一个阶段。同时，他还提出了支持该方式所需的规范变更（为了提供一个稳定的基础，这是必要的任务）和Java语言的变更，比如惰性静态JEP草案。这些都没有提及“延迟AOT”或“优化JIT”。这种方式使AOT和JIT，甚至通常的执行方式，都会得到优化。他的样例使用的是一个XML库，在运行时读取配置文件。这种转移计算的方式对AOT和JIT都有益。正如我们在像Quarkus这样的框架中看到的，在构建时初始化状态对快速启动至关重要。Leyden现在正在奠定基础，在保留程序含义的基础上进行预初始化，这是我和An-drew在文章中提出的关键需求之一。这不仅仅是确保GraalVM与Java规范之间紧密且可靠地协作的问题。Mark的提案明29热点

|

Hot确指出，Leyden项目如果需要的话，也需要谨慎而连贯地更新规范，以允许特定Condensation步骤的行为变化。例如，它甚至提到当面向完全封闭的AOT程序时，需要明确类加载器行为的语义。将GraalVM纳入OpenJDK也会使来自这两个项目的代码混合和匹配更容易。也许，GraalVM的原生镜像AOT编译器会成为程序转换流水线中的最后condenser。InfoQ：你们的文章中描述了在原生Java中无法使用的Java特性。对可观测性至关重要的Java

Agent的支持是另一个缺失的特性。对于这些限制，GraalVM应该怎么做呢？Dinn

&Heidinga：GraalVM团队可能在未来一年左右的时间内忙于将他们的代码迁移至OpenJDK。项目的迁移往往会比预期地更长，即便他们提前有所预期也在所难免。我们看到GraalVM社区正在致力于增加可用于原生镜像的工具，包括Red

Hat为支持JFR和JMX所做的努力，以及在调试支持方面的工作，包括Red

Hat和IntelliJ的努力，所有这些都是与甲骨文的开发人员一起进行的。GraalVM处在一个很好的位置，可以继续演进并与现有的代理供应商合作，为原生镜像寻找合适的插装（instrumentation）

API。在这个过程中，学到的所有内容都能直接用于Leyden，并加速Leyden的交付。这就是现在的终极目标：将所有的经验和学习到的东西（希望还会有些代码）输入到Leyden的开发过程中，以帮助该项目交付所需的规范更新、语言变更和condenser工具，以推进整个框架、库和应用的广泛采用。Sébastien

Deleuze是来自VMware的Spring框架提交者，分享了Spring生态系统的观点。InfoQ：你们如何看待Java的GraalVMJIT和AOT编译器转移至OpenJDK这一事件的？Sébastien

Deleuze：从将Spring应用编译成原生可执行文件开始，我们就与GraalVM团队进行了非常紧密的合作。我们的目标是限制“原生Java”和“JVM上的Java”之间的差异，同时保持AOT方式所带来的效率收益。所以，从我们的角度来看，GraalVM

JIT和AOT编译器转移到OpenJDK是个好消息，因为这是在OpenJDK的旗帜下实现更统一的Java的关键一步，即便在原生Java和JVM之间还存在一些差异。30InfoQ架构师2023年02月我们也到了这样一个节点，那就是越来越多的问题或优化需要OpenJDK代码库进行一些变更。所以，希望GraalVM在OpenJDK方面能够获得一些帮助，包括与Leyden项目更紧密的合作。一直以来，GraalVM都是一个包含多个子项目的伞状项目，比如多语言（polyglot）技术，有着不同的成熟度和不同的适用场景。将转移到OpenJDK内容与其他内容区分开来，有助于更加专注于GraalVM原生镜像的支持，并明确GraalVM对终端用户的意义。InfoQ：目前，GraalVM的Java编译器每年有四个特性版本，未来将有两个。这对Spring有什么影响吗？Deleuze：的确，在我们试验Spring

Native项目的时候，每年四个特性版本对于快速推进工作是相当有用的。但是，2022年11月底我们发布了Spring

Boot

3，从此开始了对GraalVM原生的正式和生产级别的支持。因此，从这个角度看，GraalVM的特性发布节奏变慢并与OpenJDK的发布保持同步，将有助于一致地处理这些升级，减少出现频繁破坏性变更的风险，并且能够让我们有更多的时间从事长远的新特性。不要忘了，可以预测的是每年还会有四个季度性的关键补丁更新，以修补原生镜像支持方面的问题。InfoQ：GraalVM

Java编译器的开发将会有所不同，至少会有一个OpenJDK项目，另外还涉及提交者、审校者和JEP，这对Spring会有什么影响吗？Deleuze：尽管流程会有所变化，但我们希望能够继续保持Spring与OpenJDK方面GraalVM团队的合作。同时，正如之前宣布的，我们与BellSoft（OpenJDK的主要贡献者之一）在JDK和原生支持方面保持着密切合作。在未来的几个月内，我们会分享关于该影响的更多细节。Red

Hat的卓越工程师和主管JasonGreene代表Quarkus框架做出了回应。InfoQ：你们如何看待Java的GraalVMJIT和AOT编译器转移至OpenJDK这一事件的？Jason

Greene：我们认为这对GraalVM和OpenJDK社区都是一个积极的变化。这两个项目更紧密地联系在一起，将会增加双方的合作和代码共享，包括推进Leyden项目31热点

|

Hot的工作。我们与这两个团队都有良好的关系，并期待着在新的结构中继续保持这种关系。InfoQ：目前，GraalVM的Java编译器每年有四个特性版本，未来将有两个。这对Quarkus有什么影响吗？Greene：这种变化可能意味着需要等待更长的时间才能在GraalVM的正式版本中出现原生镜像相关的新特性。但是，GraalVM也有一个扩展性的SPI，我们目前在Quarkus中使用了他。它与Quarkus本身相关的改善相结合，能够在频繁的Quarkus发布计划中改进QuarkusGraalVM原生镜像的体验。InfoQ：GraalVM

Java编译器的开发将会有所不同，至少会有一个OpenJDK项目，另外还涉及提交者、审校者和JEP，这对Quarkus会有什么影响吗？Greene：我们预计这些变化对Quarkus社区的影响很小。即使OpenJDK的流程和工具有一些差异，但它们与当前的模式有着相似的目标。虽然GraalVM没有使用JEP，但是它们有关于issue相关的设计讨论，并且具有包含代码审查的PR过程。甲骨文的架构师GraemeRocher提供了来自Micronaut框架的观点。InfoQ：你们如何看待Java的GraalVMJIT和AOT编译器转移至OpenJDK这一事件的？GraemeRocher：对于社区和GraalVM的广泛采用来讲，这是非常好的一个举措。InfoQ：目前，GraalVM的Java编译器每年有四个特性版本，未来将有两个。这对Mi-cronaut有什么影响吗？Rocher：在GraalVM的早期采用阶段，每季度一次的发布节奏很有帮助。现在GraalVM已经很成熟和稳定了，所以在这个阶段，转为每年发布两个版本已经没有什么问题了，这更像是一件好事。Micronaut团队和GraalVM团队都在Oracle

Labs工作，并将继续合作，确保每次发布的开发者构建和快照版本都经过良好的测试。InfoQ：GraalVM

Java编译器的开发将会有所不同，至少会有一个OpenJDK项目，另32InfoQ架构师2023年02月外还涉及提交者、审校者和JEP，这对Micronaut会有什么影响吗？Rocher：毫无疑问，这会努力使AOT的众多API和注解实现标准化，随着这些新API的出现，我们会转而使用它们。然而，这对Micronaut来说并不是一个新的挑战，因为它已经与GraalVM同步发展，并在它们出现时适配了这些改进。甲骨文的架构师Tomas

Langer代表Helidon框架做出了回应。InfoQ：你们如何看待Java的GraalVMJIT和AOT编译器转移至OpenJDK这一事件的？Tomas

Langer：JIT编译器会对运行时提供帮助，对Helidon的源代码和开发过程没有影响。对OpenJDK的任何性能改进都是非常棒的！AOT编译会影响我们设计（和测试软件的方法）。如果原生镜像成为OpenJDK的一部分，那么与AOT相关工作的复杂性都会降低，我们只需要安装一个JDK即可。对于我们的客户来讲也是如此。InfoQ：目前，GraalVM的Java编译器每年有四个特性版本，未来将有两个。这对Helidon有什么影响吗？Langer：随着GraalVM原生镜像变得越来越成熟，我们应该不会看到像过去那样的重大变化。减少发布版本实际上会使我们更加轻松，因为我们应该比以往更容易支持最新的版本，实际上，我们正在跳过对GraalVM一些发布版本的支持，因为大量的测试和相关工作使我们难以保持对最新版本的支持。InfoQ：GraalVM

Java编译器的开发将会有所不同，至少会有一个OpenJDK项目，另外还涉及提交者、审校者和JEP，这对Helidon会有什么影响吗？Langer：我想答案和前面的很相似，GralVM原生镜像越成熟，我们应该越容易使用它。目前，GraalVM计划在2023年发布四个特性版本。至少第一个版本仍将包含GraalVM的Java编译器，因为GraalVM原生镜像将在2023年1月24日发布的23.0版本中获得对Java19的完整支持。现在，还不清楚GraalVM的Java编译器何时会在GraalVM中进行最后一次发布，何时会在OpenJDK中进行第一次发布。33热点

|

Hot作者简介Karsten

Silz在欧洲和美国作为全栈Java开发者（Spring

Boot、Angular、Flutter）工作了23年。2004年，他在美国共同创办了一家软件产品创业公司。Karsten领导了13年的产品开发，在公司成功出售后离任。自2003年以来，他也曾作为承包商工作。2020年，他作为首席技术官在英国共同创立了SaaS初创公司“Your

HomeinGoodHands”。原文链接GraalVMJava

CompilersJoinOpenJDKin2023,AlignwithOpenJDKReleasesandProcesses34InfoQ架构师2023年02月React18：新玩具、新陷阱以及新可能性作者

PrithwishNath

译者

马可薇图源LautaroAndreani@Unsplash35热点

|

Hot坦白地说，我最近也没怎么用过React，只用过Vanilla

React（我在另一篇文章里总结过版本13的复杂性），以及Astro

+

Preact的组合工具。别误会，React依旧很赞，但多数情况下，你大概会觉得React可行性在很大程度上会取决于你愿意投入多少时间学习它的怪癖，以及你愿意写多少代码来对抗黑客。但React

18（在我写这篇文章时是18.2.0）为弥补这一差距迈出了巨大一步，提供了许多开箱即用的新功能，如并发渲染、过渡（Transitions）和悬停（Suspense），以及一些锦上添花的变化。那么代价是什么呢？更多“神奇”的抽象。并不是所有人都吃这一套，但就结果而言，我们或许可以考虑在下一个项目中跳过“功能齐全”框架，并用React

18取而代之，让react-query成为我们数据获取或缓存的解决方案。那究竟是什么说服了我呢？容我慢慢道来。并发渲染突击问答：JavaScript是单线程的吗？JavaScript本身是单线程的，初始代码不会等DOM树完成立刻执行，但其他基于浏览器Web接口的，如Ajax请求、渲染、事件触发等却不是单线程。React的开发者或许已经对这种独立地从不同组件中获取数据并遭遇竞赛条件的情况驾轻就熟了。36InfoQ架构师2023年02月要想应对这种情况，我们需要求助并发。并发让React具备并行性，且有能力在响应性方面与本地设备UI相匹配。怎么做到这一点？要回答这个问题，让我们先看看React幕后的工作原理。React的核心设计是维护一个虚拟或影子DOM，渲染DOM树的副本，其中每一个独立的节点都代表一个React元素。在对UI做更新后，React都会递归更新两个树之间的差异，并将累计的变更传递到渲染通道。在React

16中引入了一套新算法来完成这段流程，也就是React

Fiber，取代了原先基于堆栈的算法。所有React元素或者说是组件都是一个Fiber，每个Fiber的子和兄弟都可以延迟渲染，React通过对这些Fiber的延迟渲染实现数量级更高、效果更好的UI响应。具体观感对比可见这里。React17以此为基础构建，而React

18则为这套流程带来了更多可控性。React

18所做的是在所有子树被评估之前暂停DOM树之后的差异化渲染传递。最终结果？每个渲染通道现在都可以中断。React可以有选择地在后台更新部分UI，暂停、恢复或者放弃正在进行的渲染过程，同时保证UI不会崩溃，不会掉帧，或帧数时间一致（如，60FPS的UI应该需要16.67毫秒来渲染每一帧）。随着React18加入ReactNative，移动设备的游戏规则将彻底改变。React

18功能背后的核心概念是并发渲染，其中包括悬念、流式HTML、过渡API，等等。每次这些新功能都是并发式的，用户不用具体了解其背后的机制原理。悬停悬停（Suspense）最早出现在React

16.6.0中，但也只能用于动态导入React.lazy，如：const

CustomButton

=

React.lazy(()

=>

import(‘./components/CustomButton’));在React

18中，悬停有了新的扩展，应用也更加普遍。你是否有遇到过组件树还没有完成数据获取，什么都显示不出来的情况？在能够给出真正的数据之前，指定一个默认的、非阻塞的加载状态展示给用户。37热点

|

Hot<Suspense

fallback={<Spinner

/>}><Comments

/></Suspense>这样能够提升用户体验的方式的原因有：1.

用户不用等待所有数据获取完毕后才能看到东西；2.

用户会看到一个加载按钮，动态骨架，或者仅仅是一个<p>加载中</p>之类的即时反馈，告诉用户程序正在运行，应用程序并没有崩溃；3.

用户不用等待所有交互元素或组件完成水合（hydration），就能开始交互。<Comments>还没加载完？没问题，用户完全可以先点点看<LatestArticles>、<Navbar>，或者<Post>里的数据。与此同时，开发者体验也得到了改善。在构建应用程序或是在使用Next.js和Hydrogen类似的元框架时，开发者们可以参考React新定义的，规范的“加载状态”。另外，如果你已经知道要怎么在Vanilla

JavaScript中写try-catch模块，那你应该如何使用悬停边界。1.

悬停<Suspense>会捕捉“悬停状态”的组件，而不是错误。比如在数据、代码缺失之类的情况中，给出“嘿我还没准备好所有东西”的信息。2.