随着前端工程化日益发展，微前端的概念和微服务一样，越来越受到关注🚀。本文将以一个实际的业务场景故事为例，深入浅出从微前端的架构设计和具体代码实现角度，为大家提供一套详细完整的解决方案！
下一篇直接跳转到(qiankun微前端改造实战（架构设计+代码实现）-超级详细vue代码干货篇！（伸手党福利）)
(PS: 应用框架基于vue2.x,微前端框架基于qiankun)
什么是微前端？
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略（好难懂🙁直接跳过往下看）。(抄袭自qiankun官方文档)
如何设计一套微前端架构?
很多开发人员在接触到微前端改造的任务时，往往就直接去寻找微前端框架，在代码层面想着怎么将各个应用串联起来，其实这一步是错的🙅。微前端是一套复杂的架构体系，在着手写代码之前，必须要先结合公司的实际业务场景，设计出一套严谨的底层产品架构设计。只有在健壮的底层架构设计蓝图的基础上。才能建造出坚固宏伟的微前端大厦🌇。
那如何去规划设计一套微前端的架构蓝图呢？我们接下来以一个实际的业务场景为例，手把手的教大家如何设计出一套微前端架构。
一、故事背景：
假设现在我们开了一家公司，我们是大boss(想想就已经很开心😍)，我们的第一个业务是卖座机电话☎️。
我们用jq开发了一个在线商城，上面可以卖各种颜色的电话。同时我们用angular开发了一套后台管理系统，系统里面记录着我们的客户、电话品类、订单、客户工单、以及销售系统的管理员、销售人员、总经理等等各种各样的角色管理功能。同时我们基于angular开发了一套网银支付系统。
就这样过了5年。。
我们的系统很稳健，电话卖的也很好，但是这个时候 手机📱兴起了，随之而来的还有支付宝支付系统。技术上随着angular和jq的没落(人越来越少)，我们需要使用新的vue框架开发系统，这时候我们开始想，把老的angular系统重新用vue写一遍。这是一个美好的愿望。然而现实是，考虑到研发成本、测试成本以及用户习惯迁移成本等等一系列现实情况，我们只能将老系统沿用下去。
但是呢，我们现在要开始卖手机，也要接入新的支付宝支付系统。我们还要使用新的vue技术框架，于是乎我们开始用vue开发了跟angular一摸一样的后台系统。。
到此为止。我们公司有了两套产品管理系统、两套支付系统、两套角色管理系统。这样的模式持续了一阵后。问题终于出现了。
公司为了更好的服务，提出了客服系统的概念，用户可以在前台和后台呼叫客服，这时候需要我们开发一个客户服务页面，由于技术框架限制，于是乎我们需要在vue系统前端开发一遍，angular系统前端再写一遍一摸一样的页面。。我们开始意识到，以后再卖电脑、甚至再卖软件的话，我们还是要把之前的业务系统再写一遍。。对研发资源的浪费是不可忽视的。此外还有运营团队的划分、财务的对接等等会被这种情况所影响。
于是乎，我们开始考虑 这样下去不行，不然以后我们的系统迟早有一天会因为臃肿彻底僵化死掉！
怎么办呢，经过我们苦思冥想。终于想出一套解决方案。那就是！！
如果我们能让全公司只有一套后台管理系统。只有一套支付系统。只有一套优惠券积分系统，其实不是完美的解决这个问题？
答案是：是的。 可是我们怎么实现呢，现在有两个后端管理系统，都有自己的登录页面、都有自己的订单管理、客服管理、甚至系统设置菜单，怎么融合成一套呢？
接下来就是微前端需要入场了!
二、微前端改造方案
总体思路是，我们重新建一个新的后台管理总系统，产品层面分别将手机销售平台和电话销售平台的登录控制、角色管理、支付管理、订单管理等等一些列有交集的模块融合，后端以微服务的方式将上述模块做抽象处理，以一套全新的后端openApi方式对接到多个业务系统的后端，前端就以微前端方式将上述模块按需引入，以后我们如果再需要用到支付模块时，我们就不用再开发一套支付系统了，直接通过微前端+微服务引入即可，一秒实现!
三、微前端改造具体方案设计模型
有了总体思路的指引，我们就可以开始设计整体的微前端架构图了。我们先做一下新老系统架构对比。
可以很明显的看到两种设计模式对我们未来项目演进和扩展的鲜明利弊对比。
新的系统架构设计中
不单单是节省了重复的代码开发和资源浪费，未来我们还可以接入任意的其他模块，各自模块未来的可维护性也会变得更强。此外在团队管理上。各自业务团队可以专注于各自的业务逻辑开发，对团队人员关注点划分和敏捷迭代效率提升也有很大的帮助。
到此为止，初步的设计方案已经完成。在总体方案框架的指导下，下一篇我们将开始正式的一点点从代码层面搭建微前端！
