架构师将所有业务放在同一Kubernetes集群是否明智？

鸡蛋

如今许多架构师专注于一件事：以专业术语行愚蠢之事，实属本末倒置之举。别把鸡蛋全放一个篮子，连卖蛋阿婆都懂这道理。阿里云将所有鉴权置于RAM中，滴滴则将全部业务部署在一间KUbernetes集群内……

分享一些个人看法和想法。总体而言，我已是资深架构师，但在网络少有机会谈架构。借此问题，来聊聊我的专业领域吧。第一个问题，我的观点是：把鸡蛋放在一个篮子里，是近期几起事故的根本问题。许多人认为，这些事故本可避免，我对此深表认同，也十分清楚。海恩法则普遍适用于各类严重事故。我想强调，虽然事故的避免、预防、解决和处置都很关键，但这些与建立风控体系仍有本质区别。安全领域有句名言：这一原则同样适用于各类风控系统。确实，如此严重的事故必然伴随着诸多隐患和不当操作，或许这正是过度降低成本的后果。但话说回来，虽然道理大家都明白，可地球上每分每秒仍在发生各种事故，而每起事故背后，往往都有一群懂这些道理的工程师在努力避免却未能成功。 因为：因此，无论何时，人类编织的这些愚蠢的篮子，永远都是：也有人认为，另建集群会带来较高成本。架构师需在风险与成本间权衡取舍，做出选择。我十分赞同，架构师时刻面临权衡。就像每天不得不向愚笨的程序员作出无奈妥协一样。接下来，我来分享一下我的做法。

我相信滴滴的架构师不是傻子，这种方案他们肯定想过，那为何不实施？确实存在很多权衡因素，一个关键原因可能是他们的请求分发依托于 KUbernetes 体系，形成了一个完整的闭环（我一直觉得 KUbernetes 的现有实践过于封闭，迟早会出现问题）。既然分发机制完全在 KUbernetes 内部闭环，一旦负责分发的集群出现问题，就相当于把所有鸡蛋放在一个篮子里，结果全都破损了。因此，我的方案也就失去了意义。为避免这种情况，我不会让 KUbernetes 承担整个体系，而是在其前配置一个外部的负载均衡器，确保流量合理分配，同时降低系统风险，提升架构稳定性。此时，传统技术的优势便显现出来。比如，有些新生代互联网架构师可能会继续质疑我：负载均衡器若挂了，你的鸡蛋还是会全军覆没。其实不然，负载均衡作为一项传统技术，其容灾体系已相当成熟。实现方式多样，包括软件方式（如 HA、nginx）、硬件方式（如 F5）以及云服务（如 SLB）等。由于功能简单且同质化，切换操作极为便捷。在有预案的情况下，手动切换一般不会超过一分钟。确实有人会反驳，即使负载均衡器有备用方案，切换时仍需一个分发流量的装置，而这本身也会成为新的单点故障，风险依然存在，无法彻底避免。这我只能说，小朋友眼界要开阔些，你可听说过一种叫作的技术：什么是网络端口的物理切换技术？

阿里云

当然，如果你搬出互联网上最大的暗黑破坏神：

那我只能甘拜下风，认输。确实，实现异地容灾，得说服老板投资……