2020 年 InfoQ 最受欢迎的文章排行榜 | 架构篇

2020 年 InfoQ 最受欢迎的文章排行榜来了！

本次榜单涵盖九大热门领域：架构、前端、编程语言、云计算、AI、开源、技术管理、运维、区块链…

第一个榜单，我们从“架构”频道开始。2020 年，InfoQ 一共发布了 1700+ 篇架构类的文章，总阅读量超过四百万。

以下是前十篇最受欢迎的文章，你绝对不能错过！

TOP 1：《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》

作者：松子（李博源）

策划：Tina

这是一个四年前的中台建设案例。作为国内早期进行中台实践的大厂，最终也没有逃开失败的结局。

当时，该公司对这个“业务中台”投入了很多：产研七十人左右，运营六十多人，数据团队几十人，采购团队四十多人，审核团队几百人…前后涉及大几百人。然而在短短十几个月之后，这个“业务中台”就宣布被撤，团队成员有人转岗，有人被裁，最后只保留了数据中台团队。

最终，这个项目最终不声不响地逐步淡出了大家的视野，并没有激起短视频内容生态上任何水花。

TOP 2：《K8s和YARN都不够好，全面解析Facebook自研流处理服务管理平台》

作者：Facebook

译者：盖磊

策划：蔡芳芳 

Facebook 在许多使用场景采用了分布式流处理，包括推荐系统、网站内容交互分析等，这些应用的大规模实时运行需要达成严格的 SLO。为此，Facebook 构建了新的流处理服务管理平台 Turbine，并在生产系统中上线运行近三年，部署在由数万台机器构成的集群中，管理着数千条流水线，每秒实时处理数以 TB 的数据。在 Facebook 的生产经验证明，Turbine 很好地平衡了群集间的工作负载波动，可预测计划之外的负载峰值，持续高效地完成大规模处理。

TOP 3：《这些公司为什么放弃微服务》

作者：Justin Etheredge

译者：平川

策划：Tina、万佳

O’Reilly 调查了 1283 个企业，有 52％的受访者表示他们正在使用微服务进行软件开发。其中超过 28％使用微服务超过三年，超过 55％使用微服务的时间为一到三年。O’Reilly 还指出企业对微服务的兴趣可能达到或接近顶峰。

这几年，有无数的中小团队在微服务上陷入了挣扎。微服务有好处但也存在弊端和风险，业务不断发展，微服务也更加复杂，一些企业权衡利弊后甚至选择了退回单体架构。

TOP 4：《数据仓库、数据湖崛起后，下一个应该是什么？》

作者：金晓军、蒋晓伟 

数据仓库、数据湖、HSAP 架构，包括 Flink 社区提的流批一体，它们到底能解决什么问题？本文将由阿里云研究员将业务问题抽丝剥茧，从技术维度娓娓道来：为什么你需要数据湖或者数据仓库解决方案？它的核心难点与核心问题在哪？如果想稳定落地，系统设计该怎么做？

TOP 5：《一文讲透微服务架构下如何保证事务的一致性》

作者：梁桂钊

策划：田晓旭

随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题，例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。而微服务架构是将单个服务拆分成一系列小服务，且这些小服务都拥有独立的进程，彼此独立，很好地解决了传统单体应用的上述问题，但是在微服务架构下如何保证事务的一致性呢？本文作者将为大家详细解答。

TOP 6：《我们为什么放弃 MongoDB 和 MySQL，选择 TiDB》

作者：伴鱼技术团队 

目前，在摩尔定律失效、业务的高可用要求和成本优化等综合的大环境下，分布式架构是技术潮流的大势所趋，流量路由策略加多副本部署（微服务是其中的一种架构形式）解决了无状态服务的分布式架构问题，Redis Cluster 和 Codis 等方案解决了缓存的分布式架构问题，Kubernetes 完成了操作系统的分布式进化，数据库领域自然也不会例外，它的分布式架构趋势一定是不可阻挡的。要特别说明一下，这里所说的解决问题是指系统性的解决问题，MySQL 业务侵入式的分库分表确实是一个可以解决问题的分布式架构方案，但是需要业务研发配合一个业务场景一个业务场景的去解决，这就不能称之为系统性的解决方案，因为在解决这个问题方式上，业务侵入式的分库分表方案将本应由数据库处理好的大表抽象泄漏给业务层了，在这个问题上，我们认为 NewSQL 是一个系统性的解决方案，而 TiDB 就是当下非常不错的一个选择。

TOP 7：《Uber的Kafka实践：踩坑5年，随时像替换汽车引擎一样替换Kafka》

作者：Tina 

Uber 从 2013 年开始使用 Kafka。Uber 的主流应用，如打车、外卖等服务，都需要实时处理数据，所有核心的 Business 都是通过 Kafka 进行消息的传递。这决定了 Kafka 在 Uber 的技术平台中占据非常核心的定位。经过 7 年的发展，Uber 的 Kafka 集群已经发展成为了全球数一数二的规模，每天处理 PB 级别的数据、Trillion 级别的消息。

从 2013 年到 2018 年，Uber 主要是踩坑，修复各种 Bug。到现阶段，整个消息平台已经相当复杂，三分之二的代码是自研，开源 Kafka 仅作为平台核心部分。但这个消息平台也不会被 Kafka 所绑定，当整个系统自动化、标准化工作完成后，又可以用潜在的其他更好的开源软件，像替换汽车引擎一样将这个核心替换掉。

TOP 8：《Service Mesh 化繁为简：基于 Istiod 回归单体设计》

作者：翁扬慧

作为 Service Mesh 领域最具权威的控制面，Istio 从 2017 年发布第一个版本后，就有着一个堪称“非常优雅”的架构设计。但在推出近 3 年后，其开发团队却“意外”推翻之前的架构，重新用上“复古的”单体应用设计。这里面究竟遇到什么不可逾越的鸿沟？ 笔者从几个简单问题（WHY、WHAT、WHEN）出发，为大家揭开这次算是 Istio 诞生以来最大一次“自我革命”的来龙去脉。

TOP 9：《GraphQL vs REST API 架构，谁更胜一筹？》

作者：Michele Moody

译者：平川

策划：万佳

2015 年，Facebook 开源 GraphQL。此后，它在前端 Web 中大受欢迎。传统的 REST API 有何不足？GraphQL 优势何在？在本文中，我们将深入探讨 GraphQL 的设计原则，比较 GraphQL 与 REST 的异同，并讨论 GraphQL 相对其他架构的优点。

TOP 10：《一位架构师的感悟：过度忙碌使你落后》

作者：蔡超

策划：Tina

到现在我工作 17 年了， 担任架构师的职位也超过了 10 年，担任过像 HP、Amazon 这样的世界级团队的架构师，也担任过像汇量科技这样快速成长的中小企业的技术领导。应 InfoQ 邀请分享一下我的工作感悟，分享内容部分来自成功总结，更多是来自失败的反思，希望我踩过的坑大家可以不用再踩。