分利宝前端开发模式

[lesonwu]

前言

  近几年，随着前端的发展，react、vue、angular等框架炙手可热，成为众多从业者追捧的对象，也已经成为前端开发者必get的技能。公司之前也用vue做过移动端的项目，对于这个轻量级的框架，一开始也用的得心应手，爱不释手。但是随着开发的深入，还有产品业务开发的要求，发现vue的缺点也越来越明显。比如，页面复杂程度越高，首屏加载速度慢；单页面不能用浏览器的前进后退功能，需要自行实现前进后退；SEO不友好...在最近的一次需求开发中，产品同事要求对SEO做优化，瞬间让人非常捉急，费劲心思。不知道你是否也遇到过以上开发的问题？有没有一种更好的前端模式能做到前后分离，又能解决以上的问题？

  先看看，目前市场上存在的前端开发模式。

一、开发模式的对比

MVC时代

• 制作静态页面，css和页面js效果，解决兼容性
• 问题：前后端不分离，代码耦合度较高，前后端沟通麻烦

  MVC模式时代，现在还有有一些项目使用这种模式，最显著的缺点就是前后端不分离，前端开发人员只需要写好静态页面，然后交由后端人员去套数据，或许前端人员直接撸jsp代码，那种心塞也许只有经历过的人才会明白。

MVVM时代

• 页面样式，数据请求，数据处理，数据呈现
• 问题：seo不友好，页面的速度比mvc慢，客户端压力大

  这里分析一下MVVM这种模式，如果你是前端开发人员，对于这种开发模式应该不陌生，主流的前端框架react、vue大多采用这种方式实现前后端分离，前端与后端的人员通过api实现数据交互，前端负责页面呈现，跟数据逻辑，后端人员只需关注业务层面。

  当我们在客户端打开一个网页，首先通过http请求到存放前端文件的服务器，请求到前端的文件资源，返回给客户端，客户端通过解析拿到的资源文件，比如，html、css，组件DOM元素，渲染页面；当解析js时，再次动态渲染DOM元素；如果js文件中有ajax请求，会通过api请求到后端服务器，拿到数据后返回给客户端，再次渲染页面。由此可见，用户打开一次页面，需要渲染3次，如果需要解析的文件较大较复杂，解析的过程会比较缓慢，严重影响首屏的加载速度，给客户端带来很大压力，如果网络较差，用户体验也非常不好。
  另一方面，seo（搜索引擎优化），搜索引擎是通过爬取页面、关键字进行搜索，但是在vue项目中，是由一个js去生成一个整个页面，整个网站只有一个页面，造成seo问题。

  通过分析，能看出前两种模式的优缺点明显，这2种模式，也是本人在公司的项目迭代中所经历过的阶段，如人饮水啊，对此，本人深有体会。为了解决以上的问题，追求更好的开发体验以及更高的性能，我们司决定使用中间层的前端开发模式，来改变以上模式所出现的问题。那么如何搭建一个中间层呢？

二、Node作为中间层模式

  如下图所示，以Node作为中间层，当客户端打开一个网站时，先请求到node服务器这一层，通过node服务器转发请求到后端的服务器，获取数据，然后返给node的模板引擎，根据视图模板渲染好模板字符串页面，再返回给客户端，直接展示页面。

  这样页面的渲染工作放在了服务端，速度非常快，不用等到客户端加载的时候，再去请求数据，而且有些数据也可以放在Node层去处理，比如说数据格式、过滤、加密等，也提高了网站的安全性。

三、进一步的优化

  对于前端的优化，我们往往都只停留在对文件压缩、缓存等方面进行优化，但是这些优化其实对服务器的优化来说，九牛一毛，所以我们思考着如何进一步提高网站的性能和吞吐量？负载均衡策略，不止可以应用于后端，前端也可以。

1.负载均衡器-Nginx

  Nginx是一个高性能的WEB服务器和反向代理服务器，最常用的软件负载均衡器。
  当访问量比较大时，频繁的请求，会给服务带来很大压力，通过负载均衡、分流，减轻服务器的压力；另一方面，网站部署在多台服务器，当某台服务器故障的时候，可以马上切换到其它服务器，还能保证网站能正常访问，这就是负载均衡的优势。

接下来看下，在配置文件如何配置：

1. 1.访问页面时，代理转发

upstream wap.fenlibao.com {
    ip_hash;
    server 反向代理地址一 : 端口 weight=5;    #反向代理服务地址加端口，权重配置
    server 反向代理地址二 : 端口 weight=5;
    ...
    #session_sticky;
}

server {
        listen   端口;
        server_name  服务地址一 ;    #分利宝官网前端
        proxy_http_version 1.1;
        #return         301 https://$server_name$request_uri;
        #rewrite ^ https://$http_host$request_uri? permanent;
        access_log  /data/logs/slb.wap.fenlibao.com/access.log  main;
        error_log   /data/logs/slb.wap.fenlibao.com/error.log;
        location / {      #将所有请求转发给代理服务器集群去处理
             error_page 405 =200 http://$host:90$request_uri;
             proxy_pass http://wap.fenlibao.com;
         }
}

1. 2.请求api时，代理转发

upstream ***.fenlibao.com {
    ip_hash;
    server Node代理服务器一 : 端口 weight=5;
    server Node代理服务器二 : 端口 weight=5;
    ...
    #session_sticky;
}
server {
        listen   端口;
        server_name  Node代理服务器一;
        proxy_http_version 1.1;
        access_log  /data/logs/***.fenlibao.com/access.log  main;
        error_log   /data/logs/***.fenlibao.com/error.log;
        location / {      #将所有请求转发给Node代理服务器集群去处理
             proxy_pass http://***.fenlibao.com;
         }
}

2.redis缓存

  当前端跟后端拿数据的时候，每次都要发起重新发起http请求，重复的请求会消耗服务器的性能。这是我们就可以用到redis缓存，将请求回来数据缓存到内存中，下次发起请求的时候，就可以直接redis里面拿，这样我们的速度又提高了一步。那么这样就会出现一个问题，如何做到后端数据更新同步呢？启动app的时候，先后端发送一个请求，这个请求包含每个页面的资源标识符，后端判断一下这个标识符是否是最新的，从而判断数据是否需要更新，从而更新redis的数据。

四、总结

  中间层已经为越来越多的大公司所应用，像淘宝、facebook等。进入中间层后，前端能做的事情越来越多，将触角伸向了服务器，除了前后端分离外，还能做redis缓存，负载均衡策略。另一方面，不止是node能做中间层，PHP也可以，因为node是用js写的，node的生态很成熟，对于前端人员来说，比较容易上手。本人以个人在公司项目的实践而分享，希望对你的项目开发模式、选型有所帮助。

• 技术随业务发展而发展

• 技术选型上，不仅是技术本身，还要考虑团队能力

• 行业变化快，需要不断学习技术，拓宽自己的视野