普元云计算-聊聊前端工程化的实践与将来

转载本文需注明出处：微信公众号EAWorld，违者必究。

 

 

目录：

 

1、前端过去一年的发展

2、工程化是前端实现的核心

3、EOS8前端工程化设计实践分析

4、总结与展望

 

1、前端过去一年的发展

 

2017年的前端发生了很是多的事情。快速的技术进步，彷佛已经使前端工程师目不暇接，咱们来一块儿看下去年发生了哪些事件：

 

 

• React16发布前夕，React license风波发展到顶峰，多家公司宣布将不在使用react做为其产品的前端框架。网上对Facebook的声讨也达到了顶点。随后Facebook不得不将React license更改成MIT。这件事情极大的影响了React在你们心中的定位，人们纷纷将目光投向Vue。

   

   

• 去年，Angular一口气发布了两个版本，Angular4以及Angular5。这样的变化彷佛在乎料之中，又在乎料以外。根据官方文档说明，从Angular4以后，每一年只会发布一个大版本。然而在刚刚进入18年的时候，Angular 6.0.0 Beta版本发布，让前端开发者不得不感慨，前端之路太心酸了。

   

• 2017年是Vue飞速发展的一年，除了学习曲线平缓，Api简单易用以外等诸多缘由外，离不开React和Angular的种种“不友好”的行为。

   

• PWA（渐进式网页应用）愈来愈被你们所关注，也愈来愈被应用。也许这个技术并非咱们一直在寻找的使用网页技术完美支持其它客户端的方法，但PWA使用现代的浏览器技术使得访问网页应用的体验和原生移动应用同样。而且在性能上有了大幅度的提高，并且支持离线访问，像推送通知这样原生APP才有的功能也支持了。

   

• WebAssembly(wasm)已经开始被全部主流浏览器支持。也许WebAssembly将会开创Web的VR/AR新时代。

   

• 2017年Serverless应用持续增热，这是一种新的能够提升性能又减小资源耗费的架构。你的客户端彻底从服务器从分离出来，这样就能够只关注应用自己而不是架构。一个常见的实现方法是用AWS API Gateway和AWS Lambda函数做为后台服务。

   

• GraphQL日趋火爆，有赛过REST之势。Samer Buna甚至宣传REST已死。GraphQL容许客户端自定义数据，而后一次获取。而REST方案须要维护获取不少无效数据。Github的新版API已被GraphQL重写。

在变化飞快的前端发展中，前端究竟应该如何开发，究竟应该用什么框架，前端代码如何部署，如何进行先后端分离成为人们争论的焦点。

 

 

2、工程化是前端实现的核心

 

在将来，前端工程化成为工程师关注的核心问题。 而工程化的几个重要方面，就是路由的实现方式，组件模块化，构建自动化。

 

 

• 路由实现方式。先后端分离，前端路由显得尤其重要。除了多层级的设置，还要考虑路由实现方式。

   

• 因为前端模块化，各个组件各个模块如何相互通讯，则尤其重要。必须统一进行管理，不然在多人同时开发，且页面不断增长的状况下，前端代码会愈来愈难以维护。

   

• 开发的过程当中，要考虑到部署方式。尽可能使用一套可以知足全部部署方案的方法进行开发，减小部署工做量。

 

1.路由实现方式

 

最经常使用的路由分为Hash路由及History路由。

 

 

• Hash路由：（例http://primeton.com/#/login.html）经过改变地址后面的hash来改变浏览器历史记录，Hash部分不会发至服务端，框架自己根据url来生成相应的模块

• History路由：（例http://primeton.com/login.html）使用HTML5的History API，提供pushState(),replaceState()等方法。路由请求会发至后端服务器。

 

通常主流作法推荐使用History路由。

 

使用History路由的好处在于两点，其一是页面url比较美观，其二是能够复用浏览器自身的前进后退特性，但在SPA（单页面应用）状况下支持history模式须要后端的支持。

 

因为普元微服务治理平台并不但愿路由变化时，浏览器发请求到后端，故使用Hash路由。这样作的好处是经过前端控制用户权限，必定程度上方便后期对系统的扩展。这主要跟总体平台架构的设计有关。

 

2.灵活部署，解决先后端通讯

 

先后端分离模式的开发模式下，一般有两种部署方式来解决与后端进行ajax通讯的问题。一种是Nginx做为部署容器，一种在构建工具中将请求转发。

 

 

1. Nginx做为部署方式，须要启动一个Nginx服务，经过配置config文件，将请求转发到不一样的地址。

2. 若以构建工具的方式，则是经过构建工具启动的server自带的proxy将请求转发出去。

 

接下来详细介绍使用构建工具转发请求的方式。

 

以Webpack为例，经过proxy，Webpack server会过滤请求，将带有配置的路径的请求，转发到须要转发的服务器。

 

当代码须要部署在tomcat中时，因为不一样项目在Webapp中的前端文件名称可能不一样，每当Webapp中的应用更更名称，前端都须要更改ajax的路径，很是麻烦。

 

有一种方法能够一劳永逸的解决这个问题。使用NPM build以前，在你的package.json文件中，加上homepage变量来写明你的服务的绝对路径。

 

npm在build的过程当中，默认前端代码就在服务的根路径下，想要重写这个路径，能够在package.json中加入上面的homepage，即可重写。若不想设置固定的路径，则能够用下图实例：

 

3、EOS8前端工程化设计实践分析

 

以咱们的技术团队目前正在研发的EOS8的前端设计为例，讲一讲前端工程化的实践。

 

EOS8平台的目标是提供一整套微服务应用平台与应用全生命周期管理平台，可以提供企业快速构建数字化需求交付的能力。

 

EOS8与咱们正在研发的另外一款产品DevOps都遵循先后端分离、前端模块化的开发方式进行开发。这样作的好处是可以方便多地同事同时进行开发，减小沟通维护成本，同时保证后期的可扩展性。另外，先后端分离，也是微服务系统比较好的实践。

 

抛开框架之争，结合EOS8的前端设计，来分析从开发到部署的整个生命周期过程，主要从如下三点来考虑：

 

1）须要根据需求，考虑清楚页面的路由实现方式，同时从功能角度具体分类各个功能模块。

 

2）因为平台功能的可添加性很是强，故页面设计须要符合模块化设计，方便后期添加新的功能模块，同时在开发的过程当中，须要将ui组件公共化，标准化，方便后期开发。

 

3）前端代码的架构要考虑最终上线的部署方式，同时也要方便开发人员进行开发。

 

1.模块化开发

 

首先，前端工程化的第一步，要先划分清楚前端的功能模块。功能模块之间不能耦合。这样的好处是，不一样团队能够同时进行开发，最终将各自开发的模块合入便可。模块的开发遵循统一的开发标准。数据能够经过flux来管理。

 

 

咱们做了以下的模块划分：

 

• 平台状态监控。

• 用户认证，组织机构管理等。

• 应用节点配置进行更改，并进行灰度发布等。

• 应用下各个状态的监控。

• 不一样应用进行统一管理的能力。

• 对应用提供Api Gateway。

 

 

 

2.模块化路由及页面设置

在这里，模块化主要从路由模块化和页面模块化两个方面来设计。

路由模块化，能够解决父子模块嵌套问题，在单向数据流的框架中，这一点尤其重要。同时，经过路由嵌套，规范页面URL，使整个前端路由清晰，具备方便跳转、传参等优点。

页面模块化则能够提升页面组件的复用率，减小重复的代码。

• 路由模块化：整个平台能够分为6大模块，每一个模块分配一个路由地址，经过路由地址找到不一样的模块。图中展现的是一级路由地址，以下图所示：

 

• 页面模块化：就单个页面而言，页面须要按照组件的方式组成。为了可以减小组件的复杂性，，能够划分为Container Components以及Presentation Components。

 

1. Container Components主要用于承载各个不一样的公共组件，起到必定布局的功能。同时，他负责与服务端进行通讯，获取页面所需的数据，传给Presentation Components。

2. Presentation Components主要用于具体的功能组件。它通常不参与数据的交互，只负责展现Container传给他的数据。这样能够达到最大的复用这个组件

 

如图所示，页面由Header，SideBar，Content三个组件组成，而每一个组件，可由多个小的公共组件组成，以下图所示：

 

3.部署实践

 

在这里，模块化主要从路由模块化和页面模块化两个方面来设计。

 

路由模块化，能够解决父子模块嵌套问题，在单向数据流的框架中，这一点尤其重要。同时，经过路由嵌套，规范页面URL，使整个前端路由清晰，具备方便跳转、传参等优点。

 

页面模块化则能够提升页面组件的复用率，减小重复的代码。

 

路由模块化：整个平台能够分为6大模块，每一个模块分配一个路由地址，经过路由地址找到不一样的模块。图中展现的是一级路由地址，以下图所示：

 

前端部署的方案有两种：

 

• 先后端分离方式，经过nginx转到后台。这种方式不须要关注前端文件的路径问题。

   

• 混合模式下，前端代码会放到tomcat中，Ajax以及静态资源须要关注路径问题。

图中左侧为先后端分离的简易方案。具体部署时，经过nginx，能够进行负载均衡，同时能够部署多台nginx服务器。若是性能仍旧没法知足，则可使用LVS+F5/LVS+Nginx等多种方式进行负载均衡。

 

图中右侧为最传统的部署方式，将前端编译工具打包出来的文件，放入tomcat中便可。

 

不一样应用场景下，负载均衡的方案有不少，要根据实际的应用场景来选择适合本身的方案。这里咱们的前端架构，只要在打包时，根据不一样的部署方案，将前端文件的路径问题、ajax路径问题解决便可。

 

4、展望与总结

• 展望

   

微前端这个术语，最初来源于ThoughtWorks公司的技术雷达。传统的微服务架构下的前端：

 

微前端的核心思想如图所示（图片来源于网络）

 

微前端的理念，是将一个网站当成一个组件的合成体，每一个组件由一个独立的团队负责。带来的好处是每个团队在选择和升级他们的技术栈时，并不须要与其余团队进行统一，同时代码不依赖于共享状态和全局的变量。

 

这听起来很美好，不过目前微前端大致上还停留在概念的阶段，具体实施起来困难重重，光是框架之间的壁垒，就难以突破。

 

也许在某天，技术大牛们终将打破技术的壁垒，实现微前端，让咱们拭目以待。

 

• 总结

 

经过前端的展望，能够看出来，在将来，框架将再也不限制前端架构，再也不制约前端开发人员。人们能够根据本身的业务，选择不一样的框架，最后将各个业务模块组合起来。人们须要关注的核心，是如何将前端工程化，如何合理的将业务模块化、如何合理的分配路由，如何更快的进行开发等。

 

不管采用哪一种前端框架，前端开发的本质思路是同样的。学习前端，搭建前端项目，不该只关注具体的框架，更多要从前端工程化的角度出发去实现项目。这样才能使前端项目拥有更短的开发周期，更好的用户体验，更绚丽的页面效果。

 

关于做者：王若林，普元SOA&云计算部门高级前端工程师，曾在Tibco以及海航科技担任前端工程师，参与开发Tibco Api Gateway、海航商店、海航IAM等项目。现主要从事普元EOS微服务管理平台开发设计工做。

 

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享，长按二维码关注