你可能并不需要微前端

2,863 阅读5分钟

去年看到社区里一些关于微前端的讨论时,就想写篇文章梳理一下自己的观点,后来因为种种原因搁置了(主要是懒)。今天在微信群中看到又有不少人谈起微前端,虽遗憾错过了讨论,但也勾起了自己的表达欲。所以这里整理了一些文字,记录下自己的观点。

先说两个观点。

1. 微前端是「康威定律」在前端架构上的映射

设计系统的架构受制于产生这些设计的组织的沟通结构。 — M.Conway

康威定律几乎就是微前端(准确来说是微服务架构)的理论基础了。它指出了组织架构越庞大,其系统间沟通成本越高的问题。而解决这一问题的有效手段就是,将大的系统拆分成一个个微小的,可以独立自治的子系统。一旦系统的依赖限制在了内部,功能上更加内聚,对外部的依赖变少,那么就能显著的减少跨系统之间的沟通成本了。

简单来说,康威定律的指导思想就是:既然沟通是大问题,那么就不要沟通就好了[doge.jpg]。

所以本质上,微前端(微服务架构)关注的是如何解决组织和团队间协作带来的工程问题,而不是单纯的某个技术问题。

群里飞叔只说对了一半,实际上当时我是有各个前端应用的主控权的。但主要问题出在这些系统都是 4年+、代码 20W行+ 的长尾应用,而产品还在持续的集成迭代,我既没精力去给他们做技术栈升级,也没动力(兴趣)去跟一个个前应用 owner 沟通了解一些技术细节。

这可间接的引出我的第二个观点。

2. 微前端的假设是,所有大型系统都逃不过熵增定律

这个假设指的是,所有大型系统都将从有序变为无序,他们背后的 codebase 的归宿都将是「屎山」。

如果不是,那一定是因为这个系统使用的技术栈更新的不够快,参与系统开发的工程师不够多,产品迭代的时间不够长。

在潜意识里,微前端的采纳者就不相信一个系统会永远健康的迭代下去。因为熵增永远是自然且轻松的,而对抗熵增,则必须有足够的外力介入、足够的成本投入才行。

这也是为什么,qiankun 的很大一批用户,都是因为要在一批长尾应用上迭代新功能,最后实在搞不动,才会尝试用微前端的方案来解决了。

基于此,微前端很多时候是「悲观主义工程师」在工程上的妥协,是一种防御性,有时候甚至是「掩耳盗铃」式的架构策略。

当然在理想状态下,对于一个有追求的工程师而言,所有的技术问题都应该是被正面修复、正确治理的,而不是起手就来一个 workaround。但同时所有的软件工程原则也都会告诉我们,不遗余力、不计成本的去优化、解决一个技术问题是不可取的,尤其是在这个问题的投入产出比不高的情况下。

微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题,而是告诉我们,很多时候我们可以通过分而治之的手段,让「上帝的归上帝,凯撒的归凯撒」。

满足以下几点,你可能就不需要微前端

基于以上两个观点,我们可以概括出,存在以下场景时,你可能就不需要微前端:

  1. 你/你的团队 具备系统内所有架构组件的话语权 简单来说就是,系统里的所有组件都是由一个小的团队开发的。
  2. 你/你的团队 有足够动力去治理、改造这个系统中的所有组件 直接改造存量系统的收益大于新老系统混杂带来的问题。
  3. 系统及组织架构上,各部件之间本身就是强耦合、自洽、不可分离的 系统本身就是一个最小单元的「架构量子」,拆分的成本高于治理的成本。
  4. 极高的产品体验要求,对任何产品交互上的不一致零容忍 不允许交互上不一致的情况出现,这基本上从产品上否决了渐进式升级的技术策略

满足以下几点,你才确实可能需要微前端

  1. 系统本身是需要集成和被集成的 一般有两种情况:

    1. 旧的系统不能下,新的需求还在来。 没有一家商业公司会同意工程师以单纯的技术升级的理由,直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入,因为产品说需要「弹个框弹到中间」
    2. 你的系统需要有一套支持动态插拔的机制。 这个机制可以是一套精心设计的插件体系,但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景,可能后面还是会过渡到各种微前端的玩法。
  2. 系统中的部件具备足够清晰的服务边界 通过微前端手段划分服务边界,将复杂度隔离在不同的系统单元中,从而避免因熵增速度不一致带来的代码腐化的传染,以及研发节奏差异带来的工程协同上的问题。

还是那个老生常谈的理念,没有银弹,架构本身就是各种 trade–off。

大部分时候,一个「流行」的东西,你都无法阻止不需要它的人去使用它。