说起架构，往往是指后端的架构。对于只使用后端API的前端来看，后端看上去像只做crud；然而，后端并不像看上去那么简单。从架构层面考虑，后端是要实现高并发和高可用的。在数据库和代码实现上等方面有一系列的复杂问题，比如：使用消息队列来解藕依赖，使用微服来拆分单体应用…
架构，在前端领域会更加复杂,涉及领域更广。前端在实现过程中，除了考虑代码的可用性、性能、模型构建、组件复用等问题，还有前端特有的平台设定、浏览器兼容、交互设计、用户的体验等相关问题。而在“大前端”背景下，还需要深入移动端设计、桌面应用、物联网等相关的领域。
什么是架构？
不同的人对架构有不同的理解，不同的组织有不同的定义。维基百科：
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。
所有的架构定义中，无一不在强调设计架构的整体及内部各个部分的关系。与此同时，还设计实施过程中的原则和相关的设计实践。软件开发的过程好比盖房子：
- 如果不先打好地基，那么就无法继续往上盖房子。
- 开始盖房子时，便是在实施对应的架构。 如果地基有问题，盖的房子难以长久存在。
- 在浇筑钢筋水泥时，若不注意，房屋就可能会歪歪扭扭。
- 房子盖好了，但后期不维护保养，仍然会出现问题。
盖房子和软件开发比较相似的，需要要规划、设计、实施，而后才能使用。盖房子，最先设计的也是建筑的架构，有了建筑的蓝图，还需要考虑美观、实用、坚固等要素，从各种各样的材料中选择合适的，完成这一系列决策才能进入实施阶段。在实施的时候，还需要严格按照建筑的蓝图来进行施工，并保证施工的质量，才能造出所需的建筑。
对于软件开发来说也是相似的。最初，设计出软件的总体架构蓝图，思考各个模块之间的关系，实施一系列相关的架构决策。然后，选择软件开发所需要的一系列技术栈、框架等，讨论关于应用的上线、部署等流程问题。最后，才能进入软件的开发阶段。在开发的过程中，还需要保证软件的质量，才能设计出符合要求的系统。
而无论是建造房屋，还是开发软件架构，其中的一个重中之重的步骤便是结构设计。对于房屋来说是建筑结构，对于软件来说则是软件架构。
什么是微前端？
互联网：
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时，它们也可以在共享组件的同时进行并行开发.
笔者理解：
微服务就像是一个操作系统：在其中可以运行多个app。但每个app呢，又可以脱离操作系统独立运行。
微前端架构：
- 应用自治。微前端架构，是多个应用组件的统一应用，这些应用可以交由多个团队来开发。要遵循统一的接口规范或者框架，以便于系统集成到一起，相互之间不存在依赖关系。
- 单一职责。微前端架构理应满足单一职责的原则。
- 技术栈无关
为什么需要微前端架构
- 遗留系统迁移。解决遗留系统，是采用微前端方案最重要的原因。
- 后端解耦，前端聚合。后端微服务可以解耦服务间的依赖，而对于前端来说，更想要的结果是聚合前端应用，尤其是ToB的应用。
- 热闹驱动开发。所谓热闹驱动开发指的是，软件开发团队所做的软件架构或技术栈的决策，其中很多决策并没有经过踏实的*研究和对目标成果的认真思考，而是不准确的意见、社交媒体的信息，或者就是些“热闹”的玩意。
微前端的几种实现方式
- 路由分发式。通过HTTP服务器的反向代理功能，将请求路由到对应的应用上。
- 前端微服务化。在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用。
- 微应用。通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
- 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可。
- 前端容器化。将iframe作为容器来容纳其他前端应用。
- 应用组件化。借助于Web Components技术，来构建跨框架的前端应用。
参考资料：
- 《前端架构：从入门到微前端》 — 黄峰达
- 《架构设计：微前端架构》
- 《vue项目落地(qiankun.js)微前端服务》