文档介绍：1
微效劳前端架构开发介绍
前言
在 ThoughtWorks
正式公布的最新一期技术雷达当中，「微前端〔 Micro Fontends 〕」
已经进入到试验阶段，而试验环所列出的技术是
微效劳架构带来了哪些好处？
假设效劳边界已经被正确地定义为可独立运行的业务领域，并确保在微效劳设计中遵循诸多最正确实践。那么至少会在以下几个方面获得显而易见的好处：
简单性：效劳可以更好地分别，每一个效劳都足够小，能够完成完整的定义清楚的职责；
4
·
扩展性： 每一个效劳可以独立横向扩展以满足业务伸缩性， 并削减资源的不必要消耗；
·
机敏性：每一个效劳可以独立失败，允许每个团队自主选择最适合他们的技术和根底架
构；
·
灵敏性：每一个效劳都可以独立开发，测试和部署，并允许团队独立扩展和维护各自的
部署效劳。
每个微效劳是孤立、独立的「模块」，它们共同为更高的规律目的效劳。微效劳之间通过契约彼此沟通，每个效劳都负责特定的功能。这使得每个效劳都能够保持简洁、简洁和可测试性。
在这一根底上微效劳架构允许企业更自发地实行更深远的业务决策，由于每个微效劳都是独立运作的， 而且每一个治理团队可以很好地把握该效劳的变更。
那么前端的现状呢？ —— 臃肿的前端
5
微前端的定义 - 将微效劳理念扩展到前端开发
〔 图片来自： ://
〕
在前端， 往往由一个前端团队创立并维护一个 Web 应用程序， 使用 REST API 从后
端效劳猎取数据。这样的做法能够供给优秀的用户体验， 但会导致单页面应用〔 SPA 〕
不能很好地扩展和部署。在一个大公司里，单前端团队可能成为一个进展瓶颈。随着时
间的推移，由一个独立团队所开发的前端层往往会越来越难以维护。特别是一个特性丰
富、功能强大的前端 Web 应用程序， 却位于后端微效劳架构之上时。随着业务的发
展， 前端会变得越来越臃肿， 一个工程可能会有 90 ％ 的前端代码， 却只有格外薄的
后端， 这种状况在 Serverless
架构的背景下还会愈演愈烈。
6
微前端〔 Micro Frontends 〕这个术语其实就是微效劳的衍生物。将微效劳理念扩展到前端开发，同时构建多个完全自治、松耦合的 App 模块〔 效劳〕，其中每个 App 模块只负责特定的 UI 元素和功能。
假设我们看到微效劳供给应后端的好处，就可以更进一步将这些好处应用到前端。与此同时，在设计微效劳的时候，就可以考虑不仅要完成后端规律，而且还要完成前端的视觉局部。而微前端与微效劳的很多要求也是全都的： 监控、日志、HealthCheck 、Analytics 等等。
微前端的核心思想
Be Technology Agnostic
：每个团队都应当能够选择并升级他们的技术栈，而不必与
其他团队协调。自定义元素〔 后面会具体提到〕是隐蔽实现细节的好方法，同时为其他
人供给公共接口。
7
·
Is