架构师（2022 年 9 月）

架构师 2022年09月刊 本期主编Tina 流程编辑丁晓昀 反馈feedback@geekbang.com 商务合作hezuo@geekbang.org 发行人霍泰稳 内容合作editors@geekbang.com CONTENTS/目录 热点|Hot 是什么让Redis“气急败坏”回击：13年来，总有人想替Redis换套新架构 Oracle大规模裁员进行时：营收暴跌28%，数据库地位被侵蚀 理论派|Theory 过去的十五年，我们怎样做IM？ 在云时代，我们该如何看待新的开源许可证？ 推荐文章|Article 新浪微博从Kafka到Pulsar的演变 理想汽车：从Hadoop到云原生的演进与思考 大规模分布式架构中，怎样设计和选择API限流技术？ 观点|Opinion 为什么说DevOps治理是实现快速开发的关键 卷首语 成为架构师，你必须具备这五点能力 作者：AlanTai译者：冬雨策划：闫园园 对于软件架构师这个角色来说，对每一件事情都有经验至关重要。它让你知道什么时候该充当公司的桥梁，当放大或缩小架构图时该关注什么。当在不同的上下文中应用特定的架构设计时，您还将观察模式。在十多家公司工作过之后，我最终进入了Zuhlke咨询公司，在那里我不再需要换工作来获得不同的经验了。我的项目几乎涵盖了无数种行业，包括金融科技、保险科技、物流、制造业、奢侈品时尚、初创企业，这份列表还在不断增长。 领域知识 对某些业务领域的深入了解对于软件架构师的成功是至关重要的，因为您不仅要知道它是什么，还要知道它将是什么，或者可能是什么，以及为什么。客户经常找到软件架构师，要求向他们展示行业领导者正在做什么以及如何做。领域知识还可以帮助软件架构师说一种商业通用的语言，这反过来帮助他们成为连接管理和开发团队桥梁。 人际交往能力 软件架构师也是一个伟大的沟通者。许多优秀的高级软件工程师发现很难晋升为软件架构师，因为他们没有展示自己的技能，如倾听、口头和书面沟通、推进、冲突管理、 演示、谈判和说服。 这份工作所需技能的具体类型取决于你工作的特定公司环境。 在我的公司，我有机会在安全的环境中练习这些技能，比如我们称之为“祖尔克日”和“祖尔克营”的环境。我的雇主也在这些方面为我提供了正式的培训。最后，公司的建设性反馈文化支撑着许多人成长了起来。 专业技术能力 单独任何一张大学文凭都无法证明你是一个软件架构师。你需要学习软件工程的所有领域，包括软件设计、编码、质量保证、DevOps、性能分析、软件安全、项目管理、软件支持等等。这些技能对于创建满足软件架构“能力”的解决方案至关重要。当与开发团队中的专家交流时，软件架构师能够更好地理解相关信息，因为他们已经具备了这些领域的实践经验。 作为一名开发团队成员，我可以胜任各个领域的日常工作，包括后端、前端和DevOps。这让我能够以第一人称视角看到幕后发生了什么，并让我能够与团队保持较近的距离。 业务和开发过程 业务过程描述了一个组织的业务操作，并定义了业务需求，而这些业务需求通常没有清晰地表述为软件项目需求。软件架构师应该知道，或者至少应该知道向谁询问业务流程的相关信息。 一个向行业组织交付解决方案的软件架构师，需要干上几年时间才能成为领域专家，这种情况并不少见。 理解技术过程、软件开发生命周期和最佳实践的重要性与了解业务过程一样重要。这是因为软件架构师通常在确保业务和开发过程之间的一致性方面扮演着关键的角色，如此，才能做到迭代交付，才能有现实的项目计划。 领导力 现在，您应该非常好奇软件架构师如何掌握所有这些知识和技能了吧。好吧，我告诉你，他们并没有掌握！一个人是不可能掌握所有这些的。伟大的产品需要一个有能力的专家团队来开发。成功的软件架构师通常是有效的领导者，他们的团队中拥有伟大的成员，并使成员们成长得更加伟大，而不仅仅是个体。 软件架构师通常被视为团队的代表。他们在领导、管理业务和技术方面投入了大量的精力。虽然人们常常认为领导者只在站在前面指挥，但有时在一个项目中需要五种领导风格。我们公司提供的领导力培训就是这么教的。 你准备好成为一名软件架构师来寻求职业生涯的进一步发展了吗？现在是行动的最佳时机！ 关于作者 AlanTai是Zuhlke的首席软件架构师，Zuhlke是一家优质的全球咨询公司，为我们的业务伙伴提供高质量的解决方案。 原文链接 https://ayltai.medium.com/what-it-takes-to-become-a-software-architect-fa7788962c8c 是什么让Redis“气急败坏”回击：13年来，总有人想替Redis换套新架构 作者赵钰莹Tina 回击就代表输了？！ 今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 Dragonfly，用C/C++编写，基于BSL许可（BusinessSourceLicense）分发。 根据过往的基准测试结果来看，Dragonfly可能是世界上最快的内存存储系统，它提供了对Memcached和Redis协议的支持，但能够以更高的性能进行查询，运行时内存消耗也更少。与Redis相比，Dragonfly在典型工作负载下实现了25倍的性能提升；单个Dragonfly服务器每秒可以处理数百万个请求；在5GB存储测试中，Dragonfly所需的内存比Redis少30%。 作为一个开源软件，Dragonfly在短短两个月获得了9.2KGitHub星，177个fork分支。虽然这些年，涌现了不少类似的Redis兼容型内存数据存储系统，例如KeyDB、Skytable，但是都没能像这次这么“轰动”。毕竟Redis诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃历史包袱，更好地利用资源。 为回击新冒头的Dragonfly，Redis的联合创始人兼CTOYiftachShoolman和RedisLabs的首席架构师YossiGottlieb、RedisLabs的性能工程师FilipeOliveira联合发布了一篇名为《13年后，Redis是否需要新的架构》的文章。 在文章中，他们特地给出了自认更加公平的Redis7.0vs.Dragonfly基准测试结果：Re-dis的吞吐量比Dragonfly高18%-40%，以及一些有关Redis架构的观点和思考，以证明“为什么Redis的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。 虽然他们强调Redis架构仍然是同类最佳，但也没法忽视Dragonfly这些新软件提供的一些新鲜、有趣的想法和技术，Redis表示其中的一些甚至有可能在未来进入Redis（比如已经开始研究的io_uring、更现代的dictionaries、更有策略地使用线程等）。 另外，Redis指出Dragonfly基准测试的比较方法“不能代表Redis在现实世界中的运行方式”。对此，Reddit上有网友反驳称： 它绝对代表了现实世界中普通用户运行Redis的方式。“在单台机器上运行集群，只是为了能够使用超过1个core”是额外的复杂性，人们只有在别无选择的情况下才会这样做，如果竞争者无论有多少个core都能“justworks”，那么最好能有更容易的 设置。 还有人表示，这篇文章是Redis团队在有礼貌地否认“Dragonfly是最快的缓存系统”，但更多网友表示，Redis发文章进行“回击”，就已经代表他们的营销部门输了： “Redis投入如此多的工程精力来写这么一篇文章，还对Reids/Dragonfly进行了基准测试，这是对Dragonfly的极大赞美。”“我很高兴Redis发了这篇文章，因此我必须要去了解一下Dragonfly，它看起来很棒。” Redis博客文章翻译： 作为一项基础性技术，每隔段时间总有人跳出来，想要替Redis换套新架构。几年之前，KeyDB就提出了这类方案，而最近亮相的Dragonfly则声称是速度最快的Redis兼容型内存数据存储系统。没错，这类方案的涌现当然带来了不少值得关注和讨论的有趣技术/思路。在Redis，我们也喜欢迎接挑战，重新审视Redis最初的架构设计原则。 我们当然一直在寻求为Redis提升性能、扩充功能的创新方向，但这里我们想聊聊自己的观点和思考，阐释Redis时至今日为何仍是最出色的实时内存数据存储（包括缓存、数据库以及介于二者之间的一切）方案之一。 接下来，我们将重点介绍Redis对于速度和架构差异的观点，再以此为基础做出比较。在文章的最后，我们还会提供基准测试结果、与Dragonfly项目的详尽性能比较信息，欢迎大家自行对比参考。 速度问题 Dragonfly基准测试其实是将独立单进程Redis实例（只能使用单一核心）与多线程Dragonfly实例（可以使用虚拟机/服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表Redis在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有40个分片的Redis7.0集群（可使用其中的大部分实例核心）与Dragonfly团队在基准测试中使用的最大实例类型（AWSc4gn.16xlarge）进行性能比较。 在这轮测试中，我们看到Redis的吞吐量比Dragonfly要高出18%至40%，而这还仅仅 只用到全部64个vCore中的40个。 架构差异 背景信息 在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一Redis进程（这类设备往往提供几十个核心和数百GB内存）确实存在资源无法充分利用的问题。但Redis在设计之初也确实没有考虑到这一点，而且众多Redis服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。 Redis通过运行多个进程（使用Redis集群）实现横向扩展，包括在单一云实例背景下也是如此。在Redis公司，我们进一步拓展这个概念并建立起RedisEnterprise。RedisEn-terprise提供管理层，允许用户大规模运行Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。 下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为Redis的生产应用设计良好的工程实践。 架构设计原则 在每个虚拟机上运行多个Redis实例 通过在每个虚拟机上运行多个Redis实例，我们可以： 1.使用一套完全无共享的架构实现纵向与横向线性扩展。与纯纵向扩展的多线程架构相比，这套方案能始终提供更好的架构灵活性。 2.提高复制速度，因为复制操作是跨多个进程并发完成的。 3.从虚拟机故障中快速恢复。因为新虚拟机的Redis实例将同时填充来自多个外部 Redis实例的数据。 将每个Redis进程限制为合理的大小 我们不允许单一Redis进程的大小超过25GB（运行RedisonFlash时上限为50GB）。如此一来，我们就能： •在出于复制、快照保存、AppendOnlyFile（AOF）重写等目的进行Redis分叉时，既享受边写边复制的好处，又无需承担繁重的内存开销。若非如此，我们（或客户）将需要支付昂贵的资源成本。 •为了轻松管理整个集群，我们希望每个Redis实例都保持在较小体量，借此加快 迁移分片、重新分片、扩展和重新均衡等的执行速度。 横向扩展才是最重要的 以横向扩展的方式灵活运行内存数据存储，是Redis获得成功的关键。下面来看具体原因： •更佳弹性——我们在集群中使用的节点越多，整个集群的健壮性就越强。例如，如果您在三节点集群上运行数据集，且其中一个节点发生降级，则代表有三分之一的集群无法运行；但如果是在九节点集群上运行数据集，同样是其中一个节点 发生降级，则只有九分之一的集群无法运行。 •易于扩展——在横向扩展系统当中，向集