千万级用户网站门户前端设计
对于千万级的注册用户的门户项目是前端这块是怎么去实现的,自己在平常的工作中总结了一些经验,也是在不断的挫折中,不断演练的,希望总结出来给大家参考下,和大家一起探讨,一起进步。
一、门户设计一般会遇到哪些难点
(一)、首页打开时间太慢了
在开发一个门户到生产上线后,首页响应时间是检验门户整个系统架构以及开发的重要的一项指标,有时候我们发现在公司测试发现速度都挺快的,怎么到生产首页打开就慢了呢?
(二)、页面加载不流畅,总感觉看着不舒服
因为门户一般都是偏向于内容和图片类资源比较多,但是我们打开自己的网页,有时候总感觉加载并不是按照我们期望的那样加载得到,顺其自然,总感觉看起来怪怪的。
(三)、希望用户缓存的地方未进行缓存
很多静态的前端资源,其实在系统未进行更新时候,第一次加载之后,希望缓存到用户的本地,但是因为缓存策略没搞好,经常未进行有效的缓存。
(四)、页面的头部尾部经常需要被第三方嵌入
因为作为一个比较大的门户站点,可能会让很多小的服务接入进来,但是头部和尾部因为是需要保持风格统一,所以经常需要被第三方进行嵌入。
(五)、代码没有进行有效的压缩,导致被窃取
因为作为门户站点,前端如果不进行加密的话,代码很容易被别人进行抄袭伪造,而且还很容易清楚里面的业务逻辑,从而很容易仿造和进行攻击。
(六)、增量静态资源发布
经常门户线上环境需要增加一点小功能,但是我们又不想去整个版本的迭代更新,这时候我们可能需要增量更新一部分代码,但是因为加密压缩,这时候该怎么解决呢?
(七)、门户的轮播图,运营位图片那么多,该怎么提升加载速度呢?
我们经常在门户上面能看到很多的图片,但是这些图片却大大的拖慢了整个网站的加载速度,怎样去很好的处理这些图片资源呢,你考虑过么?
(八)、大家都知道门户需要做静态化,但是静态化方案那么多,哪一种合适呢?
门户的静态方案随着前端技术的发展,从最开始的freemark等后端java类模板,到客户端的渲染模板,但是他们各自有什么优势?该怎么选型?
(九)、需要开发多端,工作量大
二、整体设计
设计图 基础架构
上图主要说明了大型门户中常用到的一些技术,说明如下:
(一)、CDN :
假设我们的服务器都部署在合肥的机房,对于安徽的用户来说访问是较快的,而对于新疆的用户访问是较慢的,这是由于合肥和新疆分别属于电信和联通的不同发达地区,新疆用户访问需要通过互联路由器经过较长的路径才能访问到合肥的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。
(二)、反向代理 :
部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续访问应用服务器获取,这样做减少了获取数据的成本。反向代理常用Nginx。
(三)、硬负载 :
应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。
其中包括硬负载和软负载,硬负载常用的负载均衡技术硬件的有F5,价格比较贵一般都在15W以上。软件的有LVS、Nginx、HAProxy。LVS是四层(传输层)负载均衡。
(四)、使用NoSql数据库和搜索引擎:
对于海量数据的查询和分析,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有lucene、solr、elasticsearch。
(五)、 消息队列:
随着业务的扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。
(六)、分布式文件系统:
用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。而我们业务线主要用FASTDFS。
三、前端功能性设计
(一)、多页和单页的选择
门户网站推荐使用多页架构。
理由如下:
多页项目,页面和页面之间是独立的,不存在交互,因此当一个页面需要单独重构时,不会影响其他页面,对于有长期历史的项目来说,可维护性、可重构性要高很多;
多页项目可以单次只更新一个页面的版本,而单页项目如果其中一个功能模块要更新(特别是公共组件更新),很容易让所有页面都需要更新版本;
多页项目的版本控制更简单,如果需要页面拆分,调整部分页面的使用流程,难度也会更低;
灰度发布更友好;
优点:
1、降低长期项目迭代维护的难度;
2、方便增量资源更新,以及缓存内容按照页面缓存,不会整体缓存。
(二)、考虑多端,并规范多端共用一套接口,注册接口平台服务
常见方案如下:
后端提供的接口,应该同时考虑包含PC和H5的数据(即单独对一个存在亢余数据);
接口应当稳定,即当业务变更时,应尽量采取追加数据的形式;
只有在单独一端需要特殊业务流程时,设计单端独有接口;
多端共用接口,是减少开发工作量,并且提高业务可维护性的重要解决方案。
优点:
1、降低开发工作量,增强可维护性。
2、页面可以通过响应式设计,部分页面可以减少开发工作量。
(三)、负载均衡使用nginx
负载均衡通常使用Nginx比较多。当遇见大型项目的时候,负载均衡和分布式几乎是必须的。前端主要是对于静态资源服务来说,负载均衡有以下好处:
降低单台server的压力,提高业务承载能力;
方便应对峰值流量,扩容方便(如举办某些活动时);
增强业务的可用性、扩展性、稳定性;
负载均衡已经是蛮常见的技术了,好处不用多说,很容易理解。
优点:
1、增强业务的可用性、扩展性、稳定性,可以支持更多用户的访问。
2、通过静态资源代理,可以增加缓存,提升加载速度。
(四)、考虑使用CDN
用户来自不同地区,加入CDN可以使用户访问资源时,访问离自己比较近的CDN服务器,降低访问延迟;
降低服务器带宽使用成本;<