千万级用户网站门户前端设计

对于千万级的注册用户的门户项目是前端这块是怎么去实现的,自己在平常的工作中总结了一些经验,也是在不断的挫折中,不断演练的,希望总结出来给大家参考下,和大家一起探讨,一起进步。

一、门户设计一般会遇到哪些难点

(一)、首页打开时间太慢了

在开发一个门户到生产上线后,首页响应时间是检验门户整个系统架构以及开发的重要的一项指标,有时候我们发现在公司测试发现速度都挺快的,怎么到生产首页打开就慢了呢?

(二)、页面加载不流畅,总感觉看着不舒服

因为门户一般都是偏向于内容和图片类资源比较多,但是我们打开自己的网页,有时候总感觉加载并不是按照我们期望的那样加载得到,顺其自然,总感觉看起来怪怪的。

(三)、希望用户缓存的地方未进行缓存

很多静态的前端资源,其实在系统未进行更新时候,第一次加载之后,希望缓存到用户的本地,但是因为缓存策略没搞好,经常未进行有效的缓存。

(四)、页面的头部尾部经常需要被第三方嵌入

因为作为一个比较大的门户站点,可能会让很多小的服务接入进来,但是头部和尾部因为是需要保持风格统一,所以经常需要被第三方进行嵌入。

(五)、代码没有进行有效的压缩,导致被窃取

因为作为门户站点,前端如果不进行加密的话,代码很容易被别人进行抄袭伪造,而且还很容易清楚里面的业务逻辑,从而很容易仿造和进行攻击。

(六)、增量静态资源发布

经常门户线上环境需要增加一点小功能,但是我们又不想去整个版本的迭代更新,这时候我们可能需要增量更新一部分代码,但是因为加密压缩,这时候该怎么解决呢?

(七)、门户的轮播图,运营位图片那么多,该怎么提升加载速度呢?

我们经常在门户上面能看到很多的图片,但是这些图片却大大的拖慢了整个网站的加载速度,怎样去很好的处理这些图片资源呢,你考虑过么?

(八)、大家都知道门户需要做静态化,但是静态化方案那么多,哪一种合适呢?

门户的静态方案随着前端技术的发展,从最开始的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服务器,降低访问延迟;

降低服务器带宽使用成本;

支持视频、静态资源、大文件、小文件、直播等多种业务场景;

消除跨运营商造成的网络速度较慢的问题;

降低DDOS攻击造成的对网站的影响;

CDN是一种比较成熟的技术,各大云平_台都有提供CDN服务,价格也不贵,因此CDN的性价比很高。

优点:

1、增加用户访问速度,降低网络延迟,带宽优化,减少服务器负载,增强对攻击的抵抗能力。

(五)、前后端分离

建议前端负责所有静态资源的开发,后端负责所有服务的开发;前端通过前端工程化来完成前端静态资源的编译和处理工作,同时像VUE等脚手架也提供了工具。

优点:

1、更规范的进行页面管理,降低页面和功能的耦合度,减少复杂页面的环境配置时间,以及方便栏目拼接。

2、方便进行页面的工程化处理,包括合并,压缩,加密等;

(六)、支撑内容和栏目可以配置

提供内容和栏目渲染的基础组件,支持这些可复用的内容可以进行可配置,减少后期运维的成本。

门户开发前期,一定要梳理出后期可能调整的地方,从而最大限度的进行配置。

优点:

1、 页面调整时候更加灵活,方便定制化;

(八)、静态化;

能够对数据进行静态化,在服务端进行页面的渲染。

正常情况调用接口接口,异常转向静态数据。

可以通过静态页存储,采用定时更新机制减轻服务器负担,首页每个小模块可以通过oscache进行缓存,这样不用每次拉数据。

优点:

1、 能够很大程度上提升页面以及首页的加载速度;

(九)、缓存机制

对头部导航、用户信息等内容进行缓存,静态的数据进行缓存,定期更新。

常见解决方案:

直接将资源文件名使用文件摘要或者说某个固定的字符串加上一个文件摘要拼接成一个文件名。

好处有以下几点:

首先发资源文件,由于文件名已经不一样了,所以不会覆盖掉之前存在的资源文件,客户端依旧可以安全的访问。

再发客户端文件,在客户端文件一旦发布成功,那么就会立马切成新的特性,中间可以做到无缝衔接。这就是所谓的非覆盖发布的方案。

(十)、基础组件库的建设

梳理门户常见的组件,并形成统一的UI组件库,从而更加优化的交互,以及方便后面升级。

门户常用的组件不多,但是需要梳理出规范,这样便于第三方接入。

优点:

1、 方便页面展示好看,并且方便第三方接入。

(十一)、浏览器兼容

兼容性考虑统一解决方案,避免bug的重复产生。

常见解决方案:

配置postcss,让某些css增加兼容性前缀;

写一个wepback的loader,处理某些特殊场景;

规范团队代码,使用更稳定的写法(例如移动端避免使用fixed进行布局);

对常见问题、疑难问题,总结解决方案并团队共享;

建议或引导用户使用高版本浏览器(比如chrome);

优点:

1、避免浏览器环境产生的bug,以及排查此类bug所浪费的大量时间。

(十二)、考虑响应式设计

尽量支持响应式布局,方便在移动设备上显示。

优点:

1、为后期多端开发提供支撑。

(十三)、采用静态资源部署方式

为了前端静态资源方便维护和升级,建议分开部署,和服务端tomcat容器不要部署在一起。

利用nginx分向,使用之前对接完成的地址+新增一个独立上下文,然后nginx拦截执行到tomcat外层静态文件,原请求上下文依然使用nginx指向到tomcat调用接口。

优点:

1、 提升静态资源响应速度。

四、非功能性需求

(一)、安全管理

安全管理的很难从架构设计上完全避免,但还是有一定解决方案的,常见安全问题如下:

XSS注入:对用户输入的内容,需要转码(大部分时候要server端来处理,偶尔也需要前端处理),禁止使用eval函数;

https:这个显然是必须的,好处非常多;

CSRF:要求server端加入CSRF的处理方法(至少在关键页面加入);

优点:

1、减少安全漏洞,避免用户受到损失,避免遭遇恶意攻击,增加系统的稳定性和安全性。

(二)、埋点系统

强烈推荐前端做自己的埋点系统。这个不同于后端的日志系统。

前端埋点系统的好处:

记录每个页面的访问量(日周月年的UV、PV);

记录每个功能的使用量;

捕捉报错情况;

图表化显示,方便给其他部门展示;

埋点系统是前端高度介入业务,把握业务发展情况的一把利剑,通过这个系统,我们可以比后端更深刻的把握用户的习惯,以及给产品经理、运营等人员提供准确的数据依据。当有了数据后,前端人员就可以针对性的优化功能、布局、 页面交互逻辑、用户使用流程。

埋点系统应和业务解耦,开发人员使用时注册,然后在项目中引入。然后在埋点系统里查看相关数据(例如以小时、日、周、月、年为周期查看)

优点:

1、数据是money,数据是公司的生命线,数据是最好的武器。

以上一些点是我们在门户开发中常注意的点,来解决交互,性能和安全方面的问题。

原文地址:https://www.cnblogs.com/guchengnan/p/12004655.html

时间: 2024-10-03 14:14:45

千万级用户网站门户前端设计的相关文章

千万级用户的大型网站,应该如何设计其高并发架构?

目录 (1)单块架构 (2)初步的高可用架构 (3)千万级用户量的压力预估 (4)服务器压力预估 (5)业务垂直拆分 (6)用分布式缓存抗下读请求 (7)基于数据库主从架构做读写分离 (8)总结 本文将会从一个大型的网站发展历程出发,一步一步的探索这个网站的架构是如何从单体架构,演化到分布式架构,然后演化到高并发架构的. 一.单块架构 一般一个网站刚开始建立的时候,用户量是很少的,大概可能就几万或者几十万的用户量,每天活跃的用户可能就几百或者几千个. 这个时候一般网站架构都是采用单体架构来设计的

设计千万级用户量网站的高并发架构!!!

(1)单块架构 网站开始建立时,用户少 , 网站架构都是用单体架构设计,共部署3台服务器,1台应用,1台数据库,1台图片. 1.应用服务器上发布,可能是把应用服务器上的Tomcat给关掉,替换系统的代码war包,重新启动Tomcat. 2.数据库服务器,存全部核心数据. 3.网络文件系统(NFS)作图片服务器,存网站全部图片.应用服务器上代码会连接以及操作数据库以及图片服务器. 如下图所示: 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障

从0到千万级访问量网站架构演变史

从0到千万级访问量网站架构演变史 read it later. 架构演变第一步:物理分离webserver和数据库最 开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候已 经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这 个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问

谈谈运行稳定性好效率高的千万级大型网站系统架构性分析

千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下select.delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题.另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的.索引和更新是一对天生的冤家. 高并发死锁:平时我们感觉不到,但数据库死锁在高并发的

亚马逊AWS在线系列讲座——如何在AWS云平台上构建千万级用户应用

用户选择云计算平台来构建应用的一个重要原因是云平台的高弹性和高扩展性.面向互联网的应用往往需要支撑大量用户的使用,但是构建一个高扩展性的.高可用的应用具有一一定的挑战,不过基于AWS云平台来构建应用可以相对简化这个事情.这个在线讲座将讨论如何如何充分利用云平台的特性和AWS的相关服务来构建一个可以支撑千万级用户的应用.通过讨论不同用户数量级别的应用需求和架构特点,然后结合不同的AWS的服务来满足用户访问,并最终逐渐把架构优化成为可以支持千万级用户的设计.这个演讲的目的是帮助对AWS服务有一定基础

【AWS+Drupal应用案例】如何让一个千万级流量网站从一直挂机到起死回生?

BootDev成立之初,旨在为大网站提供自动部署解决方案.我们的优势,简单通俗地讲,便宜且快:专业地说,我们让大网站以低成本,快速度交付内容!我们有能力在客户自己的AWS账号下部署一个自动伸缩架构,支持高流量高可用,减省网站使用云的学习周期和使用风险. BootDev拥有7年的Drupal经验,Drupal也是我们最擅长的东西之一.众所周知,Drupal以其极高性能要求著名,却同样也是世界上最难的开源CMS,这个没有之一.大言不惭地说,BootDev都能把Drupal做好,还有其他什么网站做不好

千万级PV网站架构

1 架构背景 CleverCode了解了一下架构.现在的情况是:一共约有50台服务器,安装的服务nginx,mysql,memcached,squid,solor等. 现在日均纯PHP访问的PV是2500万,最高峰值可以抗住5000万访问. 以下只列出来一些常用域名,部分访问域名未列出来,其中的机器也只列出来部分. 2 架构原理图 3 架构原理说明 3.1 LVS部分 1)首先让所有的域名都通过DNS指向211.181.168.168.211.181.168.168是一个外网IP.对于LVS结构

浅谈千万级PV/IP规模高性能高并发网站架构

高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”. 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.能访问静态服务器的,就不要去 访问动态服务器.以此类推:能不访问数据库和存储就一定不要去访问数据库和存储. 说起来很轻松,实际做起来却不容易,但只要稍加努力

浅谈千万级PV/IP规模高性能高并发网站架构(转自老男孩)

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://oldboy.blog.51cto.com/2561410/736710 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.能访问静态服务器的,就不要去访问动态