微前端随记

微前端

大型组织的组织结构，软件架构在不断变化。导致组织和应用不断膨胀，从而映射到软件架构中。

移动优先->App平台（One App）->中台战略->...?

组织架构的变化同时，如天下大势，“分久必合，合久必分”，一个功能过于庞大，分治就是最理所应当的策略。同时，分治导向的可能是业务场景，技术栈的多样化。但过了不久，用户越来越难以忍受一家公司的不同业务分散在多个应用上，于是应用又走向了聚合。

微前端是一种类似微服务的架构。是微服务理念在浏览器端的应用实践。即将原来由单页面前端应用由单一的单体，转变微多个小型前端应用的聚合体。每个子项目可以独立开发部署，也可以进行并行开发。组件之间通过npm，git等进行管理。

微前端的核心思想就是（拆）分（自）治。达到降低维护成本的目的。以下是它的三个基本概念：

自治：不同应用由不同团队维护，但遵循统一的接口规范或框架以便于集成。因此彼此之间不存在依赖。因此在技术选型，人员配置上拥有较大的自由度。

单一职责：前端作为最终面向用户的开发环节，想要单一纯粹的职责？基本上，天哪这个太难。

技术栈无关：在后端，可以选用最合适的语言去实现不同特性的服务，而在前端的js世界里，即便存在各种框架，但从最终实现效果来说，其实差异并不大——一个框架能做的，另一个也能做。

对于大部分公司团队来说，技术无关只是一个无关痛痒的话术。公司创始时用JAVA，那么极有可能在未来继续使用 JAVA。

技术栈无关还存在以下缺点：

•拆分时，如果都对基础设施有强依赖。那么维护就是一个挑战。•粒度过小，维护成本反而提高•多样化的技术栈，意味着混乱。

那么什么时候考虑做微前端？

•遗留系统的迁移：最重要的原因。正在赚钱的东西没有理由毁掉重来。人生苦短，尽量不要重构了。•聚合前端应用：这是前端特有的需求——后台使用微服务，希望的是解耦服务之间的依赖。但在前端界面，人们更想把各种功能聚合在一起。比如说adobe公司对于视频编辑，就有PR（剪辑），AE（特效），Encore（转码），Au（音频编辑）等等一系列的软件。用户每当使用一个功能，不得不去开n个软件。甚至N台电脑。因此，一个面向用户的产品，更希望是“功能强大”的。而微前端最后要达到的目的，就是实现聚合•“热闹驱动开发”：开发团队在软件架构和技术栈方面的调研，往往是不足的。不排除为了KPI，或者在个人开发过程中获得更大的发挥，最后采用了新技术。——微前端就是一种“热闹”的技术。因此，在采用之前，需要看看看别人的失败经验。对于未来，仍然有很多路要走。