我们为什么用 gRPC 取代了 Kafka？

作者 |Stephanie Sherriff

译者 | 无明

策划 | 小智

本文作者的技术团队第一个 App 高度依赖 Kafka，她希望这个 App 能够支持审计，具有很高的稳定性，从长远看，随着用户量的增长也能够轻松地处理高负载。但 Kafka 同样带来了基础设施、系统维护和支持方面的成本问题，最终他们选择了用 gRPC 取代了 Kafka。值得说明的是，二者的技术选型并没有明确的优劣之分，有的只是业务场景和需求所带来的取舍。

保持简单的技术选型更重要

程序员职业生涯的大部分时间都用于维护和修复已有的系统。运气好的话，如果你加入了一家初创公司，就有机会从头开始构建全新的系统。这种兴奋是无可言喻的，因为你有了一个可以“重新来过”的机会，终于可以把旧系统那些让你感到反胃的东西扔掉了。

你开始思考可以使用哪些新技术，有些是你已经尝试过的，有些是你在某篇文章上刚刚看到的，有些是你在之前项目中用得很成功的。也就是在这个时候，你感到了稍许的轻松，起码在一段时间之内，你或者你的团队会一直维护这个新系统。

于是你开始想：这个跟这篇文章的标题又有什么关系？我为什么讨厌 Kafka ？我其实不讨厌 Kafka，或者更确切地说，是有那么一点点。从使用体验看，Kafka 并没有给我留下非常好的印象，而且我们也只是在用它解决原本就不存在的问题。

不管你有没有在遵循 KISS（Keep It Simple Stupid，保持简单）或 YAGNI（You Aren’t Gonna Need It，你其实不需要它）原则，又或者你只是想尝试一下，我都希望你能够从我们犯过的错误中学到一些东西，并在开始下一个项目时意识到，保持简单是多么的重要。

背景

我们的第一个 App 高度依赖 Kafka，因为我们希望我们的 App 能够支持审计，具有很高的稳定性，从长远看，随着用户量的增长也能够轻松地处理高负载。

但 Kafka 却让整件事情变复杂了。我们的核心系统是一个投资系统，大多数时候不会直接与用户发生交互，所以我们没有必要创建一个高负载系统来支持用户。我们的团队本来就不大，时间又紧，在发布第一个版本时没有必要花费额外的开销。大多数情况下，真正到了需要处理大流量的时候，你可能已经把系统都重写过了。而如果能够走到这一步，说明离成功不远了。

到了这个时候，被忽略的往往是基础设施、系统维护和支持方面的成本问题。

问题

采用新技术需要时间

每一种技术都有它自己的特点和正确的“打开”方式。如果你团队里没有人熟悉一项新技术，那么很可能在一开始不知道怎样做才是对的。等你知道该怎么做的时候，可能已经需要重新来过了。

即使你团队里有人熟悉这项新技术，要让其他人都熟悉起来也是需要时间的。有时候采用新技术是势在必行的，但你要让整个团队都知道，并一起讨论这样做的必要性，另外也要注意不要在短时间内引入太多新技术。

技术栈越简单就越容易上手

对于新手来说，简单且在业内随处可见的技术相比复杂的技术栈更容易上手。吃透一家公司的业务逻辑本来就需要很长时间，如果在技术栈层面再加入额外的复杂性，那么开发团队的产出必然会打折扣。在初创公司，一方面人员流动率很高，一方面公司又想快速成长，这种情况就会越加严重。

方便查找问题

调试生产环境的应用程序通常不是件容易的事情。如果应用程序本身很复杂，就会带来更多的问题。

如果团队里只有一个人知道怎么处理这些问题，那他就要一直盯着。如果这个人生病或者离开公司，对于团队来说就是一个严重的打击。而对于这个人来说，老是处理这些问题也是件很枯燥的事情，因为他也想做一些不一样的事情。

另一个是处理问题需要很长的时间，这可能会导致用户不开心，特别是如果你是一个新手，很可能会让用户暴跳如雷，然后留下不好的评论，或者跟他们的朋友说你的坏话。

方便维护和修改

简单的应用程序不仅开发起来容易，修复、更新和添加新特性也很容易。有时候，对一个复杂的遗留应用程序进行更新通常会被列为“高难度”的难题，因为没有人心里有底，不敢去碰它，所以迟迟不敢动手。所以说，没事不要去摸老虎的屁股，小心它回头过来咬你。

我们是如何解决这些问题的

我的解决方案是改用 gPRC ，并把 Kafka 从我们的技术栈中移掉。至于我们是怎么做的就说来话长了，我们做了很多规划，整个团队花了三到四周的时间。我们是幸运的，因为公司给了我们足够的时间来偿还这笔巨额技术债务。

改造给我们带来了很可观的好处。新手上手的时间缩短了，他们跟支持工程师在一起一两个礼拜就能够对公司的业务有所了解。团队成员可以轮流提供支持，因为每个人对代码多多少少都了解一些，至少知道如何搜索日志，找到问题的根源。支持 SLA 时间大幅下降，轮流值班也限制了知识孤岛的形成，支持人员也不再感到无聊，因为他们每次做的事情可能不一样。另外，我们的服务器数量减少了 50%。

每家公司都有自己的问题要解决，有时候采用复杂的技术架构也是在所难免的。但你需要确保采用技术是为了解决问题，而不是制造问题。代码越少，bug 就越少。

点个在看少个 bug