前端微服务-面向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文件。

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

继承，因为是平台级的基础层，每一个应用都会使用，因此在每一个应用的逻辑处理时，都须要经过继承来使用平台级的方法，固然每一个应用都不同，平台级的工具要作到‘拿来即用’，应用能够结合本身的数据自由组合这些工具，搭建本身的应用，软件行业里面有句名言，‘架构设计中,没有一个问题是不能经过一层抽象层来解决,若是有,那就是两层’。

注意后期维护

若是不明白这个架构思路，当有新人接收项目，或者出现新的业务的时候，很容易将这个架构打破，可能仍是会按照程序员他本身原来的思路去往上堆，若是是个高手他可能会看明白，可是个初中级的段位呢？对吧，最明显的例子就是你可能仅仅加一个小功能，想固然地直接插入进去，虽然成功了，结果很容易忽视它是一个平台级的仍是应用级的方法，甚至可能会由于命名而致使你其余应用的部分功能很差使，因此架构规则很重要，同时也会发现，当你只是要添加一个小功能的时候，基于这是一个平台级的应用，合理地增长新功能是一件不容易的事，你可能会质疑它，但随着你的不断深刻，抽丝剥茧，你最终会发现，这一切都是有缘由可言的。

关于后台通讯

因为将项目全部的重心放在了前端，因此弱化了后端的功能，只须要提供最基本的数据增删改查便可。

关于构建部署

如何前端构建部署都是基于webpack工具来操做，平台级的部署也可以体现微服务的特色，独立部署，独立构建，因此在须要结合项目去自定义脚手架，在我司项目中，自定义npm命令，以web应用名来定义，而在webpack文件夹下，目录结构大概是这样：

和其余脚手架相似，有一个最基本的base文件，来作平台级的构建优化，好比压缩静态资源，babel转编译，打包编译，开发环境和构建环境的差别化部署等等，来覆盖整个应用，而后各个应用有本身独立的webpack文件，对webpack有必定了解的人都知道，在应用中继承或者使用baseJS文件，直接require进来便可，因为webpack的几大要素都是经过对象属性来构成的，因此想二次加工这baseJS文件，能够直接修改这些属性便可，如此，便创建了应用本身的构建部署，

在package.json文件中根据命令定义好了特定web应用的webpack文件

而在cmd命令中，只需输入命令npm run XXX，则会在package.json命令中自动加载特定webpack文件

快速理解

项目特别复杂，你又想特别快入手，明白它的架构设计，我以为抓住两点很重要，第一是数据流，你得注意它的数据结构和流向，从上到下（父子组件，应用之间），从左到右（兄弟组件，应用之间），数据又是如何展现到各个应用的，有一个总体概念，第二，事件机制，其实就是数据处理的交互，每一部分的数据都如何产生的，逻辑处理是怎样的，再深刻到具体的应用中，去分析它的业务便可，这也是为何大学里面计算机专业的课程很大一部分是在教授数据结构和算法，而不教你一大堆主流框架，各类java，R，go，javascript编程语言的缘由，说到底，我认为，一个应用就是由数据结构，算法，以及自己的业务数据构成的，而那些vue或者react只不过是一种工具，让你更好地实现你的idea。

写着写着，其实发现这个vue的设计思想特别像，我以为vue的组件化设计其实就是面向对象思路，react更多的是函数式编程，一切js皆文件，以一种web组件的形式来集成应用，不管是哪种主流框架结构，更多的理解框架自己的设计思路，并融会到本身的项目中，也算是一种借鉴和突破，我认为不必定非得用主流框架，使用一大堆API就是新技术，借鉴思想，修炼js内功，结合业务突破瓶颈，才是最根本的。

其余方面的有时间再完善。