前端微服务-面向web应用的新设计

从去年开始，前端领域就出现了一个‘微应用’的名词，说的是前端架构的一种设计思路，业内都把它和后端的微服务进行类比，当时忙于公司的项目。没有静下心来好好了解，现在项目结束，再加上最近看的几篇关于前端微服务的文章，（特别讨厌有些文章说的天花乱坠，引用各种高大上的名字，一篇通读下来什么也没有获得）回头一想，我们做的这个架构设计不就是 ‘微服务’吗？

首先说一下前端微服务。

我觉得这是一种架构设计，不是什么新技术，而是多种技术结合的产物，既然是架构设计那么它就得有使用场景，否则那是空谈，而它的使用场景则是面对平台级的产品解决方案，可以支撑许多web应用，各个应用之间相互独立解耦，又可以不断扩展，不仅易于老代码，老业务的维护，而且开发项目也是游刃有余的。对于开发人员来说，这样的架构设计也是独立的，完完全全可以负责单独的web应用，而不需要和别的团队交叉式协作，所以我觉得如果产品是平台级的，做的是解决方案的东西，长期支撑公司发展的，那它的一种设计思路不妨一试，但如果就是几个独立的web应用，比如说公司官网，后台系统，支付系统，这几个一点关联都没有的项目，没有必要来这样做，反而会增加项目本身的难度。

它的出现我觉得很大程度上是由于spa单页面应用的出现，组件化的出现，让一个完整的页面从几个标签的组合，到模块功能的组合，再到应用的组合，一步步过渡，最初一个页面由几个标签加点文字或者图片组成，主要用来向消费者输出信息，到后来ajax出现，局部刷新人机交互，页面成了按照功能模块来划分，再到现在单页面应用，直接按照应用来划分，每一个应用有自己的一套数据，交互，逻辑，业务等等，页面成了一个容器，或者说是一张幕布，它所做的就是有一个加载机制，更够很多好地处理各个应用的关系和数据通信，所以一步步走过来，有各大浏览器厂商对引擎的升级换代，有硬件的迭代，还有大量交互数据的出现，体验的升级等等因素，这些诉求让前端领域不再是展示内容那么简单，需要不断突破自我，架构设计应运而生。

微服务里面容器或者称为平台该怎么搭建，怎么加载不同的web应用，应用之间如何数据通信，应用怎么扩展定义，那些平台级核心方法如何处理等等，带着这些问题，结合我司的项目谈谈我的看法及设计思路。

做前端平台级的架构设计，首先有一个最基本的容器，由于项目的复杂特点和背景，我们使用的是jq，别觉得low，用小米加步枪能打败敌人更是说明策略用得好，容器呢则是iframe，应用之间数据通信呢，则是挂载了window这个大对象。

那么如何去加载不同的应用呢，有的做法是将所有的应用js文件在首次全加入进来，每一个应用都是一个独立的大对象，根据地址栏的url组成，获得其中的hash名，这个名字可以是应用的名字，去实例化特定的应用。

或者学习一下vue-router，利用hash改名字，页面不刷新的特点，去按需加载特定的应用js文件。

在或者直接以整个web组件的形式，通过document.append的方式直接插入进来。

我司采用的是第二种，这样的方式可控，加载机制可以自定义处理。毕加索的名言，‘优秀的艺术家抄袭创意，杰出的艺术家剽窃灵感’。

然后各个应用该如何处理呢，怎么才能做到应用独立扩展，而又没有重复代码呢？

按照如今一切js文件皆模块的原则，每个应用的数据，交互逻辑，都是独立的类，或者独立的模块，这个每次扩展就是一个独立的类，包含着新业务的特定数据和逻辑，相互之间使用import进行引用，不会出现代码越来越多，惨不忍睹的情况，而每一个应用它都有一个index.js文件，在每次启动应用的时候去加载这个index文件。

而那些平台级基础层的组件如何操作呢

继承，由于是平台级的基础层，每个应用都会使用，所以在每个应用的逻辑处理时，都需要通过继承来使用平台级的方法，当然每个应用都不一样，平台级的工具要做到‘拿来即用’，应用可以结合自己的数据*组合这些工具，搭建自己的应用，软件行业里面有句名言，‘架构设计中,没有一个问题是不能通过一层抽象层来解决,如果有,那就是两层’。

同时还要注意后期维护，如果不明白这个架构思路，每一部分的规则，当有新人接收项目，或者出现新的业务的时候，很容易将这个架构打破，还是会按照程序员原来的思路去往上堆，最明显的例子就是你可能仅仅加一个小功能，想当然地直接插入进去，虽然成功了，结果很容易忽视它是一个平台级的还是应用级的方法，甚至可能会因为命名而导致你其他应用的部分功能不好使，所以架构规则很重要。

关于后台通信，由于将项目所有的重心放在了前端，所以弱化了后端的功能，只需要提供最基本的数据增删改查即可。

时间有限，先写这么多，其他方面的有时间完善。