《架构师（2022年11月）.pdf》由会员分享，可在线阅读，更多相关《架构师（2022年11月）.pdf（76页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 CONTENTS/目录 热点|Hot DevOps已死，平台工程才是未来 上云“被坑”十年终放弃，寒冬里第一轮“下云潮”要来了？那位用Rust重写数据库的创始人来复盘了：删除27万行C+代码，值吗？理论派|Theory 字节大规模微服务语言发展之路 去哪儿网Service Mesh落地实践：100%容器化打底，业务友好是接入关键 推荐文章|Article 新一波JavaScript Web框架 字节跳动开源BitSail：重构数据集成引擎，走向云原生化、实时化 观点|Opinion 当“增加人员”不足以解决问题，你就该考虑应用“微前端”了 架构师 2022 年 11 月刊 本期主编 褚杏娟
2、反馈 流程编辑 丁晓昀 商务合作 hezuogeekbang.org 发行人 霍泰稳 内容合作 2 卷首语 卷首语卷首语 专访“专访“MySQLMySQL之父”：要拥有一份能做一辈子之父”：要拥有一份能做一辈子的开发工作，需要给自己积累名望的开发工作，需要给自己积累名望 作者：作者：李冬梅李冬梅“热爱”，是贯穿于“MySQL之父”Monty过往40年编程人生的关键词。60岁的Monty现在仍在写代码，每周保持60个小时的高工作强度。他说，等到80岁时，才会考虑将工作缩短到35小时。编程这事儿，他还要干一辈子。二十年磨一剑 InfoQ：您在34岁时开发出了MySQL。从接触编程到开发出MySQL
3、，这段时间可真不短，您都做了哪些工作？Monty：我从18岁的时候就开始编写MySQL的最早一批代码了，这部分代码主要是MySQL内存控制方面的，所以最早的开发工作可以追溯到1982年左右。后来的开发工作都是以之前的成果为基础。在此期间，我也开发过不少硬件驱动程序，设计了一款不错的处理器，还做过很多游戏。InfoQ：这么长的开发历程，是什么让您一直坚持了下来？Monty：我想，是热爱。我喜欢做开发，我特别喜欢解决问题的感觉，特别是在开 3 InfoQ 架构师2022年11月 发MySQL和MariaDB的过程中。而且，我参与了开源，帮助很多人走向成功。我觉得这一切都能让人始终保持热情。Info
4、Q：从您写下第一行代码到开发出MySQL，花费了近二十年时间。但目前市场上也有不少企业投入过十年甚至十五年来开发软件，但最终成果从来没能真正流行起来。你怎么看待这样的现实？Monty：我确实是用了快二十年才开发出MySQL，但当时我没有想到未来这个软件会发展成什么样子。我将我的软件卖给了北欧最大的一家电脑公司，但后来，我的软件成了整个平台上最受欢迎的产品。你提到的这种情况也的确存在，很多公司耗时耗力，最终却一无所获。MySQL的成功是与时代背景分不开的。当时互联网已经得到广泛认可，每个人都需要这样的数据库，用它创建互联网所需要的数据。当时那些技术巨头还不看好互联网，所以这是个有待开发的蓝海市场
5、。其实只要意识到需求的存在，其他的就都好办了，所以我从94年开始正式编写MySQL。最终成果的发布大概是在95年末，也就是说，我们用了短短两年就开发出了MySQL的第一个版本，成为当时的新兴支撑性产品。InfoQ：技术圈内，您被誉为“编程天才”，您怎么看待这样的称呼？Monty：我觉得差不多，我在编程方面确实有点小天赋。InfoQ：我想不只是编程这一个领域吧，您在创业方面也很成功啊。Monty：嗯，我在企业家、开源倡导者、程序员和架构师几个角色上表现得都还可以。InfoQ：您是否会认为，如果一个人想在某个领域取得卓越的成就，天赋是不是比努力更重要？Monty：那是肯定的。毕竟在编程行业，一个优
6、秀的程序员要胜过十个普通的程序员。这种优秀，源自天赋、努力工作，更源自想要了解一切的学习精神。4 卷首语 所以在前二十年里，我每天基本上就是学习计算机、学习硬件、学习如何高效编程，学习怎么让计算机发挥出一切性能。有了这样的底子，我才能真正开始做自己的事。转管理，不是程序员的尽头 InfoQ：从MySQL到MariaDB，您已经证明了自己是位成功的企业家。但不是所有技术人员都能成长为管理者，在这方面您能不能分享一点经验？Monty：我觉得大多数开发人员就适合当开发者。我知道，一直都有些开发者屈服于现实，转而去做管理岗。但根据我的观察，他们大多数人的编程才能其实比管理才能要强得多。很多人就是为了钱
7、，管理岗的收入应该是比开发者要高一些。但我觉得他们的天赋主要还是体现在开发上，最好能坚持下去，依靠自己的才能走向成功。InfoQ：您在34岁，也就是快接近中年时才开发出MySQL。但在中国市场，35岁以上的开发者往往会考虑转向管理岗。您怎么看待这种现象？Monty：我认为不应该这样。因为好程序员，特别是优秀的程序员其实更难找。虽然管理岗的薪水可能稍高一点，但却很容易被取代。所以只要大家有天赋，最好能坚持在技术的道路上走下去。至于MySQL这边，其实我从来不想当CEO。我想做的是CTO，负责技术方面的工作，毕竟我的天赋就在技术上。我觉得自己没有那份成为优秀全职管理者的天分。我把一生都投入到写代码
8、上，我喜欢这活儿，也正是编程让我成为了独一无二的人。InfoQ：如您所说，转到管理岗后，就会得到更多资源，比如晋升机会更大、薪酬更高。相比于技术理想，这是很现实的考量，毕竟大部分人要养家糊口，您怎么看呢？Monty：我觉得很多企业在职业设计上都有这种错误。所以在MySQL和MariaDB，我觉得与其靠让大家做管理来提升薪水，不如让他们承担起更多责任。有时候，职位的重要性比单纯的高薪水更有吸引力。这可以算是另一种思路吧。5 InfoQ 架构师2022年11月 大家当然应该为自己的编程事业规划一条职业发展道路，但没必要把转管理岗当成唯一的方向。企业不需要那么多经理，而且在开始裁员的时候，管理岗都是
9、最先倒霉的。毕竟经理人很容易替代，但优秀的程序员不可替代。他们掌握着企业最需要的代码知识，所以只要代码在，那岗位就在。编程40年，如何保持技术前瞻性？InfoQ：您的编程经历大概有四十年了。在这么长的从业过程中，您是怎么保持自己的技术前瞻性的？Monty：我的办法是信任客户。我的想法一直很坚定，那就是跟客户合作、解决问题，了解他们未来可能遇上的新问题，再共同将其克服。所以只要有了良好而且足够广泛的用户群体，比如MySQL和MariaDB建立起的客户基础，那他们就能告诉我，未来会走向哪里。我在等待未来的到来，同时也成为造就未来的一部分。所以，认真倾听客户意见，与他们合作，自然就能了解最新的技术。
10、跟客户距离越近，我们就越了解功能需求，并据此安排自己的工作。对于开发者，我们要做的是为他们提供正确的技术、让他们满意。总之，只要明确了需要解决的问题，技术选型自然就会容易得多。InfoQ：那您会常跟社区中的开发者讨论技术问题吗？Monty：我经常参与技术会议，在那里跟与会者们交流。这也算是一种探讨吧。另外，在接触世界各国的客户，比如中国的客户时，也可以跟内部员工讨论关于MySQL和MariaDB的问题。他们代表的就不是客户，而是社区成员。所以我会认真倾听。InfoQ：对于想要学习MariaDB或MySQL的中国开发者，您有什么建议吗？Monty：首先应该积极参与到社区当中，帮助他人、改进实现。
11、如果你需要某项功能，就想办法着手开发，并随时向MariaDB#基金会寻求帮助。我们可以帮助大家，告诉你具体该怎么做。你审查过自己的代码吗？你也可以参与审查其他贡献者的代码，这就 6 卷首语 是实实在在的开源贡献。而要想成为一名出色的程序员，拥有一份能做一辈子的开发工作，那最好能让自己积累起名望，让自己在开源世界拥有一席之地。有了这些积累，就不是你找工作，而是工作来找你了。保持住好奇心，积极探索事情是如何运作的，这样我们就会变得更好，对企业的价值也越大。本文节选自本文节选自InfoQ专访“专访“MySQL之父”：我曾创造之父”：我曾创造MySQL，也将颠覆，也将颠覆MySQL 7 InfoQ 架
12、构师2022年11月 DevOpsDevOps已死，平台工程才是未来已死，平台工程才是未来 开发者不想做运维，对DevOps来说不是好事情。最近，Scott Carey发表了一篇调查文章，喊出了一些开发者的心声：“扯淡的DevOps，我们开发者根本不想做运维！”除此之外，软件工程师兼DevOps评论员Sid Palas也在推特上写道，“DevOps已死，平台工程才是未来。”作者 Tina 平川 8 热点|Hot 他的核心观点是：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。Honeycomb的首席技术官Charity Ma
13、jors对此也有同样的观点，她认为在软件演进过程中，我们将运维技能从开发技能中剥离出来，形成了两个不同的职业，但结果证明这是一个巨大的错误。因此DevOps出现了，我们用它来重新统一开发和运维。然而开发周期应该是一个企业中最稀缺的资源，所以应该将尽可能多的资源花在核心产品上。Majors认为，在过去，有的工程师写代码，有的工程师跑代码。而现在，工程师不仅编写代码，还要运行他们编写的代码。这导致软件工程师觉得他们必须对所有事情都了如指掌，大大增加了“认知负担”。这迫使许多团队重新在自动化带来的自由与认知负担之间进行权衡。平台工程也因此越来越受关注和热议。PlatformCon是第一个面向平台工程
14、师的会议，一出现就吸引了 9 InfoQ 架构师2022年11月 超过6,000名与会者。Gartner也在其2022年8月发布的软件工程炒作周期中添加了“平台工程”（图中第四个小圆点）。什么是平台工程？按照“平台工程”社区主要贡献者和Humanitec的产品负责人Luca Galante的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（Internal Developer Platform）”，可以涵盖应用程序整个生命周期的所有操作需求。内部开发平台（以下简称IDP）是位于
15、工程团队已有技术和工具之上的一层。它帮助操作人员进行系统性设置，并为开发人员提供自助服务。平台工程做好了，就好比是为个体开发人员铺就了金光大道，他们可以从IDP层获得合意的抽象等级。从DevOps余烬中崛起 DevOps和云原生的概念兴起之后，似乎是在突然之间，工程师们不得不掌握10种不同的工具、Helm图表、Terraform模块等，仅仅是为了在多集群微服务设置中的多个环境中部署和测试一个简单的代码更改。问题是，在整个工具链的演进过程中，这个行业似乎认为，在全球经济的几乎其他所有领域都被证明有效的劳动分工（Ops和Dev）并不是一个好主意。相反，DevOps范式备受推崇，被视为实现高效设置的
16、方式。10 热点|Hot 开发人员应该能够端到端地部署和运行他们的应用。“谁构建，谁运行”，这才是真正的DevOps。这种方法的问题是，对于大多数公司而言，这实际上并不现实。虽然对于像谷歌、亚马逊、Airbnb这些比较先进的组织来说，上述方法很有效，但对于其他大多数团队而言，要在实践中复制真正的DevOps并不简单。最主要的原因是，大多数公司都没有像他们那样的人才库，也不会仅仅为了优化开发工作流和体验而做他们那样的资源投入。与此相反，当一个普通的工程组织试图实施真正的DevOps时，往往会出现一系列的反模式。我们通过一个例子来看下，当组织决定实施DevOps并取消正式的Ops角色或团队时，许多
17、开发团队中出现了什么情况。开发人员（通常是比较资深的）最终承担起了管理环境、基础设施等的职责。这就导致了这样一种情况：“影子操作”由那些在编码和产品开发方面才能体现出最大价值的工程师来执行。没有赢家。高级工程师现在要负责设置，并需要处理比较初级的同事的请求。在组织层面，其最昂贵和最有才华的资源现在正在被滥用，他们无法再以同样的速度和可靠性来交付功能了。这类反模式已经为许多研究所证明，比如Puppet的DevOps现状报告或是最近Humanitec的基准测试研究。后面这份报告根据标准的DevOps指标（准备时间、部署频率、MTTR等），对表现最好和最差的组织进行了分组。如下图所示，44%的低效组
18、织存在着上述反模式，有些开发人员要自己完成DevOps任务，并帮助经验不足的同事。与此相比，表现最好的组织全部成功实施了真正的“谁构建，谁运行”方法。11 InfoQ 架构师2022年11月 那么，低效组织和高效组织之间的关键区别是什么？最好的团队是如何确保他们的开发人员能够运行自己的应用程序和服务，而不需要借助资深同事的不断帮助？你猜对了，他们有一个搭建内部开发平台的平台团队。Puppet的2020年DevOps现状报告清楚地说明了内部平台的使用与组织DevOps演进程度之间的相关性。最好的工程组织就是这样做的。他们成立了内部平台团队，负责构建IDP。在使用这些IDP时，开发者可以根据自己的
19、喜好选择合适的抽象级别来运行他们的应用和服务。例如，他们喜欢摆弄Helm图表、YAML文件和Terraform模块吗？很好，他们可以这么做。他们是不关心应用是否在EKS上运行的新手吗？没问题，他们可以通过自助服务为自己提供一个环境，这个环境包含了他们部署和测试代码所需的一切，而且不用管它在哪里运行。12 热点|Hot 铺就金光大道 这里所说的铺就金光大道是什么意思呢？让我们具体看下。如今，大多数CI/CD设置的重点都只是简单地更新镜像。CI构建它们，更新配置中的镜像路径，完成。这覆盖了大多数部署用例。但是，当我们需要做一些基本工作流程之外的事情时，情况就开始变得更加复杂和耗时，例如：增加环境变
20、量和修改配置 添加服务和依赖项 回滚和调试 启动一个新环境 重构 添加/修改资源 强制使用RBAC 这样的例子不胜枚举。平台工程就是为所有这些需求铺好路。平台工程师提供粘合剂，将所有这些操作都绑定到一个一致的自助服务体验中，而不是让每个人什么操而不是让每个人什么操作都作都做，而且还必须了解整个工具链才能做到做，而且还必须了解整个工具链才能做到。这种粘合剂就是内部平台。用Evan Bottcher（https:/ 许多组织开始意识到内部开发平台和开发者自助服务所带来的好处。按照Puppet2021年DevOps现状报告的说法，“平台团队的存在并不一定会解锁更高层次的DevOps；不过，优秀的平台
21、团队会扩大DevOps方案的好处。”13 InfoQ 架构师2022年11月 然而，招聘合适的人才来构建这样的平台和工作流程并不简单。更麻烦的是，要确保他们始终如一地向工程组织的其他部门提供可靠的产品，并将对方的反馈纳入IDP。以下是一些有用的原则，成功的平台团队和自助服务驱动的组织都是以此为主线。明确使命和角色 要明确平台团队的任务。例如，“构建可靠的工作流，使工程师们能够独立地操作设置，并针对他们运行应用程序和服务所需的基础设施提供自助服务。”无论对你的团队来说哪块最重要，都要确保一开始就把这个定义好。为平台团队赋予一个明确的角色也极其重要，不应该将平台团队视为另一个按需提供环境的服务台，
22、而应该将其视为一个专门为内部客户服务的产品团队。将平台作为产品来对待 关于聚焦产品，我们再展开说明下。平台团队需要秉持产品思维，以内部客户也就是应用开发者的反馈为基础，专注于能够真正为他们提供价值的东西。要保证平台团队基于这个反馈循环来交付功能，而不被刚刚出现的新技术所吸引。聚焦常见问题 对于内部其他团队共有的问题，平台团队要防止他们处理这些问题时重复发明轮子。找出这些常见问题的关键是：首先要了解导致开发进度放缓的开发痛点和阻力。这些信息既可以是通过开发人员反馈收集的定性信息，也可以通过查看工程KPI收集的定量信息。粘合剂很有价值 通常，平台团队会被视为纯粹的成本中心，因为他们不为最终用户提供
23、任何实际的产品功能。他们只是把我们的系统粘合在一起而已。这样的观点非常危险，当然，这种粘合剂非常有价值。平台工程师需要在内部肯定和宣传自己以及自己的价值主张。一旦你们为其他团队设计并铺就了金光大道，那么作为一个平台团队，你们所创造的主要价值是将工具链整合在一起，为工程师们提供顺畅的自助服务工作流。14 热点|Hot 不要重复发明轮子 同样，平台团队应该防止组织内的其他团队重复发明轮子，为同样的问题寻找新的创造性解决方案，他们自己也应该避免犯这样的错误。不管你自己开发的CI/CD解决方案多么优秀，商业供应商最终都会迎头赶上。平台团队应该经常问自己有什么不同之处。与其构建内部的CI系统或指标仪表板
24、，并与能力强20或50倍的企业竞争，还不如专注于组织的特定需求，并根据这些需求定制现成的解决方案。无论如何，商业竞争对手更多的是针对行业中比较通用的需求进行优化。现代工程组织 根据Puppet的2021年DevOps现状报告，“高度发展的组织往往会遵循Team To-pologies模式”。Matthew Skelton和Manuel Pais合著的Team Topologies一书于2019年出版，在成功的工程组织中，成为最具影响力的现代团队设置蓝图之一。根据他们描绘的蓝图，团队应该围绕四种基本拓扑结构来设置。15 InfoQ 架构师2022年11月 业务导向团队：与业务领域某个部分的工作流
25、相匹配，处理核心业务逻辑。赋能团队：帮助业务导向团队克服障碍并检测缺失的功能。复杂子系统团队：在严重依赖数学/技术方面的专业知识时组建。平台团队：提供一个令人信服的内部平台，提高业务导向团队的交付速度。如上图所示，平台团队与其他所有团队都是平行的，旨在确保从编码到生产的自助工作流的流畅运转。什么时候应该考虑平台工程？什么时候应该考虑平台工程？一个常见的误解是，平台工程只在大型团队中才有意义。如果你的团队只有5名开发人员，那么平台团队和IDP肯定是多余的，可一旦你的组织发展到超过20-30名开发人员，可能就应该考虑内部开发平台了，而且越早越好。Luca Galante对此强调道，“我听过无数团队
26、的故事，他们构建IDP的时间太滞后了，并因此承受了许多本不必承受的痛苦，例如，唯一一名负责DevOps的员工休假，整个组织几周都不能部署。IDP和招聘平台工程师可能是你今天就要考虑的投资和招聘平台工程师可能是你今天就要考虑的投资。”参考链接参考链接 https:/ https:/platformengineering.org/blog/what-is-platform-engineering 16 热点|Hot 上云“被坑”十年终放弃，寒冬里第一轮“下上云“被坑”十年终放弃，寒冬里第一轮“下云潮”要来了？云潮”要来了？Basecamp是37signals旗下一款流行的基于云服务的项目管理软件，
27、其用户囊括了来自五大洲的166个国家的超75,000个组织。Basecamp的上云历程已经超过十年，而且其前两年发布的产品HEY也一直在云端运行。不过近日，Basecamp&HEY联合创始人David Heinemeier Hansson发文表示将要“下云”。“我们用过亚马逊云科技、也用过谷歌云，试过裸虚拟机、也体验了Kubernetes容器编排。我们知道云能提供哪些功能，其中大部分都有实际应用。现在我们终于得出结论：对于像我们这样一家增长稳定的中型企业来说，租赁基础设施资源总体上看是笔糟糕的买卖。云服务商做出的降低复杂性、控制运营成本等承诺从来就没能实现，所以我作者 褚杏娟 核子可乐 17
28、InfoQ 架构师2022年11月 们正在筹划脱离云端、重归本地。”“从未适用于Basecamp”高昂的云成本“云计算在两种极端情况下确实大有裨益，但只有其中一种跟我们有关。”Hansson解释道，首先是应用程序极其简单且流量很低的情况，这时选择完全托管服务确实能摆脱大部分复杂性要素。Heroku就是这样起步的，同是PaaS提供商的Render则证明这条路完全行得通。从零客户到少部分客户，云基础设施既是个良好的起点，也能在一段时期内帮助企业稳稳前行。但随着使用量的增加，账单也会水涨船高，并最终来到某个必须做出改变的时间节点。另一种就是负载波动几乎毫无规律可言。具体来讲，负载运行期间经常出现剧烈
29、震荡或者高耸的峰值，但基准资源需求却只相当于峰值的一小部分。面对这种情况，大家确实不知道该部署10台服务器、还是100台服务器。于是乎，上云就是最好的选择。“我们在发布HEY的时候也属于这种情况。当时，突然有30万用户挤在三周之内注册试用我们的服务，这一规模远远大于我们预测的6个月3万用户。”Hansson说道。但Hansson表示，“这两种情况都不再适用于今天的我们，也从未适用于Basecamp。所以如果继续坚持在云端运行，我们相当于既用不上云服务的亮点，又要承担几乎荒谬的夸张溢价。这就像明明住得离地震带很远，却要花四分之一的房屋总价买保险一样。如果真能遇上大灾害，那这钱花得确实有道理。可问
30、题是并没有，这完全是在浪费资源。”Hansson以HEY为例解释道，公司每年需要为亚马逊的数据库（RDS）和搜索（ES）服务支付超50万美元。“确实，在为成千上万客户处理电子邮件时，肯定得分析和存储大量数据。但结合价格来看，这样的状态还是让我觉得很荒谬。大家知道每年50万美元预算能买到多少台功能强大的服务器吗？”18 热点|Hot “按需计算“并没有更先进“那样你就得自己管理服务器了。云服务多简单，省下的可都是劳动力成本！”面对可能到来的质疑，Hansson先发制人：这么说的人肯定没尝试过在云端运行HEY或者Basecamp这类大规模服务。有些环节确实更简单，但有些环节反而更复杂。而且总体来讲
31、，我还没听说过像我们这种体量的组织能单靠上云，就大幅削减自己的运营团队和日常开销。作为经营者，Hansson表示“云厂商的营销手段确实高明”。讨论的另一方总有话说，比如“你至少不用自己打理那么多基础设施设备”或者“基础设施服务构成你的核心竞争力”之类。面对这些直击灵魂的发问，云似乎再次闪耀起夺目的光芒，让每个考虑运行自有服务器的决策者都像是活在上个时代的老顽固。但Hansson也指出，与此同时，亚马逊凭借租赁服务器赚取着惊人的利润。尽管一直在做容量和服务升级，但AWS的利润率仍然接近30%（总营收62.2亿美元，利润为18.5亿美元）。而且随着该公司表示“计划在未来将服务器的使用寿命由四年延长
32、至五年，并将网络设备的使用寿命由五年延长至六年”，利润比例势必还会进一步上升。“我对亚马逊靠云业务赚钱没有意见，毕竟租计算设备本来就不便宜。只是云服务总喜欢搞一大堆专业术语，比如按需计算，听起来很酷，感觉比租计算机整整领先了一个世纪。但二者好像并没什么本质区别。”Hansson进一步指出，“而且这不只是成本问题，更关乎我们未来要如何运营整个互联网。令人震惊的是，云计算这一堪称人类社会奇观的产物，居然只能运行在少数几家巨头厂商的基础设施当中。如果AWS的某个主区域出现故障，似乎会有近半数网站随之离线。DARPA当初规划互联网的时候，恐怕也想不到会有这样的结果。”基于以上原因，37signals觉
33、得有必要带来点不一样的声音。Hansson表示，Basecamp多年的商业模式跟自有硬件都能良好协同，业务的增长轨迹也有很好的可预测性。而且即使是用了亚马逊或者谷歌云，也还是得设置专业员工才能操作服务商那边的设备。“相信不只我们，还有很多企业都面临着类似的情况。”“而要想让互联网回归那片成本更低、去中心化度更高的净土之前，我们先得学会 19 InfoQ 架构师2022年11月 从云服务商的那套营销话术中脱离出来。在云计算普及之前，大家都在运行自有服务器，其实连不少号称云优势的功能也完全可以用在本地设施当中。所以千万别被云宣传蒙蔽了双眼，运行自有设施其实没那么可怕。当初我们就是这样一步步走了，才
34、有了如今繁荣兴盛的互联网时代。”Hansson说道。Hansson的决定也引发了开发者们的讨论。其中“降低复杂性、控制运营成本等承诺从来就没实现”这一点也戳中了开发者们敏感的神经。“仪表板是一个迷宫，许多非常常见的用例都要求您协调部署多个名称奇怪的产品。当云计算在10多年前刚出现时，复杂性是可以被原谅的，但从那时起，确实并没有变得更容易使用。”Reddit账户名为“50653”的开发者道对某云产品吐槽道，“我不会推荐裸机服务器，但我认为中小型公司应该考虑这个云产品的替代品，其中大多数都更容易使用。”开发者“mwassler”对此表示赞同。“我认为我对这个产品相当了解，有时我用它帮助我所在地区的
35、小公司，我无法告诉你我经常进入某人的仪表盘，他们每个月花费数千美元来托管一些每天收到几千个请求的服务拥有开发公司的人将他们的登录信息提供给没有经验的开发者，让他们去做任何想做的事情，然后他们进入那里就变得疯狂。我见过有人多年来运行默认大小的实例，但这些实例没有提供流量，某些开发人员只是在某天准备了一些。”还有开发者评论道，“IT一直存在集中化（入站）和分发（出站）的循环。服务提供商怎么会每510年卖给你同样的东西呢。”没有“下云”成功的GitLab 实际上，Basecamp并非第一家想要“下云”的企业。GitLab在2016年底时候就表示计划要“下云”，不过团队“在收到数百条充满建议和警告的评
36、论和邮件后，最后还是决定将GitL保留在云端。GitLab对存储需求较高，因此当时建了一个CephFS集群来解决NFS的容量和性能问题。但在将大量项目、用户和CI工件加载到CephFS上运行一段时间后，GitLab发现，CephFS为了正常运行需要非常快速地读写很多东西，因此其对底层基础设施的性能有非常高的 20 热点|Hot 要求。如果其中一台主机延迟写入日志，则队列的其余部分将单独等待该操作，整个文件系统将被阻塞。另一方面，CephFS还遵从CAP定理，因此会放弃可用性以换取一致性。如果对系统施加很大压力，那么它会产生热点。例如高负载时，在托管GitLab CE存储库的机器集群中，所有读取
37、和写入最终会间出现在同一个位置。GitLab认为，由于GitLab将系统托管在没有IO延迟最低SLA的云上，这个问题被放大了。GitLab当时的OSD日志延迟 GitLab这一计划发出来后也引发了社区的热烈讨论，大家纷纷就GitLab面临的问题进行了探讨，GitLab首席执行官Sid Sijbrandij也认真听取了社区的意见。Sid还与一位将多家公司从云端带到裸机领域的人士进行了长谈，他得到的建议是：除非绝对需要，否则不要这么做，即使是将自定义为提供托管服务的公司也不应该这样做。正确处理硬件需要的专业知识庞大、昂贵且难以获得，这意味着要雇佣服务器、网络、备份、安全、电力等方面的专家。“这与我
38、们董事会成员看到的其他公司情况相似，上述工作花费了他们70%的工程量。对我们来说，首要任务是制作一个大多数人自己托管的出色工具。我们不能让托管主导我们的组织。”Sid表示。最后，GitLab决定将所有存储分散到多个NFS分片（NFS shard），并删除了堆栈中的CephFS，同时创建了Gitaly，这样就不必依赖NFS实现横向扩展，并可以通过缓存来加速Git访问。21 InfoQ 架构师2022年11月 结束语 在过去的五年中，云计算行业蓬勃发展，加上很多企业在疫情之初开始进行数字化转型，云计算更是“风生水起”。但由于市场动荡、对潜在经济衰退的担忧，企业承担着越来越大的财务和运营压力。据悉，
39、苹果公司每月花在亚马逊云计算上的费用就超过了3000万美元。因此，在人人都讲降本增效的今天，高昂的云计算成本能否带来同样高的回报也成为企业重要的考量。但现实可能是，云计算可能并未给大多数企业带来想象中的收益。Wanclouds研究显示，81%的IT管理者表示，随着成本飙升和市场下行，他们的最高管理层已经指示他们要减少或不承担额外的云支出。根据调研结果，39%的人已经决定将大量的云消耗和高性能工作负载迁移或留在本地，还有29%的人表示在2022年上半年由于价格贵而更换了公有云厂商。未来，各种各样的压力是否会逼迫企业开始纷纷“下云”？我们对此也将持续关注。参考链接参考链接 https:/ http
40、s:/ 22 热点|Hot 那位用那位用RustRust重写数据库的创始人来复盘了：删重写数据库的创始人来复盘了：删除除2727万行万行C+C+代码，值吗？代码，值吗？前段时间，数据库初创企业RisingWave Labs曾经发表了一篇博客文章，宣布完全删除掉了RisingWave（该公司开发的云原生流式数据库）的27万行C+代码库，并用Rust语言从头开始重写了一遍系统。本文，我们采访到了该公司的创始人&CEO吴英骏博士，详细探讨了重写前中后期的准备、遇到的问题以及经验复盘。放弃Rust，初抉择是C+InfoQ：选择哪种编程语言和：选择哪种编程语言和RisingWave的特性有关系吗？的特性
41、有关系吗？吴英骏吴英骏：RisingWave是一款云原生流式数据库，主要服务于需要超低延迟实时数据作者 赵钰莹 23 InfoQ 架构师2022年11月 分析应用。其定位不仅是一个SQL数据库系统，还提供流处理能力：使用流数据执行连续查询，并以物化视图的形式动态维护结果。另外，采用分层架构，建立在现代云基础架构之上，利用云资源为用户提供对成本和性能的细粒度控制。这个架构最大的特点在于资源是无限的，既然有无限资源，性能并不是特别大的问题，只要加资源，性能就会更好，但是资源是收费的，设备是收费的，我们希望能够在保证用户性能的前提下让整个系统更加便宜，让普通用户以一种比较低的价格使用，这是我们的核心
42、设计理念。这与编程语言的选择没有太大关系，开发一款数据库可以用各种各样的语言，比如C+、Rust、Java，Scala等，一些交易系统相关的可能还会考虑Haskell，但即便是在20年之前的数据库，也鲜少有人使用Java、Basic、Python这类语言，主要是因为这些语言的运行效率和性能均不高。我们主要希望选择一门高性能的编程语言，所谓的高性能基本上是C+、Rust或者一些小众的语言，如果希望可以被用户广泛接受，基本是C+和Rust。InfoQ：从之前披露的：从之前披露的文章中可以看到团队最初选择的是文章中可以看到团队最初选择的是C+语言来构建，并集结语言来构建，并集结了多位具有了多位具有1
43、0年以上经验的年以上经验的C+工程师，当时是看中了工程师，当时是看中了C+的哪些特质还只是遵循市面的哪些特质还只是遵循市面上大部分数据库系统的选择？上大部分数据库系统的选择？吴英骏吴英骏：我本人比较擅长C+，不管是读博期间还是创业之前做的所有数据库都是用C+写的，没有用过其他任何语言写过任何项目。创业之初，有人给我们提过可以用Rust写，理由是用Rust写容易火。在我看来，这不可以算作理由，我们又不是想要成为网红，选择一门语言肯定不是单纯为了火，我们需要考虑团队适合用、会用的语言以及数据库领域的通用语言是什么。在数据库领域，虽然TiDB的存储引擎TiKV是用Rust写的，但这不足以证明成功的数
44、据库系统都是用Rust写的，反而绝大多数成功的数据库系统都是用C+写的。从招聘的角度考虑，我们肯定希望招到的都是数据库领域的专家，在数据库领域有多年经验的专家很可能来源于现有的各大数据库厂商，而这些厂商基本都是用C+的。相较而言，Rust是一门比较年轻的语言，缺少比较重量级的项目，尽管这个语言是 24 热点|Hot 被实战过的，也有一些相对流行的项目，但还算不上重量级的巨无霸项目，还有一些项目主要是币圈在用，生态上或多或少是有不足的。综上，我们最终决定选择用C+作为主要开发语言。再抉择用Rust重写 InfoQ：团队已经在这件事情上投入了：团队已经在这件事情上投入了7个多月，您也提到对初创企业
45、而言时间是非个多月，您也提到对初创企业而言时间是非常宝贵的，是哪个点常宝贵的，是哪个点/事件让团队觉得不重写不行了？事件让团队觉得不重写不行了？吴英骏吴英骏：首先，C+比较经典的问题是内存泄漏，但这类Bug比较容易修，我们觉得可以忍。其次，依赖管理很痛苦，虽然CMake工具可以自动配置C+项目的编译，但使用起来还是很麻烦的，仍然需要手动配置和安装依赖库；STL库缺乏对一些现代编程工具的支持，依赖的社区项目大多数还都缺乏长期支持；最后，我们招聘进来的成员C+水平参差不弃，每个人都有自己的风格，非常难统一，代码看起来比较累，审查代码令人生畏。随着越来越多人员的加入，C+的问题暴露得越来越频繁。这段
46、时间，频繁有工程师提出是不是可以考虑使用Rust重写。另外，流式数据库通常用于对延迟非常敏感的关键任务。因此只能使用以下语言构建RisingWave：保证零成本抽象，不会有性能上限；不需要运行时垃圾收集，可以控制可能由内存管理引起的延迟峰值。起初，我们是不愿意更换语言的，毕竟已经写了这么久。最后，我们表示如果支持用Rust重写的工程师可以对一个独立的模块改写成功，我们就考虑整体重写。与此同时，我也想起之前在AWS Redshift工作中遇到的一个Bug，三个人不断调试了两周都无解，最终发现是内存泄漏的问题，如果现在的项目继续下去很可能会遇到类似的情景，假设那时的产品已经有了很多用户，我们还需要
47、因为这种内存泄露的问题调试许久，得不偿失。也是这个时候，我们开始认真考虑是否用Rust重写。经过慎重评估，原来七个月写的代码用Rust重写需要花费大约两个月的时间，前后的时间差主要体现在项目的逻辑框架前期已经梳理清楚，正值暑假，公司内部纳入大量实习生，人手比较充足，且很多实习生天然有Rust的基础，这些都提升了重写的速度。最后经过全公司的表决投票，我们开始重写。25 InfoQ 架构师2022年11月 在替换过程中，我们选择逐个模块替代，这也保证了整个过程不会出现很严重的问题。InfoQ：C+代码风格不统一的问题代码风格不统一的问题，用用Rust重写重写以后以后就不存在这个问题了吗？就不存在这
48、个问题了吗？吴英骏吴英骏：风格不统一的问题肯定不是使用Rust就能解决的，但相对C+会有很大程度的改善，C+中一些指针等的写法很难统一，还容易造成安全性的问题，工程师在阅读其他人的代码时如果对全局系统不够了解很容易出现误读，从而造成系统出错。InfoQ：C+一些语言层面的缺陷由来已久，您将一些语言层面的缺陷由来已久，您将C+语言作为主要的开发语言，语言作为主要的开发语言，之前没有遇到过上述问题吗？之前没有遇到过上述问题吗？吴英骏吴英骏：我之前也遇到过，但上学期间，Rust没有现在完善，使用者很少，因此也不会考虑到使用Rust去开发数据库。此外，我之前接触的数据库是比较成熟的产品，比如IBM D
49、B2，大部分时间都在调试，很难有精力和时间去把这么一个诞生了几十年的数据库进行重写，但创业是不一样的，尤其是早期起步阶段。在大型企业内部，重写某个项目大概率项目本身并不是那么重要，或者没有很多用户，否则需要投入大量的精力和资源。对起步阶段的创业公司来说，还是有机会重写的，一旦面对客户交付的压力，重写是不太可能。InfoQ：重写之前的系统已经完成了多少？：重写之前的系统已经完成了多少？吴英骏吴英骏：简单来说，框架是比较清晰的水平。重写不至于发现之前的Bug，但的确会通过这个过程重写考量各个部分设计的合理性。Rust的爽点 InfoQ：Rust比较爽的特性是什么？比较爽的特性是什么？吴英骏吴英骏：
50、首先，安全性肯定是让我们觉得是比较爽的，这对数据库项目非常重要。其次，包管理非常少，C+有非常多的库，包管理非常复杂，可能需要花费几个小时去想如何在CMake里面配置一个包管理工具，甚至是在花费了很多时间之后，我们发现装不上去，还可能会遇到重名的问题（其他项目中使用的变量名称可能和我们使用的库中的名字重合了），这些问题都需要手动解决，而且改起来费时费力。26 热点|Hot 重写收益比 InfoQ：重写前后的收益情况如何？：重写前后的收益情况如何？吴英骏吴英骏：总结来讲，这件事情的收获非常大。从收益比的角度看，我们损失的是时间，因为分段重写大概花费了一个月左右，但这些时间并没有浪费掉，这个过程让