架构师（2023 年 3 月）
CONTENTS/目录 热点|Hot 15年做不好的代码搜索，基于Rust重写引擎终于搞定：GitHub声称能从此“改变游戏规则” 新必应整合ChatGPT，微软：“搜索引擎技术大战，始于今日” 没有NGINX和OpenResty的未来：Cloudflare工程师正花费大量时间用Rust重构现有功能 访谈文章|Interview 七年前选择用Go和Rust做数据库的创业公司，如今怎么评价这个决定？ Log4Shell一年之后，为什么你还应该信任开源软件安全？ 案例研究|CaseStudy 从ClickHouse到ApacheDoris，腾讯音乐内容库数据平台架构演进实践经历亿级话单处理优化打磨检验，江苏移动云流一体化到底如何玩转eBay为何以及如何转向OpenTelemetry 推荐文章|Article 入行14年，我还是觉得编程很难微服务进入深水区后该何去何从 被逼出来的自主可控，从华为自研看国产IDE的未来和商业模式从安全视角看，革命性的eBPF是“天使”还是“恶魔”？ 从谷歌最好的程序员JeffDean：我用过18种编程语言 II 架构师 2023年03月刊 本期主编Tina 流程编辑丁晓昀发行人霍泰稳 反馈feedback@geekbang.com 商务合作hezuo@geekbang.org 内容合作editors@geekbang.com 特别专题|QCon2022热门演讲实录 代码快照x覆盖率：洞察研发体系的最后100米百万级代码工业软件的云端综合实战 OPPO全球混合云建设之路 向云原生要数据：日均万亿级数据安全保障和小时级风险应对实践 从ETL走向EtLT架构，下一代数据集成平台ApacheSeaTunnel核心设计思路解析国内首例社区双栈Istio方案落地经验，实现代码已开源 特别专栏|视频推荐 本月，这些视频值得一看！ 卷首语 从微服务过去十年发展中，我们能学到什么？ 作者：Tina 根据Wiki的说法，在2011年的时候，一群聚会中的架构师不知道如何命名自己正在探索的架构风格，于是他们使用了“微服务”这个词。这种架构风格，在得到正式命名之前也被一些人称为细粒度SOA，即面向服务的架构，当时还存在着一些来自早期尝试者的负面反馈。但是没想到仅一年的时间，“微服务”这个词就开始因为技术演讲而流行了起来，变成了一个正式的名称。 这些早期实践者在宣传技术理念时，表示它可以使组织“走得更快”，从而快速交付业务价值，业界也开始达成一致，普遍认为它“显着提高了开发效率，使我们能够大胆思考并进行实质性的产品改进，并让工程团队能够安全地测试新技术。” 微服务就这么火了起来，迅速跨越“早期采用者鸿沟”成为了主流架构，一些早期参与者甚至觉得自己“创造了未来”。到了2018年左右的时候，InfoQ还发布了“微服务成熟度状况”调查报告，报告显示接受调查的从业者对微服务总体持有非常积极的态度，似乎微服务已经成为了架构领域的“银弹”。 实际上，FredGeorge，也有人称他为“微服务之父”（其研究和宣传都早于MartinFowler），在2016年就提出单靠微服务的实施不会给组织带来成功，必须识别和解决技术、流程和组织环境中阻碍业务敏捷性提高的因素。2020年，他还以“WhyIWouldn'tUseMicroServices”为题发表了一次演讲，强调不同的问题需要不同的解决方案，但他发出的声音没有足够引起大家重视。 当采用微服务的组织增多，微服务本身也越来越复杂，大家在实践中踩的“坑”也就多了起来。虽然一直有人总结经验教训，但阻止不了微服务的全面采用。直到GitHub前CTO喊出了那句震惊业界的话：“全面微服务是最大的架构错误！”回头去看，过去的这些经验告诉我们，如果你的组织交付软件的速度太慢，那么采用微服务可能不会解决这个问题，而且还有可能会使情况变得更糟。因为一开始人们认为微服务与服务规模有关，但它更多是要解决开发人员基数太大、代码的开发和发布周期太长的问题。 我们受益于微服务带来的很多好处，也需要承担架构复杂性带来的成本，这中间存在着取舍。但就像前Netflix云系统总监AdrianCockcroft所说的那样，架构可以复杂，也可以没那么复杂。可用的简单架构很多，选择适合自己的才最重要。这一切在于选择的人，因此不能全算是微服务的锅。 15年做不好的代码搜索，基于Rust重写引擎终于搞定：GitHub声称能从此“改变游戏规则” 作者Tina核子可乐 GitHub宣称，源代码搜索引擎将给业界带来颠覆性变革。 GitHub上可供搜索的代码浩如烟海，全球代码仓库已经超过2亿，并且这些代码不是静态的：它在不断变化，这就给代码搜索引擎带来了相当大的挑战。 上线15年来，GitHub一直努力给大家提供一个好用的代码搜索引擎，但一直不能如愿。这两年，GitHub用Rust从头开始构建了自己的搜索引擎，专门用于代码搜索领域，并且自发布后已经极大地改善了该平台的代码搜索能力。 GitHub从头构建代码搜索引擎的动机 搜索是工程师最常用的功能之一，谷歌内部曾对工程师做一次调研，发现平均每位工程师每天会进行5.3次代码搜索会话(session)，执行12个代码搜索请求。 对于GitHub这个用户已经达到一亿的代码托管平台来说，具备一个性能良好的搜索引擎尤其重要。然而GitHub自身的代码搜索引擎一度被用户吐槽“形同虚设”，连GitHub工程师TimothyClem自己都吐槽说“用户体验糟糕”。在这种情况下，一些开发者会使用额外的工具查找代码，比如https://grep.app/或https://sourcegraph.com/search。 实际上，GitHub在这十几年中一直在努力改进其搜索引擎，第一版搜索引擎通过将所有公共文档索引到Solr实例中来工作。对于公共存储库，当时看起来“一切都挺好”，但大型私有存储库仍然无法搜索。 到2010年，搜索领域出现了相当大的动荡，Solr作为一个子项目加入了Lucene，而 Elasticsearch作为一种在Lucene之上构建和扩展的好方法逐渐兴起。在2013年初，GitHub 推出了由Elasticsearch集群支持的全新代码搜索，整合了公共和私有存储库的搜索体验并更新了设计。 “当我们第一次部署Elasticsearch时，花了几个月的时间来索引GitHub上的所有代码，当时大约有800万个存储库，平均每秒能响应5个搜索请求。” 因为运营规模巨大，在发布后的几天或几周内，GitHub就马上经历了第一次代码搜索中断...... 再加上代码库的不断增加，“代码搜索是迄今为止我们运营的最大集群，自发布以来，它的规模又增长了20-40倍”，该公司发现现有技术的正常运行已经越来越难以维持，“从Solr到Elasticsearch，我们尝试用各种通用文本搜索产品来支持代码搜索，但效果都不好。除用户体验糟糕之外，托管成本还非常昂贵，而且索引速度也很慢。” 他们意识到，代码搜索与一般文本搜索有着很大的区别，毕竟代码是写给机器来理解的，需要利用代码之间的结构和相关性，并且还需要支持正则表达式进行搜索。 “归根结底，现成的东西都不能满足我们的需求，所以我们放弃了开源方案，从头开始构建了搜索引擎。” 基于Rust语言的搜索引擎 从2020年开始，GitHub开始全力以赴构建自定义搜索引擎。这款代码搜索引擎被命名为Blackbird，用Rust编写，它创建并增量维护一个由Gitblob对象ID分片的代码搜索索引。增量的形式能节省大量存储空间，并保证了跨分片的均匀负载分布。同时支持对文档内容进行正则表达式搜索，还可以捕获额外的元数据，例如它还维护符号定义的索引。最终Blackbird满足了大家的性能目标：速度非常快，索引也非常紧凑，重量约为（去重）语料库大小的1/3。 本周一，Clem发布了一篇博文，讲述了Blackbird的工作原理，深入探讨了这个可对四分之一代码仓库进行搜索的新技术。 Blackbird目前可对近4500万个GitHub代码仓库进行访问，涵盖的代码总体量达115TB、涉及155亿份文档。要在这么多行代码之间切换，单靠grep（类Unix系统上用于搜索 文本数据的常用命令行工具）显然是远远不够的。 Clem解释道，在8核英特尔CPU上，通过ripgrep对内存内的13GB文件执行详尽的正则表达式查询大约需要2.769秒，相当于0.6GB/秒/核心。 “我们很快意识到，面对GitHub所拥有的大量数据来说，用grep的办法根本行不通。代码搜索实际运行在每节点64核、总计32节点的集群之上。即使我们设法将115TB的代码全放进内存并实现了完美并行查询，那2048个CPU也要饱和运行96秒才能完成一次查询！在此期间，只有当前查询可以运行，其他操作全都得排队。” 每秒只能执行0.01次查询，这就直接给grep判了死刑。 于是，GitHub决定将大部分工作预加载至预先计算出的搜索索引当中，这些索引本质上属于键值对映射。如此一来，我们就能使用数字键（而非文本字符串）来搜索编程语言或单词序列等文档特征，从而大大降低对计算资源的需求。 尽管如此，这些索引还是太大、远远超出了内存容量。因此GitHub又为需要访问的各个索引构建了迭代器。根据Clem的介绍，这些迭代器会延迟返回经过排序的文档ID，而各ID所代表的正是关联文档的级别和满足的查询条件。 为了保持搜索索引的可管理性，GitHub采取分片方法——使用Git的内容可寻址哈希schema与增量编码将数据拆分成多个部分，借此存储数据差异（增量）以减少需要抓取的数据和元数据。考虑到GitHub上存放着大量冗余数据（例如不同fork），这套方案确实效果拔群，一举通过重复数据删除技术将115TB数据缩减至25TB。 最终系统的运行速度要远超grep，将最初可怜的每秒0.01次查询提升至每秒640次查询。此外，索引的执行速度可达到每秒约12万个文档，所以处理全部155亿个文档需要约36个小时。而由于增量（变更）索引减少了所需抓取的文档数量，重新索引只需要18个小时。 GitHubCodeSearch目前处于beta测试阶段，感兴趣的朋友可以点击此处前往体验 （https://github.com/features/code-search）。 参考链接 https://github.blog/2021-12-15-a-brief-history-of-code-search-at-githubhttps://www.theregister.com/2023/02/07/github_code_search/?td=rt-3ahttps://github.blog/2023-02-06-the-technology-behind-githubs-new-code-search/ 新必应整合ChatGPT，微软：“搜索引擎技术大战，始于今日” 作者褚杏娟核子可乐 IT届很久没有像这几天这样因为某个技术热闹了，ChatGPT则是那条将水搅浑的“鲶鱼”。 几乎在同一天，谷歌CEOSundarPichai先在官方博客上宣布推出谷歌下一代AI对话系统Bard，以此应对ChatGPT；百度紧接着宣布将推出类似ChatGPT的产品——文心一言 （英文名ERNIEBot）将在三月份完成内测，面向公众开放；不久后，微软公布了自家搜索引擎Bing最新版本，其采用的底层AI技术正是ChatGPT，同时微软还为Edge浏览器添加了新的AI增强功能，承诺带来前所未有的网络浏览与在线信息查找体验。 “搜索引擎的技术大战，始于今日。我们会继续前进并加快步伐。更重要的是，我 们希望能在搜索领域持续创新，如今时机已到。”微软CEOSatyaNadella说道，“这代表着搜索领域进入了全新的篇章。” 传统搜索引擎+ChatGPT 那么，“传统搜索引擎+ChatGPT”会发生
