架构师（2022年11月） -新一波 JavaScript Web 框架

热点|HotDevOps已死，平台工程才是未来上云“被坑”十年终放弃，寒冬里第一轮“下云潮”要来了？那位用Rust重写数据库的创始人来复盘了：删除27万行C++代码，值吗？理论派|Theory字节大规模微服务语言发展之路去哪儿网ServiceMesh落地实践：100%容器化打底，业务友好是接入关键推荐文章|Article新一波JavaScriptWeb框架字节跳动开源BitSail：重构数据集成引擎，走向云原生化、实时化观点|Opinion当“增加人员”不足以解决问题，你就该考虑应用“微前端”了2022年11月刊angcomgorgekbangcom卷卷首语2专访“MySQL之父”：要拥有一份能做一辈子的开发工作，需要给自己积累名望MySQLMonty生的关键词。60岁的Monty现在仍在写代码，每周保持60个小时的高工作强度。他说，等到80岁二十年磨一剑InfoQ：您在34岁时开发出了MySQL。从接触编程到开发出MySQL，这段时间可真不Monty：我从18岁的时候就开始编写MySQL的最早一批代码了，这部分代码主要是Monty：我想，是热爱。我喜欢做开发，我特别喜欢解决问题的感觉，特别是在开InfoQInfoQ架构师2022年11月3发MySQL和MariaDB的过程中。而且，我参与了开源，帮助很多人走向成功。我觉得这InfoQ：从您写下第一行代码到开发出MySQL，花费了近二十年时间。但目前市场上也有不少企业投入过十年甚至十五年来开发软件，但最终成果从来没能真正流行起来。Monty：我确实是用了快二十年才开发出MySQL，但当时我没有想到未来这个软件，很多公司耗时耗力，最终却一无所获。MySQL的成功是与时代背景分不开的。当时互联网已经得到广泛认可，每个人都需要这样的数据库，其实只要意识到需求的存在，其他的就都好办了，所以我从94年开始正式编写MySQL。最终成果的发布大概是在95年末，也就是说，我们用了短短两年就开发出了LMonty：嗯，我在企业家、开源倡导者、程序员和架构师几个角色上表现得都还可InfoQ赋是不是比努Monty：那是肯定的。毕竟在编程行业，一个优秀的程序员要胜过十个普通的程序卷卷首语4InfoQ：从MySQL到MariaDB，您已经证明了自己是位成功的企业家。但不是所有技y但我觉得他们的天赋主要还是体现在开发上，最好能坚持下去，依靠自己的才能走Monty：我认为不应该这样。因为好程序员，特别是优秀的程序员其实更难找。虽LCEOCTO我把一生都投入到写代码上，我喜欢这活儿，也正是编程让我成为了独一无二的人。InfoQ资源，比如晋升机会更大、薪酬更Monty：我觉得很多企业在职业设计上都有这种错误。所以在MySQL和MariaDB，我觉得与其靠让大家做管理来提升薪水，不如让他们承担起更多责任。有时候，职位的重InfoQInfoQ架构师2022年11月5大家当然应该为自己的编程事业规划一条职业发展道路，但没必要把转管理岗当成霉的。毕竟经理人很容易替代，但优秀的程序员不可替代。他们掌握着企业最需要的代码知识，编程40年，如何保持技术前瞻性？InfoQ么保持自己Monty：我的办法是信任客户。我的想法一直很坚定，那就是跟客户合作、解决问所以只要有了良好而且足够广泛的用户群体，比如MySQL和MariaDB建立起的客户。我在等待未来的到来，同时也成为造就未来的一部分。所以，认真倾听客户意见，与他们合作，自然就能了解最新的技术。跟客户距离越近，我们就越了解功能需求，并对于开发者，我们要做的是为他们提供正确的技术、让他们满意。总之，只要明确另外，在接触世界各国的客户，比如中国的客户时，也可以跟内部员工讨论关于MySQL和MariaDB的问题。他们代表的就不是客户，而是社区成员。所以我会认真倾听。Monty：首先应该积极参与到社区当中，帮助他人、改进实现。如果你需要某项功能，就想办法着手开发，并随时向MariaDB#基金会寻求帮助。我们可以帮助大家，告诉你具体该怎么做。你审查过自己的代码吗？你也可以参与审查其他贡献者的代码，这就卷卷首语6工作来找你了。保持住好奇心，积极探索事情是如何运作的，这样我们就会变得更好，InfoQInfoQ架构师2022年11月7DevOps已死，平台工程才是未来者Tina平川最近，ScottCarey发表了一篇调查文章，喊出了一些开发者的心声：“扯淡的DevOps，我们开发者根本不想做运维！”除此之外，软件工程师兼DevOps评论员SidPalas也在推特上写道，“DevOps已死，平台工程才是未来。”热点热点|Hot8他的核心观点是：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自。Honeycomb的首席技术官CharityMajors对此也有同样的观点，她认为在软件演进过是一个巨大的错误。因此DevOps出现了，我们用它来重新统一开发和运维。然而开发周Majors的工程师跑代码。而现在，工程师不仅编写代码，还要运行他们编写的代码。这导致软件工程师觉得他们必须对所有事情都这迫使许多团队重新在自动化带来的自由与认知负担之间进行权衡。平台工程也因InfoQInfoQ架构师2022年11月9Gartner“平台工程”(图中第四个小圆点)。什么是平台工程？按照“平台工程”社区主要贡献者和Humanitec的产品负责人LucaGalante的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台(InternalDeveloperPlatform)”，可以涵盖应用程序整个生命周期的所有操作内部开发平台(以下简称IDP)是位于工程团队已有技术和工具之上的一层。它帮DevOps起DevOps和云原生的概念兴起之后，似乎是在突然之间，工程师们不得不掌握10种不乎认为，在全球经济的几乎其他所有领域都被证明有效的劳动分工(Ops和Dev)并不是热点热点|Hot开发人员应该能够端到端地部署和运行他们的应用。“谁构建，谁运行”，这才是虽然对于像谷歌、亚马逊、Airbnb这些比较先进的组织来说，上述方法很有效，但实践中复制真正的DevOps并不简单。最主要的原因是，与此相反，当一个普通的工程组织试图实施真正的DevOps时，往往会出现一系列的反模式。我们通过一个例子来看下，当组织决定实施DevOps并取消正式的Ops角色或团队时，许多开发团队中出现了什么情况。开发人员(通常是比较资深的)最终承担起了管理环境、基础设施等的职责。这就导致了这样一种情况：“影子操作”由那些在编码和产品开发方面才能体现出最大价值的工程师来执行。没有赢家。高级工程师现在要负责设置，并需要处理比较初级的同事的请求。在组织层面，其最昂贵和最有才华的资源这类反模式已经为许多研究所证明，比如Puppet的DevOps现状报告或是最近Humanitec的基准测试研究。后面这份报告根据标准的DevOps指标(准备时间、部署频在着上述反模式，有些开发人员要自己完成DevOps任务，并帮助经验不足的同事。与此InfoQInfoQ架构师2022年11月那么，低效组织和高效组织之间的关键区别是什么？最好的团队是如何确保他们的了，他们有一个搭建内部开发平台的平台团队。Puppet的《2020年DevOps现状报告》清最好的工程组织就是这样做的。他们成立了内部平台团队，负责构建IDP。在使用这些IDP时，开发者可以根据自己的喜好选择合适的抽象级别来运行他们的应用和服务。例如，他们喜欢摆弄Helm图表、YAML文件和Terraform模块吗？很好，他们可以这么做。他们是不关心应用是否在EKS上运行的新手吗？没问题，他们可以通过自助服务为自己提供一个环境，这个环境包含了他们部署和测试代码所需的一切，而且不用管它在哪里热点热点|Hot大道金光大道是什么意思呢？让我们具体看下。如今，大多数CI/CD设置的重点都只是简单地更新镜像。CI构建它们，更新配置中的镜像路径，完成。这覆盖了大多数部署用例。但是，当我们需要做一些基本工作流程之外的事情时，情况就开始变这样的例子不胜枚举。平台工程就是为所有这些需求铺好路。平台工程师提供粘合剂，将所有这些操作都绑定到一个一致的自助服务体验中，而不是让每个人什么操作都做，而且还必须了解整个工具链才能做到。这种粘合剂就是内部平台。用EvanBottcher(/articles/talk-的基础，它们被定位成一个令人信服的内部产品。自主交付团队可以利用该平台更快地交付产品功能，减少协调时间。”以这个定义为基础，我们可以将内部开发平台定义为“一个自助服务层，旨在让开发人员可以独立操作组织的交付设置，使他们能够通过自助服务获取环境、部署、数据库、日志以及任何他们运行应用程序所需的东西。”平台工程的原则许多组织开始意识到内部开发平台和开发者自助服务所带来的好处。按照Puppet《2021年DevOps现状报告》的说法，“平台团队的存在并不一定会解锁更高层次的DevOps；不过，优秀的平台团队会扩大DevOps方案的好处。”InfoQInfoQ架构师2022年11月然而，招聘合适的人才来构建这样的平台和工作流程并不简单。更麻烦的是，要确工程组织的其他部门提供可靠的产品，并将对方的反馈纳入IDP。队来说哪块最重要，都要确保一开始就把这个定义好。为平台团队赋予一个明确的角色为产品来对待问题KPI收集的定量信息。有价值粘合剂非常有价值。平台工程师需要在内部肯定和宣传自己以及自己的价值主张。一旦热点热点|Hot发明轮子同样，平台团队应该防止组织内的其他团队重复发明轮子，为同样的问题寻找新的案，他们自己也应该避免犯这样的错误。不管你自己开发的CI/CD解决方案处。与其构建内部的CI系统或指标仪表板，并与能力强20或50倍的企业竞争，还不如专注于现代工程组织MatthewSkelton和ManuelPais合著的TeamTopologies一书于2019年出版，在成功的InfoQInfoQ架构师2022年11月如上图所示，平台团队与其他所有团队都是平行的，旨在确保从编码到生产的自助一个常见的误解是，平台工程只在大型团队中才有意义。如果你的团队只有5名开发人员，那么平台团队和IDP肯定是多余的，可一旦你的组织发展到超过20-30名开发人LucaGalante建IDP的时间太滞后了，并因此承受了许多本不必承受的痛苦，例如，唯一一名负责DevOps的员工休假，整个组marysdeadembraceplatformengineeringlatformengineeringngorgblogwhatisplatformengineering热点热点|Hot上云“被坑”十年终放弃，寒冬里第一轮“下核子可乐Basecamp是37signals旗下一款流行的基于云服务的项目管理软件，其用户囊括了来自五大洲的166个国家的超75,000个组织。Basecamp的上云历程已经超过十年，而且其前两年发布的产品HEY也一直在云端运行。不过近日，Basecamp&HEY联合创始人David“我们用过亚马逊云科技、也用过谷歌云，试过裸虚拟机、也体验了Kubernetes容器编排。我们知道云能提供哪些功能，其中大部分都有实际应用。现在我们终于得出结InfoQInfoQ架构师2022年11月们正在筹划脱离云端、重归本地。”“从未适用于Basecamp”“云计算在两种极端情况下确实大有裨益，但只有其中一种跟我们有关。”Hansson解释道，首先是应用程序极其简单且流量很低的情况，这时选择完全托管服务Heroku就是这样起步的，同是PaaS提供商的Render则证明这条路完全行得通。从零行。但随着使用量的增加，账单也会水涨船高，并最终来到某个必须做出改变的时间节另一种就是负载波动几乎毫无规律可言。具体来讲，负载运行期间经常出现剧烈震荡或者高耸的峰值，但基准资源需求却只相当于峰值的一小部分。面对这种情况，大家择。“我们在发布HEY的时候也属于这种情况。当时，突然有30万用户挤在三周之内注”Hansson说道。但Hansson表示，“这两种情况都不再适用于今天的我们，也从未适用于Basecamp。样。如果真能遇上大灾害，那这钱花得确实有道理。可问题是并没有，这完全是在浪费资源。”Hansson以HEY为例解释道，公司每年需要为亚马逊的数据库(RDS)和搜索(ES)预算能买到多少台功能强大的服务器吗？”热点热点|Hot有更先进“那样你就得自己管理服务器了。云服务多简单，省下的可都是劳动力成本！”面对可能到来的质疑，Hansson先发制人：这么说的人肯定没尝试过在云端运行HEY或者Basecamp这类大规模服务。有些环节确实更简单，但有些环节反而更复杂。而且总体来讲，我还没听说过像我们这种体量的组织能单靠上云，就大幅削减自己的运营团队和日作为经营者，Hansson表示“云厂商的营销手段确实高明”。讨论的另一方总有话说，比如“你至少不用自己打理那么多基础设施设备”或者“基础设施服务构成你的核但Hansson也指出，与此同时，亚马逊凭借租赁服务器赚取着惊人的利润。尽管一直在做容量和服务升级，但AWS的利润率仍然接近30%(总营收62.2亿美元，利润为18.5亿美元)。而且随着该公司表示“计划在未来将服务器的使用寿命由四年延长至五年，“我对亚马逊靠云业务赚钱没有意见，毕竟租计算设备本来就不便宜。只是云服务总喜欢搞一大堆专业术语，比如‘按需计算’，听起来很酷，感觉比‘租计算机’整整领先了一个世纪。但二者好像并没什么本质区别。”Hansson进一步指出，“而且这不只是成本问题，更关乎我们未来要如何运营整个家巨头厂商的基础设施当中。如果AWS的某个主区域出现故障，似乎会有近半数网站随DARPA。”多年的商业模式跟自有硬件都能良好协同，业务的增长轨迹也有很好的可预测性。而且即使是用了亚马逊或者谷歌云，也还是得设置专业员工才能操作服务商那边的设备。“相信不只我们，还有很多企业都面临着类似的情况。”“而要想让互联网回归那片成本更低、去中心化度更高的净土之前，我们先得学会InfoQInfoQ架构师2022年11月从云服务商的那套营销话术中脱离出来。在云计算普及之前，大家都在运行自有服务器，了双眼，运行自有设施其实没那么可怕。当初我们就是这样一步步走了，才有了如今繁Hansson的决定也引发了开发者们的讨论。其中“降低复杂性、控制运营成本等承“仪表板是一个迷宫，许多非常常见的用例都要求您协调部署多个名称奇怪的产品。it裸机服务器，但我认为中小型公司应该考虑这个云产品的替代品，其中大多数都更容易使用。”mwassler。“我认为我对这个产品相当了解，有时我用它千美元来托管一些每天收到几千个请求的服务……拥有开发公司的人将他们的登录信息疯狂。在某天准备了一些。”还有开发者评论道，“IT一直存在集中化(入站)和分发(出站)的循环。服务提供商怎么会每5~10年卖给你同样的东西呢。”没有“下云”成功的GitLabBasecamp并非第一家想要“下云”的企业。GitLab在2016年底时候就表示GitLab此当时建了一个CephFS集群来解决NFS的容量和性能问题。但在将大量项目、用户和CI工件加载到CephFS上运行一段时间后，GitLab发现，CephFS热点热点|Hot另一方面，CephFS还遵从CAP定理，因此会放弃可用性以换取一致性。如果对系统施加很大压力，那么它会产生热点。例如高负载时，在托管GitLabCE存储库的机器集群中，所有读取和写入最终会间出现在同一个位置。GitLab认为，由于GitLab将系统托管在itLabOSDGitLab这一计划发出来后也引发了社区的热烈讨论，大家纷纷就GitLab面临的问题进做。正确处理硬件需要的专业知识庞大、昂贵且难以获得，这意味着要雇佣服务器、网“这与我们董事会成员看到的其他公司情况相似，上述工作花费了他们70%的工程最后，GitLab决定将所有存储分散到多个NFS分片(NFSshard)，并删除了堆栈中的CephFS，同时创建了Gitaly，这样就不必依赖NFS实现横向扩展，并可以通过缓存来加速InfoQInfoQ架构师2022年11月结束语在过去的五年中，云计算行业蓬勃发展，加上很多企业在疫情之初开始进行数字化着越来越大的财务和运营压力。据悉，苹果公司每月花在亚马逊云计算上的费用就超过因此，在人人都讲降本增效的今天，高昂的云计算成本能否带来同样高的回报也成udsIT管理层已经指示他们要减少或不承担额外的云支出。根据调研结果，39%的人已经决定将大量的云消耗和高性能工作负载迁移或留在本地，还有29%的人表示在2022年上半年未来，各种各样的压力是否会逼迫企业开始纷纷“下云”？我们对此也将持续关注。loudbetgitlabcomblogwhychoosebaremetal热点热点|Hot那位用Rust重写数据库的创始人来复盘了：删C码，值吗？莹前段时间，数据库初创企业RisingWaveLabs曾经发表了一篇博客文章，宣布完全删除掉了RisingWave(该公司开发的云原生流式数据库)的27万行C++代码库，并用Rust语言从头开始重写了一遍系统。本文，我们采访到了该公司的创始人&CEO吴英骏博士，放弃Rust，初抉择是C++吴英骏：RisingWave是一款云原生流式数据库，主要服务于需要超低延迟实时数据InfoQInfoQ架构师2022年11月分析应用。其定位不仅是一个SQL数据库系统，还提供流处理能力：使用流数据执行连这个架构最大的特点在于资源是无限的，既然有无限资源，性能并不是特别大的问这与编程语言的选择没有太大关系，开发一款数据库可以用各种各样的语言，比如之前的数据库，也鲜少有人使用Java、Basic、Python这类语言，主要是因为这些语言的被用户广泛接受，基本是C++和Rust。InfoQ：从之前披露的文章中可以看到团队最初选择的是C++语言来构建，并集结了多位具有10年以上经验的C++工程师，当时是看中了C++的哪些特质还只是遵循市面吴英骏：我本人比较擅长C++，不管是读博期间还是创业之前做的所有数据库都是创业之初，有人给我们提过可以用Rust写，理由是用Rust写容易火。在我看来，这需要考虑团队适合用、会用的语言以及数据库领域的通用语言是什么。在数据库领域，虽然TiDB的存储引擎TiKV是用Rust写的，但这不足以证明成功的数据库系统都是用Rust写用C++的。相较而言，Rust是一门比较年轻的语言，缺少比较重量级的项目，尽管这个语言是热点热点|Hot再抉择用Rust重写InfoQ您也提到对初创企业而言时间是非很痛苦，虽然CMake工具可以自动配置C++项目的编译，但使用起来还是很麻烦的，仍然需要手动配置和安装依赖库；STL库缺乏对一些现代编程工具的支持，依赖的社区项目大多数还都缺乏长期支持；最后，我们招聘进来的成员C++水生畏。随着越来越多人员的加入，C++的问题暴露得越来越频繁。这段时间，频繁有工另外，流式数据库通常用于对延迟非常敏感的关键任务。因此只能使用以下语言构建RisingWave：保证零成本抽象，不会有性能上限；不需要运行时垃圾收集，可以控制起初，我们是不愿意更换语言的，毕竟已经写了这么久。最后，我们表示如果支持用Rust重写的工程师可以对一个独立的模块改写成功，我们就考虑整体重写。与此同时，我也想起之前在AWSRedshift工作中遇到的一个Bug，三个人不断调试了两周都无解，最失。经过慎重评估，原来七个月写的代码用Rust重写需要花费大约两个月的时间，前后Rust速度。InfoQInfoQ架构师2022年11月在替换过程中，我们选择逐个模块替代，这也保证了整个过程不会出现很严重的问吴英骏：风格不统一的问题肯定不是使用Rust就能解决的，但相对C++会有很大程InfoQ：C++一些语言层面的缺陷由来已久，您将C++语言作为主要的开发语言，：我之前也遇到过，但上学期间，Rust没有现在完善，使用者很少，因此也不会考虑到使用Rust去开发数据库。此外，我之前接触的数据库是比较成熟的产品，比如IBMDB2，大部分时间都在调试，很难有精力和时间去把这么一个诞生了几十年的数。吴英骏：简单来说，框架是比较清晰的水平。重写不至于发现之前的Bug，但的确Rust的爽点foQRust吴英骏：首先，安全性肯定是让我们觉得是比较爽的，这对数据库项目非常重要。C时去想如何在CMake里面配置一个包管理工具，甚至是在花费了很多时间之后，我们发现装不上去，还可能会遇到重名的问题(其他项目中使用的变量名称可能和我们使用的库中的名字重合了)，这些问题都需要手动解决，而且改起来费时费力。热点热点|Hot重写收益比InfoQ如何？吴英骏：总结来讲，这件事情的收获非常大。从收益比的角度看，我们损失的是时间，因为分段重写大概花费了一个月左右，但这些时间并没有浪费掉，这个过程让我们又反思了一遍不同模块的设计思路，改掉了其中不合理的部分。对数据库系统而言，这我们收获的是系统更加稳定、安全，且代码清晰，尤其是包管理部分有非常大的提升。此外，Rust本身在高速发展中，整个社区非常有活力，提问基本都能够得到及时回使用Rust重写要注意的地方：团队中有部分工程师之前就懂Rust，只是未在工作中使用，这部分工程师还是比较容易转型的。我们也专门让一些工程师评估从零开始学Rust需要多久，绝大多数工程师一个月之内基本能够掌握Rust，但还达不到全面掌握，只是可以使用Rust写一整个过程比较顺利也得益于部分工程师会利用业余时间自学并将经验告知其他人，这是非常重要的。我认为，如果公司决定重写，必要条件是公司内部有一到两个，甚至更多使用Rust进行过实战的工程师，或者至少是愿意用业余时间时间并将经验传授给其吴英骏：会有差异，而且比较明显。C++属于底层语言，掌握了C++意味着你基本明白内存管理、指针、面向对象等理念。对于其他语言，比如Python，最大的特点是简化InfoQInfoQ架构师2022年11月开发者不需要考虑内存管理等事情，但Rust是需要这方面基础的，所以不同的语问题吴英骏：Rust确实存在编译时问题，但编译C++相对也比较慢，但目前还在可承受的范围之内，如果时间比较长，工程师会定期查看编译进度，并尝试是否有办法可以缩重写理由InfoQ：你会建议什么类型的公司或者业务团队在什么情况下选择重写？吴英骏：如果是在一个大型公司内部选择重写，大概率表明该项目不是那么重要，况下可以考虑重写。对创业公司而言，早期还有精力重写，一旦用户量上来了就会面临此外，需要梳理清楚转换语言的理由，出于性能、安全性或者其他原因，而不是为间的磨炼，其实转Rust的需求并不大。总的来说，我觉得是非常看中实际需求，需要全骏：整体来看，Rust的生态环境还比较不错，主要问题是在于缺少大型项目验证，比如Go最成功的项目是Kubernetes。当然，我们现在已经看到有不少科技公司考虑使用Rust重写某些服务，比如InnoDB，也看到很多公司加入了Rust基金会，比如AWS、Google、Facebook等，相信通过这些公司的长期支持，未来会出现一些非常不错的项目。Rust能够获得这些大公司、初创企业(背后的投资人和投资机构)的支持，我相信社区热点热点|Hot吴英骏：我觉得重写和团队规模的关系不是很大，但我建议更加年轻的团队选择Rust，当然这也因人而异。至于最终是否要转，也要遵循团队大多数人的意见，因为如果在学习了一段时间的Rust语言之后发现还是没有熟练掌握可能会有比较强的挫败感，。InfoQInfoQ架构师2022年11月字节大规模微服务语言发展之路马春辉在DIVE全球基础软件创新大会2022上，阿里云程序语言与编译器团队负责人李三红出品了《DIVE编程语言新风向专场》专题。本文整理自字节跳动高级工程师马春辉在DIVE全球基础软件创新大会2022的演讲分享，主题为“字节大规模微服务语言发展之Golang现状o常热门的一门语言，根据2019年的JetBrains的统计，现在全球有两百多万名开发者，并理理论派|Theoryr在字节内部，微服务使用最多的语言就是Golang。但字节也不是一开始就使用Golang。最早期用的是Python，在2014年，我们经历了一场大规模的微服务开发的过程，从Python转向Golang。据说一个最主要的原因是当时Python对CPU资源利用率不高，当时负责语言选型的同学经过调研，最终选择了Golang。现在看来，这位同学眼光非常超当时为什么没有选择Java？Java有非常多优点，一直到现在都具有统治力。但是站在微服务角度，它有一些固有缺点，比如说资源开销。并行时资源开销越低，意味着部署密度越高，计算成本越低。而Java在运行过程中，要花费较多资源进行JIT编译。另外，JVM本身要占用大概五六十兆左右的内存，而在微服务中，内存不能超卖超售，所以相对于分布式架构的微服务来说，会影响分发部署速度。此外，Java的启动速度也一直比较令人诟病，对于需要快速迭代和回滚的微服务来说，启动速度慢会影响交付效率和快这几年开始兴起的静态编译。但是很遗憾，字节进行语言选型时，这些项目还不存在。另外可能还有一个没有选择Java的原因，就是当时负责语言选型的同学不是特别喜欢Golang优势中科院的崔慧敏教授说过这么一句话：“设计编程语言一直有两个目标，一个是让挥更高性能。”Golang就是让编程越来越容易的一种语言，它在开发效率和性能之间取得了比较好Golang有很多优点。首先，它从语言层面上支持高并发。它自带了Goroutine、也就是协程，可以比较充分地利用多核的性能，让程序员更容易使用并发。其次，它非常简单易学，并且开发效率非常高。Go的关键字只有25个，对比一下C11，大概有40多个关InfoQInfoQ架构师2022年11月键字。虽然Go的关键字数量更少，但是表达能力很强大，几乎支持大多数其他语言里一Golang存在的问题Golang作为一个开源语言，而且Goteam的核心成员也曾公开表示Go完全开源，并o区的Go”。比较典型的一个故事就是Go的module的发展历史，或者说它的上位史。一般来说，Go的发展一直被Google的GoTeam核心团队牢牢把控，外界的声音、社区的声音，对Go语言的发展来说似乎没那么重要，也就是说，外界很难主导设计一个完整的特前面提到，随着单个微服务本身大小的增加，以及部署微服务的机器数量越来越多，我们遇到越来越多的性能问题。这些性能问题，可以分为以下两个方面，一个是GC，这是属于内存管理的一个问题；另外一个是编译生成代码的质量问题。另外在调度 (Scheduling)这块，我们也有同事在进行一些优化分析工作。GC清除(CMS)算法收集器。但是需要注意一点，Go在实现GC的过程当中，过多地把重心放在了暂停时间——也就是StoptheWorld(STW)的时间方面，但是代价是牺牲了GC中理理论派|TheoryC对吞吐量有多大的影响；还有，在一段固定的CPU时间里可以回收多少垃圾；另外还有StoptheWorld的时间和频率；以及新申请内存的分配速度；还有在分配内存时，空间的Golang在设计和实现时，过度强调了暂停时间有限。但这带来了其他影响：比如在执行的过程当中，堆是不能压缩的，也就是说，对象也是不能移动的；还有它也是一个不分GCGC比较多CPU资源。我们有同事进行过一些统计，很多微服务在晚高峰期，内存分配和GC时间甚至会占用超过30%的CPU资源。占用这么高资源的原因大概有两点，一个是Go里面比较频繁地一个是Go在分配堆内存时，实现相对比较重，消耗了比较多CPU资源。比如它中间有acquiredM和GC互相抢占的锁；它的代码路径也比较长；指令数也比较多；内存分配的局部性也不是特别好。因此我们有同学做优化的第一件事就是尝试C我们这边同学经过调研发现，很多微服务进行内存分配时，分配的对象大部分都是比较小的对象。基于这个观测，我们设计了GAB(Goroutineallocationbuffer)机制，用分配请求执行一个比较完整的mallocGC方法，而我们的Gab为每个Goroutine预先分配一个比较大的buffer，然后使用bump-pointer的方式，为适合放进Gab里的小对象来进行快速分配。我们算法和tcmalloc算法完全兼容，而且它的分配操作可以随意被Stoptheworld打断。虽然我们的Gab优化可能会造成一些空间浪费，但是在很多微服务上测试后，发CPU%到12%。生成代码另外一个问题是Golang生成代码的质量问题。Go的编译器相比传统编译器来说，可sInfoQInfoQ架构师2022年11月对于我们微服务的一些场景来说，可以不用那么在意编译速度。我们很多微服务，U然，我们还是控制了编译速度和binarysize的代价。比如说我们binarysize通常的增长大，大概50%到100%左右。第一个优化就是内联优化。内联优化是其他优化的基础，它的作用就是在编译时，Golang原生的内联优化受到比较多限制。比如一些语言特性会阻止内联，比如说如defer个函数内联到调用的地方，可能会导致defer函数执行的时机和原有语义不一致。所以这种情况下，Go没有办法做内联。此外，如果一个函另外，Go的编译器从1.9才开始支持非叶子节点的内联，虽然非叶子节点的内联默认是打开的，但是策略却非常保守。举个例子，如果在非叶子节点的函数中存在两个函数调用，那么这个函数在内联评估时就不会被内联。另外，从实现的角度上，内联的策略也做得非常保守。我们在字节的go编译器中修改了内联策略，让更多函数可以被内联，这样带来的最直接收益就是可以减少很多函数调用开销。虽然单次函数调用的开销可能。另外更重要的是，内联之后增加了其他优化的机会，比如说逃逸分析、公共子表达式删除等等。因为编译器优化大多数都是函数内的局部优化，内联相当于扩大了这些优，理理论派|Theory还有另外一个更重要的运行时开销。也就是说，内联增加后会导致栈的长度有所增加，整的背景。Golang通过goroutine支持高并发，用户可以创建非常多的goroutine。为了降低对内存的要求，每个goroutine的栈就不能像其他语言的线程的栈那样，设置成两兆到八兆这么大的空间，要不然很容易OOM。在Linux上，Golang的起始栈大小是2K。Go会在函数开头时检查一下当前栈的剩余空间，看看是否满GO。我们收益最大的一个优化应该就是内联策略的优化调整上。另外我们还进行了一些其他优化，比如说前面提的Gab优化，我们会在编译期把Gab的快速分配路径直接生成到低在堆上的分配。而Golang分配对象到堆上还是栈上，这个过程由逃逸分析控制，所以大家可以看到，我们目前在编译器上实现的优化，大多都是通用优化。理论上，所InfoQInfoQ架构师2022年11月我们发现，基本上线上所有微服务或多或少都会节省一些CPU资源。除此之外，延迟也有不同程度的降低，以及内存使用也有不同程度的下降。我们在目前上线的一些微正因为我们在编译器上经过了几个简单的优化，都能得到这么明显的优化效果，所继续尝试在Go原生编译器里引入更多编译器优化，希望进一步提升Go的原生编译器性能；另一个，我们也考虑借助LLVM强大的优化能力，Gollvm基本可用，但是不支持很多重要的观测Go的问题，就是性能观测问题，它自带的pprof工具，结果不是太准确。这在Go社区内部也有一些讨论，大概原理理理论派|Theory是Go的pprof工具使用itimer来发生信号，触发pprof采样，但是在Linux上，特别是某些版Linux么准确。根据我们pprof的结果来统计，一些容器上大概有20%甚至50%的结果被丢掉了。它还有一个问题，在一个线程上触发的信号可能会采样到另外一个M上，一个M上触发的这个采用信号可能会采到另外一个M上的数而perf呢，很遗憾，我们很多线上容器内部不支持perf。出于一些安全策略的考虑，用pprof的一些接口，使用硬件的PMU来触发采样。但是Uber的pprof++的一个问题是性能损耗非常大。我们经过一些验证，发现在一些小例子上，在打上Uber的pprof++的patch之后，仅仅是打上这个patch而不是打开这个pprof，就有大概3%左右的性能损耗。我们前面做编译器优化、做内存分配优化，性能提升很多也就提升5%到10%，只把这我们在Go1.6、1.17上，也仿照Uber，采用了PMU的pprof形式。这种方式实际验证总结与展望从长期趋势来看，基于更高级编程语言的软件系统会逐步取得竞争优势。因为随着CPU等硬件资源的价格进一步下降，而开发成本，开发人力成本，还有项目研发风险以Go有非常好的开发效率，也有着可以说媲美C的性能，而且它还很好地提供了互联网环境当然，未来可能会有一种新语言，有更好的效率、更高的性能，也可能会有更开放InfoQInfoQ架构师2022年11月虚拟机相关软件研发经验，曾参与HPACC编译器、IBMJDK、华为毕昇编译器/虚拟机等理理论派|Theory去哪儿网ServiceMesh落地实践：100%容器化打底，业务友好是接入关键娟自2011年引入Dubbo框架至今，去哪儿网的微服务架构已经有了十多年的历史。时根据去哪儿网基础架构部高级技术总监朱仕智分享的数据，现在去哪儿网Dubbo服hon等5种语言的技术栈，其中以Java和Node为主。此外，去哪儿网在线运行的应用大约InfoQInfoQ架构师2022年11月首先，多语言的复杂性主要在于SDK的重复实现，每个治理逻辑需要开发不同的语在多协议治理上，一方面，去哪儿网内部有Cactus平台对Dubbo进行治理，治理功能相对完善。另一方面，去哪儿网对HTTP的治理主要通过OpenRestry，治理能力相对薄Dubbo和HTTP治理能力不统一导致了重复造轮子情况，增加了业务的开发和维护成此外，业务和中间件强耦合，但业务部门与基础架构部门对升级更新的意愿并不同步。基础架构部门不断升级更新来完善中间件，但业务研发在不影响使用情况下并不希而ServiceMesh将服务治理能力下沉到了sidecar，SDK只需要负责编解码、与sidecar通信，通用逻辑基本不用修改，只要对sidecar修改就可以应用到所有语言和框架，于是在去年，去哪儿网开始组织团队引入ServiceMesh来解决自身多语言、多框架的治理难容器化基础深开发工程师李佳龙看来，容器化下比较适合引入ServiceMesh。大概从2014年起，去哪儿网便开始使用Docker、Mesos、Kubernetes(以下简称K8s)等来解决测试环境构建困难的问题，也逐渐尝试基于容器部署ES、MySQL等中间件服务。到了2021年底，去哪儿网全面实现容器化，业务服务基本完成上云。从效果数据来看，容器化虚拟比例从1：17提升到1：30，资源利用率提升76%，宿主运维时间由天变成了分钟级，环境稳定性差、交付慢、可扩展性差和服务器成本高等问题都得到了有效解决。经过多年积累，去哪儿网已经为引入ServiceMesh打下了坚实的基础。引入Service在去年加入去哪儿网后，李佳龙主要负责ServiceMesh的落地工作。团队基于去哪理理论派|Theory儿网的现状，明确了对新服务治理体系的期望：多语言、多协议统一治理、治理能力增如何做技术选型整个实践过程主要分为三个阶段：调研、开发和推广。调研阶段的主要任务是技术bbo有选择重复造轮子，而是基于业内已有开源软件进行选型。其次，去哪儿网团队还从产NSN语言也是重要的考虑因素。由于在C++技术栈方面人才储备有限，团队放弃了流行nvoyMOSNGoInfoQInfoQ架构师2022年11月控制面上，去哪儿网选择了Istio，并根据自身需要对其进行了二次开发。Istio使用XDS协议与数据面进行交互，是很多企业的首选，去哪儿网选择紧跟社区的脚步。但原生的Istio有个问题，就是和K8s耦合非常严重：主要体现在K8s既是注册中心又是配置中ceKVM，如何解决兼容问题?公司内部已有比较成熟的注册中心和配置中心，一刀切必然会引入很多适配和运维Ks在最初商定方案时，选择解耦K8s，采用内部使用多年的注册中心和配置中心。于一些启动配置，则依赖去哪儿网内部的配置中心(QConfig)，同时团队自研了McpServer模块替代K8s来对接Istio。接入Mesh后，业务主要关心的就是性能、治理能力和问题排查。因此在做好技术选理理论派|Theoryes去哪儿网主要使用了两种流量转发方式：一是升级SDK，在SDK中直接将请求转发到sidecar截，例如使用dnsMasa将的请求转发到本机sidecar。李佳龙提醒道，引入ServiceMesh后，流量安全值得特别关注，因为之前两个服务decarr对于sidecar的配置、部署、升级、回滚和灰度等，去哪儿网团队将其整合到了运维arSidecarInfoQInfoQ架构师2022年11月decar对于原地升级，由于sidecar容器和业务容器是同属一个pod的两个独立容器，基础架构团队将MosnAgent作为sidecar容器的1号进程，用于管理sidecar的生命周期，例如启snAgent而部署时升级，发布平台会请求sidecar管理平台来获取sidecar配置，包括是否注入、sidecar信息等，然后生成服务的yaml配置。注意在部署时，有可能遇到sidecar容器、业务容器的启用顺序问题。如果sidecar容器未启动成功或者配置未拉取成功、但业务容器已经ready，那么请求就会失败。基础架构团队设置成sidecar先于需要注意的是，Istio下发配置时，也可能发生顺序异常问题。去哪儿网团队通过iomerkeltreeside另外，运维面还负责对接内部系统，如内部配置中心、全链路监控系统、报警系统、理理论派|Theory在性能优化方面，首先由于业务容器与sidecar容器同属一个pod，基础架构团队选其次，团队对Dubbo协议进行了优化。sidecar接收到请求后的第一步是获取路由信息，用以服务寻址。按照Dubbo原来的设计，路由信息(service/method/group等)存放在body中，但为了避免不必要的body反序列化，团队扩展了内部Dubbo协议，将路由信但是原生的Istio会拉取当前集群中所有服务数据，导致sidecar资源占用过多以及推送风暴，大大制约了ServiceMesh的集群规模，这也是很多公司落地ServiceMesh要解决的问题。去哪儿网的解决方式是配合内部SpringCloudQunar框架，在编译器采集订阅关系，针对之前治理功能分散、能力不统一的问题，基础架构团队将Dubbo和HTTP统一到“在设计时，Captain要尽量做到服务治理与协议无关。”李佳龙说道。比如，之前Dubbo服务需要在项目中配置参数支持调权预热、HTTP在发布平台配置支持引流预热或者自定义接口预热，引入ServiceMesh后就可以很方便地支持Dubbo/HTTP调权、引流两度限流和基于优先级限流。业务团队既可以根据应用的不同来设置不同的限流阈值，也如下图所示，当流量达到设定的阈值时会触发限流，这时流量会进入到多个优先级InfoQInfoQ架构师2022年11月此外很多情况下，业务会将超时时间、限流阈值设置得比较大或比较小，这未能起如何进行推广“推广是最为关键、也是比较容易出现阻塞的地方。因为对于用户来说，让系统最那么，如何让业务更容易接受ServiceMesh呢？去哪儿网团队先是在内部做了关于MeshMesh然后对于新服务治理平台，基础架构团队也注意保留了很多业务的使用习惯。比如在实际使用中，超时时间等治理参数与路由的相关度较低，业务更习惯作为服务提供方配置某个接口的超时时间，或者作为服务调用方配置要调用服务的超时时间。但在xDS理理论派|Theory基础架构团队现在提供了两种Mesh接入方式：第一种是接入新的开发框架Spring而不是一刀切地接入。基础架构团队的策略是让业务先从一个小的接口、小的流量来接ServiceMesh切换起来是不是安全和方便、需求是不是能够满足、能不能保留之前的研发习惯等等。ServiceMesh多工作，比如进行二次开结束语SDK负责编码以及与sidecar的通信，这部分比较固定，不包含治理功能。虽然还是多个实现，但是复杂度降低了一个量级，从而将更多的功能实现，抽离到独立的sidecar进程，只需入ServiceMesh呢？李佳龙表示这具备K8s的基础设施了，但是我们仍然可以有多种方式支持虚机接入服务网格，只要解sidecar、升级，流量拦截，服务注册发现等。而且我们设计之初去除了K8s的耦的底座，在容器之上能更好的支持ServiceMesh、Serverless等。”InfoQInfoQ架构师2022年11月越来越复杂后，才可能会出现多语言、多框架的问题。只有确实出现这个问题时，才应该开始考虑是否引入ServiceMesh。此外还需要考虑自身的基础设施、团队技术储备等是否支持落地。ServiceMesh是利用低复杂的技术去解决高复杂度的问题，如果本身复还有一个值得关注的方面就是性价比。引入ServiceMesh的新增成本包括sidecar所占有的资源，比如每个sidecar占用的CPU、内存、磁盘以及其他如trace存储、日志存储等业务的使用成本。与业务解耦后，我们的推广周期也大大缩短。”“ServiceMesh应该会是未来的一个发展趋势。”李佳龙表示，“之后去哪儿网会在可观察性、性能优化、多语言支持上持续发力。”原生、基础架构等领域，负责去哪儿内部ServiceMesh和新服务治理平台Captain的研发推荐文章推荐文章|Article新一波JavaScriptWeb框架FrontEndMasterySambodhi太过保守很难在Javascript生态系统中保持与时俱进。对于那些刚进入这个行业的人InfoQInfoQ架构师2022年11月不要把注意力集中在快速增长的解决方案上，而是从潜在问题入手。每一种架构都网页简史Web提前准备一份文件，并把常酷。于是我们有了像CGI这样的技术，使我们能够根据请求提供不同的内容。然后，我们有了像Perl这样的表达MLRegards.代拉开大幕这些动态页面很受欢迎。我们可以很轻松地对发送给用户的内容进行定制，包括启推荐文章推荐文章|ArticlesWeb的发展一日千里，我们想要更多的互动体验。为了这个目的，我们使用了Flashvascript像jQuery和Prototype这样的工具出现了，它们隐藏了WebAPI的复杂度，消除了浏光阴荏苒，科技公司的规模在不断扩大，并且由于项目和开发团队的增长，在模板业务逻辑的“混合体”来访问全局变量。由于像SQL注入这样的攻击已经司空见惯，因ations为我们带来了Ajax技术。现在你用Ajax技术可以做的新事情就是用异步方式更新页面，而不再是以同步的方式来更新页面。这种模式被第一批大型客户端应用程序所推广，如谷歌地图和谷歌文档。后来，我们开始看到Web分发对桌面风格的软件的影响力。与在ript所有这些都是开发人员所熟悉的异步优先模式。这曾经令人无法抗拒，当然现在也是。端分离我们更渴求能够与桌面、移动设备相媲美的Web。现在，我们已经有了一系列可重InfoQInfoQ架构师2022年11月导致了前端和后端的模板重复。像Backbone和Knockout以及许多其他的框架出现了。它到的所有小部件和JQuery插件。添加结构有助于扩展所有这些前端代码。并且可以加速DOM页面并保持组件的同步。这个问题非同小可，在谷歌的支持下，Angular登场了。它通过增强HTML的动态性，促进了生产力的提并占据主线程(今天像Svelte这样的库可以在降低其缺陷的情况下保持双向绑定)。除了移动设备的兴起之外，这些提高生产力的框架也加速了前端和后端的分离。这为探索强大的CDN基础设施，有了可以与独立API互动的解耦前端，就无需依靠远在天边的中央React崛起快步流星地进入大科技时代。我们正试图追风逐电，一改故辙。对于那些进入这个推荐文章推荐文章|Article2.组织上的扩展：优先考虑进入市场的时间和速度。对于新开发人员来说，能否快。前端关注点的分离是著名的反思，以前的MVC框架无法扩展。人们并不喜欢从模板组件模型允许解耦独立的前端团队，他们可以更容易地在独立组件上并行工作。作为一个架构，它允许组件的分层。从共享的原语到构成页面根目录的“有机体”。单向的数据流使数据流更易于理解、跟踪和调试。这就提高了之前难以企及的可预见性。虚拟DOM就是我们可以编写函数，返回用户界面的说明，让React去解决这些难点。这样规模化的React已达到CPU和网络的极限DOM是React模型的一个问题。浏览器并不是为了在连续的渲染周期中不断创建和DOM任何可以通过引入一个新的间接级别来解决的问题一样，人们只有在100毫秒以内感知到反馈，才会感到流畅。而在做像滚动页面这样的事的新瓶颈。当虚拟DOM和真实DOM之间发生协调时，大型交互式应用程序会对用户的输本增加InfoQInfoQ架构师2022年11月动速度慢就成为一个问题。我们开始注意到所有隐含的运行时成本，不仅是HTML和虚S组件模型简化了我们在CSS方面的经验。我们可以将样式与组件放在一起，这提高了可删除性。对于那些以前不敢删除CSS代码的人来说，这是一个非常好的属性。我们JavaScriptCSS抽象化了。这些第一波的库往往伴有隐含的运行时成本。我们需要等到组件被渲染后，再将这些样式注入到页面中，这就造成了JavaScript包中的样式问题。从规模上来说，糟糕的性能往往是千夫所指，而我们也注意到了这些成本。这导致JavaScript库中出现了新的CSS，下的网络和渲染受阻的组件当浏览器渲染HTML时，像CSS或脚本这样的渲染障碍资源会阻止HTML的其他部分显在实践中，许多组件依赖于数据库的数据和CDN的代码(通过代码分割)。这经常它们将会获取它们所需的数据，并重复这一过程。经常可以看到“下拉列表的地狱”或Facebook如何解决这些问题在React中，虚拟DOM的运行时成本是无法避免的。并发模式是一个解决问题的方推荐文章推荐文章|Article在JavaScript中的CSS领域，使用了一个名为Stylex的内部库。当成千上万的组件被渲Facebook用Relay来避免顺序性的网络瀑布问题。对于一个给定的入口点，静态分析可以精确地确定要加载的代码和数据。这就意味着代码和数据都可以在一个优化的就很困难了。还有语言和地区设置。当代码有许多分支时，静态依赖关系图不能看到在起使用的模块。Facebook使用了一个由人工智能驱动的动态包系统。这利用其紧密的客户-服务器集成，在运行时根据请求计算出最佳的依赖图。这与一个根据优先级分阶段加载包的框架Facebook拥有复杂的基础设施和多年来构建的内部库。如果你是一家大型科技公司，这为前端产品开发人员创造了一个成功的深渊，可以让他们在完成任务的同时保持我们中的大多数人都不会像Facebook那样的规模上构建一套应用。然而，对于许多。InfoQInfoQ架构师2022年11月大型科技公司经常在内部推出自己的应用框架。在不同的用户资源库中，遗留了大还跟我们在一起？我们正处于SPA的时代。这就是目前从事这一行的人所面临的现乱，每个层都有自己的概念和API。如今，很多开发人员都被不确定的事情所困扰，他们不知道应该怎么去做，也不知估迁移到Angular2或React时，Vue填补了入门门槛低的空白。你不必为复杂的webpack配置而担心。你可以从CDN上下载并开始使用对许多开发人员来说很直M推荐文章推荐文章|Article有这些都是基于声明式组件和熟悉的可变Javascript风格来保持现代的创作体验。Svelte完全避免了使用虚拟DOM，因此不会受到编写Javascript的不可变风格的约束，这种风格可以用来做更新状态之类的事情。对于许多人来说，这是一个更简单、更理智地在WebSolid有一个直接的和可预测的反应性模型，其灵感来自Knockout。像React一样，它而React采取的是不断重新渲染世界的方法。Solid只渲染一次，并在不增加虚拟多React开发人员想要使用钩子的新代码那样。它的API也许更人性化，并且在许多方面对于每个框架，还有许多可说的。每个人都会在自己的基本模式和喜好上作出不同在现实中，进化往往是由人类的意志决定的。尝试不同的解决方案来解决当前的痛点，每个框架都从彼此中学习。其中一个重要的主题就是精简和简化。把事情从运行时orget同时，我们看到了纯客户端渲染的权衡。当加载一个页面时，那个空白的白屏需要InfoQInfoQ架构师2022年11月 (后来才发现这是一种权衡)。这个最初的倒退引发了许多“元”框架和HTML优先前新一波的JavaScriptWeb框架我们不会停止探索。我们所有探索的终点就是我们开始的地方。也是第一次知道这受PHP的启发，Next开始简化创建静态页面推送到CDN的过程。它还解决了在React有其他一些不错的特点。从那时起，又有一波“元”框架被创建。对于Vue，我们在Web。这并不仅仅是多页面架构从服务器上提供HTML，其中导航是全页面刷新。快速启动对于很多站点来说都是至关重要的，尤其是那些没有登录的站点。它直接关系到诸如搜索排名和跳出率之类的事情。对于许多互动性低的网站和应用程序来说，使用像React这样的客户端相比，路由器停留在服务器上，而不是让客户端的路由器在第一次加载后接管。在推荐文章推荐文章|Article这一轮的MPA与前几代不同。“Sprinkles”是在一个基于组件的模型中编写的，通常使用island模式。在前端和后端代码中使用相同的语言。往往在同一个文件中共存。增强的回归技术角度来看，Remix是ReactRouter的编译器，和其他新兴的元框架一样，是一个边缘兼容运行时。它通过嵌套布局和数据获取API，解决了Facebook通过Relay大规模这允许早期的代码和数据的并行获取。这是用Suspense实现“边渲染边获取”模式的一个良好前提条件。对渐进增强的强调意味着它的API基于Web标准，数据变异的故事而不是通过连接事件处理程序来进行必要的获取请求。你渲染表单，将数据提交给在服务器上处理它们的动作函数(通常在同一个文件中)。受到PHP的启发。与Next类似，应用程序可以缩小规模，像传统的服务器渲染的MPA那样在没有Javascript的规模扩展到交互式React应用程序。Remix还提供了许多API和模式，用于处理诸如乐观的UI更新、静态条件的处理以及优雅的退化之类的事情，这些都是你希望一个专注于终端用户体验的深思熟虑的框架所来不要与Quic协议相混淆。Qwik这个框架是关于尽量减少不必要的Javascript。虽然它就像你可以暂停一台虚拟机并将其移动到不同的物理机上。Qwik把这个想法带到了服务器和浏览器之间发生的工作。它的“可恢复”水化的想法意味着你可以在服务器上启动一些东西，然后在客户端上恢复，而不需要任何重新工作。这与部分水化形成对比，InfoQInfoQ架构师2022年11月过渡到SPA。有时(用更流行的话来说)被称为“过渡性应用程序”。边缘的生活变得简单而快速。现在将运行时和数据转移到边缘也变得可行了。这是在浏览器之外创事情移回服务器变得更加容易。同时在一定程度上减轻了这样做所带来的网络延迟的取像React服务器组件这样的想法正在探索将服务器组件的输出从这一层流向浏览器的概念。像Deno和Bun这样的新的Javascript运行时正在出现，以简化和精简Javascript生态这也导致了应用框架采用标准的网络API来在这一层运行。随着无服务器功能和流流(Streaming)是这里的一个大主题。它允许提前刷新HTML，因此浏览器可以在概括本文讲了那么多，但实际上只是触及皮毛而已。对于本文中提到的最佳框架、架构或模式，以及我们没有提到的无数其它框架、架构和模式，并没有一个通用的答案。它始终是对特定指标的权衡。而要知道如何权衡，取决于你正在构建的东西、你的用户是谁、他们的使用模式，以及围绕关键用户体验的任何其他要求(如性能预算)的设定。推荐文章推荐文章|Article对于我们中的大多数人来说，真相在某个中间的地方。新一波框架和创新的伟大之处在于，它们提供了根据需要扩大和缩小规模的杠杆。对于那些进入这个行业的人和那Web前对框架的需求，并减InfoQInfoQ架构师2022年11月字节跳动开源BitSail：重构数据集成引擎，走向云原生化、实时化芳自年初成立开源委员会以来，字节跳动开源动作频频。公开信息显示，字节跳动近五个月新开源了不少项目，包括Shuffle框架CloudShuffleService、基于Rust的RPC框架 BitSail支持多种异构数据源间的数据同步，并提供离线、实时、全量