转载

杀死Apache Kafka：过度架构的陷阱 - Stephanie Sherriff

通往地狱的道路充满了良好的愿望。希望您可以从我们的错误中学习并发现为什么在开始下一个项目时应该考虑极简主义。

在Spaceship，Voyager应用程序后端的第一个迭代很大程度上依赖于Kafka。我们的意图是崇高的：创建一个应用程序，随着我们的客户群的增长，该应用程序将具有可审核性，稳定性和长期负担。

最终采取Kafka是一个相当简单的过程，但最终复杂化。Voyager的真正内心在于投资体系，其中大多数与成员之间没有直接互动。只需注册Voyager，就不必为极重的负载创建系统。团队很小，时间表很雄心勃勃，而且第一次发布产品时就不需要额外的开销。在大多数情况下，当您需要处理大量请求时，无论如何您已经重写了事情。有一个好问题；这意味着您正在成功。

当时可能没有考虑的其他问题是基础架构的成本，更重要的是维护和支持的成本。

花时间掌握新技术

每种技术都有自己的处理方式。有一种“正确”的方法。如果您的团队中没有已经拥有新技术经验的成员，那么，您迟早会梦想着正确重写它。

即使您确实有团队成员花费大量时间来使用这项技术，也可能需要一些时间才能使其他成员开始使用。有时必须进行切换，但要让整个团队团结起来，讨论您为什么要切换，并确保出于所有正确的原因进行切换。另外，请确保您不想太快地添加太多新技术。

聘请新工程师时，简单的应用程序变得更快，更容易。

使用简单易用的技术栈，该技术栈在行业中很普遍，这意味着您可以让新的团队成员加入团队，并且比复杂的设置要快得多。通常，学习公司的业务领域需要花费足够长的时间。通过技术堆栈增加额外的复杂性意味着团队的整体产出减少的时间将超过必要的时间。在一家初创公司中，如果营业额很高，而您正试图快速成长，那真的可以加起来。

易于支持

在支持生产应用程序时，调试问题在最佳情况下通常很困难。当应用程序很复杂时，这可能会导致支持问题增加。

一个常见的问题是团队中只有一个人知道应用程序的工作方式并最终一直支持该应用程序。如果工程师休假，生病或离开公司，而其他人都不知道该怎么办，那么这种知识孤岛最终可能会伤害到团队。对于支持该应用程序的人员来说，这也可能很无聊，导致企业失去一支优秀的团队成员，因为他们希望从事新工作。

另一个问题是，调试问题可能需要更长的时间，这可能会使不满意的客户受益。尤其是当您是新手时，您需要做的最后一件事就是让客户感到沮丧，留下不好的评论或对他们的朋友说坏话。

易于添加和修改

与最初的开发一样，一个更简单的应用程序可以更快地添加修复，更新和新功能。有时，过于复杂的旧版应用程序会将所有更新放入“太难”的篮子中。

我们如何解决

快速的答案是我们转向使用带有protobuf模式的gPRC微服务。卡夫卡被完全被砍掉。解释我们如何做到这一点又是另一回事，但它花了很多时间进行规划，并且花了三到四个星期的时间。幸运的是，我们有时间来照顾我们所谓的大量技术债务。

好处是可观的。上岗时间减少了，人们可以快速启动并运行该技术，并且可以通过与支持工程师一起进行工作的前一两个星期进行标记，从而学习业务领域。可以在整个团队中轮流提供支持，因为任何人只要对编码有一点了解，并且能够搜索日志至少可以跟踪问题的根源。支持SLA的时间已大大减少，并且支持的轮换限制了知识孤岛和无聊，因为您知道您会花时间回到有趣的东西上。哦，我是否提到我们将服务器数量减少了约50％？

每个公司都有自己要解决的问题，有时需要复杂的技术。只要确保技术能够解决问题而不是解决问题即可。更少的代码，更少的错误。

原文 https://www.jdon.com/53615

正文到此结束