首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

我们为什么用gRPC取代了Kafka

作者 | Stephanie Sherriff

译者 | 无明

策划 | 小智

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

1

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

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

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

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

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

2

背景

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

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

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

3

问题

采用新技术需要时间

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

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

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

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

方便查找问题

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

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

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

方便维护和修改

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

4

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

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

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

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

英文原文

https://medium.com/spaceship/killing-kafka-the-pitfalls-of-over-architecting-c9fe3f1085fb

点个在看少个 bug

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20191223A0A9QE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券