Ten million user Web portal front-end design

For ten million registered users of the portal project is a front-end to achieve this is how he summed up some experience in ordinary work, is in constant frustration, and continue to exercise, summed up hope for your reference, and explore together, progress together.

 

First, the portal design which generally encounter difficulties

(A) Home opening time is too slow

After developing a portal to the production line, the response time is an important home an indicator of the overall test system architecture and the development of the portal, sometimes we find in the company's testing found that speed came fast, how to produce home opened to slow it ?

(B), the page loads is not smooth, the overall feel uncomfortable watching

Because portals are generally biased in favor of more content like pictures and resources, but we have to open their own web pages, and sometimes not in accordance with the general feeling load load as we expect to get, go with the flow, always feel looks strange.

(Iii), where not want users to cache cache

After a lot of static front-end resources, in fact update when you first load is not in the system, want the cache to the user's local, but the strategy did not do a good job because the cache, the cache is often not effective.

(D), the head of the tail of the page often need to be embedded in third party

Because as a larger portal site, it may make a lot of small service access in, but the head and tail because it is the need to maintain a unified style, so often need to be embedding a third party.

(E), the code is not efficient compression, resulting in stolen

Because as a portal site, and the front end if not encrypted, then the code can easily be copied others were forged, and very easy to know which business logic, making it easy to counterfeit and attack.

(Vi), the incremental static resource publishing

Portal online environment often need to add a little feature, but we do not want to update the entire iterative version, this time we may need to update the incremental portion of the code, but because the encryption compression, this time how to solve it?

(Seven), portal carousel view operation bit images so much, how to enhance the loading speed of it?

We often see a lot of the portal above the pictures, but these pictures has greatly slow down the loading speed of the entire site, how to deal with these good picture of it resources, you thought about it?

(Eight), we all know needs to be done static portals, but still so many schemes, which one is better?

Static scheme portal with the development of front-end technology, from back-end java class template freemark the beginning, to the client rendering templates, but they each have what advantage? How the selection?

(Ix) the need to develop multi-terminal heavy workload

 

Second, the overall design

 

Ten million user Web portal front-end design

 

Infrastructure design

The figure illustrates a large main portal to a number of techniques commonly described as follows:

(A), CDN:

Suppose our servers are deployed room in Hefei, Anhui for users who access is faster, and for users to access Xinjiang is slow, which is due to Hefei and Xinjiang Telecom and China Unicom, respectively, belong to different developed areas, Xinjiang user access need to go through a longer path to access the Internet through the router to the server Hefei, the return path is the same, so the data transmission time is relatively long. In this case, often used to solve CDN, CDN content caching data to the operator's room, starting with the most recent acquisition of data when users access operators, thereby greatly reducing the network access path.

(B), the reverse proxy:

Deployed at the site of the room, when a user requests access to reach the first reverse proxy server, the reverse proxy server will cache data back to the user, if the cost is not cached data will continue to get access to the application server, this reduces access to data . Reverse proxy commonly used Nginx.

(III) hard load:

Application server as a portal, it will take a lot of requests, we tend to share the number of requests by the application server cluster. In front of the application server load balancing server deployment scheduling a user request, according to distribution policy to distribute requests to the plurality of application server nodes.

Including hard and soft load load, load commonly used hard load balancing hardware, F5, they are generally more expensive than 15W. Software has LVS, Nginx, HAProxy. LVS is four (the transport layer) load balancing.

(D), using NoSql databases and search engines:

For inquiries and analysis of massive data, we use nosql database plus search engines can achieve better performance. Not all data should be placed relational data. Commonly used NOSQL have mongodb, hbase, redis, search engines have lucene, solr, elasticsearch.

(E), the message queue:

As the business expanded, the application has become very bloated, then we need to split the business application. Each business application responsible for independent business operations. Achieved between the business communication or message via the shared database.

(Six), Distributed File System:

用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有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);

记录每个功能的使用量;

捕捉报错情况;

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

Buried front-end system is highly involved in the business, grasp a sword business development through this system, we can grasp the user's habits deeper than the rear end, as well as to product managers, operators and other personnel to provide accurate data basis. When the data, it can flow distal to use targeted optimization, layout, interaction logic page, the user.

Buried systems and services should be decoupled, when developers registered, and then introduced in the project. Then view the data in the buried point system (for example, hour, day, week, month, year view for the period)

advantage:

1, data is money, data is the lifeblood of the company, data is the best weapon.

 

Some of the above point to note is that we often point in portal development, to solve the problem interaction, performance, and security.

Guess you like

Origin www.cnblogs.com/guchengnan/p/12004655.html