翼支付门户架构讲解
文章平均质量分 74
lichunan
这个作者很懒,什么都没留下…
展开
-
利用Idea创建web项目
1、原创 2014-10-28 09:54:08 · 690 阅读 · 0 评论 -
关于大型网站技术演进的思考(十一)--网站静态化处理—动静分离策略(3)
前文里我讲到了网站静态化的关键点是动静分离,动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路。由此可见,网站静态化处理的核心就是动静分离和缓存两大方面,上篇我简单讲述了动静整合的基础知识,本篇将会讲述两大核心之一的动静分离策略,只有把动静分离策略做好了,缓存才能发挥出它转载 2015-03-16 09:35:59 · 350 阅读 · 0 评论 -
关于大型网站技术演进的思考(十二)--网站静态化处理—缓存(4)
上篇我补充了下SSI的知识,SSI是一个十分常见的技术,记得多年前我看到很多门户网站页面的后缀是.shtml,那么这就说明很多门户网站都曾经使用过SSI技术,其实现在搜狐网站也还在用shtml,如下图所示: 由此可见SSI在互联网的应用还是非常广泛的。其实互联网很多网页如果我们按照动静分离策略拆分,绝大部分都是可以当做静态资源处理,例如新闻网站,文学网站,这些网页生成后,大部分的资源都是不变转载 2015-03-16 10:08:52 · 385 阅读 · 0 评论 -
关于大型网站技术演进的思考(十五)--网站静态化处理—前后端分离—中(7)
上篇里我讲到了一种前后端分离方案,这套方案放到服务端开发人员面前比放在web前端开发人员面前或许得到的掌声会更多,我想很多资深前端工程师看到这样的技术方案可能会有种说不出来的矛盾心情,当我的工作逐渐走向越来越专业化的前端开发后,我就时常被这套前后端分离方案所困惑,最近我终于明白了这个困惑的本源在哪里了,那就是这套前后端分离方案其实是服务端驱动的前后端分离方案,它的实现手段又是从服务端的MVC架构体转载 2015-03-16 11:43:43 · 336 阅读 · 0 评论 -
关于大型网站技术演进的思考(十四)--网站静态化处理—前后端分离—上(6)
前文讲到了CSI技术,这就说明网站静态化技术的讲述已经推进到了浏览器端了即真正到了web前端的范畴了,而时下web前端技术的前沿之一就是前后端 分离技术了,那么在这里网站静态化技术和前后端分离技术产生了交集,所以今天我将讨论下前后端分离技术,前后端分离技术讨论完后,下一篇文章我将会以网站 静态化技术的角度回过头来重新审视下前后端分离技术,希望通过这种审视来加深我们对两套技术的理解。 前后端分 离转载 2015-03-16 11:31:01 · 348 阅读 · 0 评论 -
关于大型网站技术演进的思考(十三)--网站静态化处理—CSI(5)
讲完了SSI,ESI,下面就要讲讲CSI了 ,CSI是浏览器端的动静整合方案,当我文章发表后有朋友就问我,CSI技术是不是就是通过ajax来加载数据啊,我当时的回答只是说你的理解有点片面,那么到底什么是CSI技术了?这个其实要和动静资源整合的角度来定义。 CSI技术其实是在页面进行动静分离后,将页面加载分为两个步骤完成,第一步是加载静态资源,静态资源加载完毕后进行第二步骤加载动态资源。不过这个定转载 2015-03-16 11:03:29 · 334 阅读 · 0 评论 -
关于大型网站技术演进的思考(二):存储的瓶颈(2)
上篇里我讲到某些网站在高并发下会报出503错误,503错误的含义是指网站服务端暂时无法提供服务的含义,503还表达了网站服务端现在有问题但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误所致,如果生产系统里发现了500转载 2015-03-13 15:12:25 · 304 阅读 · 0 评论 -
关于大型网站技术演进的思考(三):存储的瓶颈(3)
存储的瓶颈写到现在就要进入到深水区了,如果我们所做的网站已经到了做数据库垂直拆分和水平拆分的阶段,那么此时我们所面临的技术难度的挑战也会大大增强。 这里我们先回顾下数据库的垂直拆分和水平拆分的定义: 垂直拆分:把一个数据库中不同业务单元的数据分到不同的数据库里。 水平拆分:是根据一定的规则把同一业务单元的数据拆分到多个数据库里。 垂直拆分是一个粗粒度的拆分数据,它主要是将原转载 2015-03-13 15:42:12 · 346 阅读 · 0 评论 -
关于大型网站技术演进的思考(一):存储的瓶颈(1)
前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的转载 2015-03-13 11:30:35 · 357 阅读 · 0 评论 -
关于大型网站技术演进的思考(四):存储的瓶颈(4)
如果数据库需要进行水平拆分,这其实是一件很开心的事情,因为它代表公司的业务正在迅猛的增长,对于开发人员而言那就是有不尽的项目可以做,虽然会感觉很忙,但是人过的充实,心里也踏实。 数据库水平拆分简单说来就是先将原数据库里的一张表在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个整体的表进一步拆分成多张表,每一张表都用独立的数据库进行存储。当表被水平拆分后,原数据表成为了一个逻辑转载 2015-03-13 17:11:21 · 272 阅读 · 0 评论 -
关于大型网站技术演进的思考(五):存储的瓶颈(5)
上文里我遗留了两个问题,一个问题是数据库做了水平拆分以后,如果我们对主键的设计采取一种均匀分布的策略,那么它对于被水平拆分出的表后续的查询操作将有何种影响,第二个问题就是水平拆分的扩容问题。这两个问题在深入下去,本系列就越来越技术化了,可能最终很多朋友读完后还是没有找到解决实际问题的启迪,而且我觉得这些问题都是像BAT这样巨型互联网公司才会认真思考的,因此本篇我打算换个角度来阐述本文的后续内容。转载 2015-03-13 19:47:30 · 276 阅读 · 0 评论 -
关于大型网站技术演进的思考(六):存储的瓶颈(6)
在讲数据库水平拆分时候,我列出了水平拆分数据库需要解决的两个难题,它们分别是主键的设计问题和单表查询的问题,主键问题前文已经做了比较详细的讲述了,但是第二个问题我没有讲述,今天我将会讲讲如何解决数据表被垂直拆分后的单表查询问题。 要解决数据表被水平拆分后的单表查询问题,我们首先要回到问题的源头,我们为什么需要将数据库的表进行水平拆分。下面我们来推导下我们最终下定决心做水平拆分表的演进过程,具体如转载 2015-03-13 20:09:10 · 370 阅读 · 0 评论 -
利用redis + lua解决抢红包高并发的问题
抢红包的需求分析 抢红包的场景有点像秒杀,但是要比秒杀简单点。 因为秒杀通常要和库存相关。而抢红包则可以允许有些红包没有被抢到,因为发红包的人不会有损失,没抢完的钱再退回给发红包的人即可。 另外像小米这样的抢购也要比淘宝的要简单,也是因为像小米这样是一个公司的,如果有少量没有抢到,则下次再抢,人工修复下数据是很简单的事。而像淘宝这么多商品,要是每一个都存在着修复数据的风险,那如果出故障了则很转载 2015-04-01 09:37:15 · 496 阅读 · 0 评论 -
关于大型网站技术演进的思考(九)--网站静态化处理--总述(1)
在存储瓶颈的开篇我提到像hao123这样的导航网站只要它部署的web服务器数量足够,它可以承载超大规模的并发访问量,如果是一个动态的网站,特别是使用到了数据库的网站是很难做到通过增加web服务器数量的方式来有效的增加网站并发访问能力的。但是现实情况是像淘宝、京东这样的大型动态网站在承担高并发的情况下任然能保证快速的响应,这其中有什么样的技术手段可以达到动态网站支撑高并发的场景了,这也许是每个做we转载 2015-03-15 22:51:39 · 285 阅读 · 0 评论 -
关于大型网站技术演进的思考(十)--网站静态化处理—动静整合方案(2)
上篇文章我简要的介绍了下网站静态化的演进过程,有朋友可能认为这些知识有点过于稀松平常了,而且网站静态化的技术基点也不是那么高深和难以理解,因此它和时下日新月异的web前端技术相比,就显得不伦不类了。其实当我打算写本系列的之前我个人觉得web前端有一个点是很多人都知道重要,但是有常常低估它作用的,那就是web前端和web服务端如何融合的这个点上,这个点再加上我们要做出一个规模庞大,高并发,快速响应的转载 2015-03-15 22:51:19 · 278 阅读 · 0 评论 -
关于大型网站技术演进的思考(八)--存储的瓶颈终篇(8)
在开始本篇主要内容前,我们一起看看下面的几张截图,首先是第一张图,如下图所示: 这是一家电商网站的首页,当我们第一次打开这个首页,网站会弹出一个强制性的对话框,让用户选择货物配送的地址,如果是淘宝和京东的话,那么这个选择配货地址的选项是在商品里,如下图是淘宝的选择配送地点: 那么图一跟京东和淘宝有什么区别呢?图一的电商强制用户选择地区后,那么我们在查询这个商品时候会因为地区转载 2015-03-15 21:46:22 · 666 阅读 · 0 评论 -
翼支付门户架构之搭建SpringMvc环境
本篇博文是在上篇原创 2014-10-29 14:50:07 · 1454 阅读 · 0 评论 -
翼支付门户架构之搭建spring+springmvc+springsecurity框架
1、项目结构如下:原创 2014-10-31 19:25:08 · 1472 阅读 · 0 评论 -
翼支付门户架构之spring security之自定义登陆页面
一、项目结构如下: 二、新建两个controller,一个是LoginLogoutController和MainController: LoginLogoutController: package com.bestpay.controller; import org.springframework.stereotype.Controller原创 2014-11-26 17:46:53 · 2302 阅读 · 0 评论 -
翼支付门户架构之Spring Security框架介绍
Spring Security3,其前身是“”转载 2014-11-21 16:56:56 · 926 阅读 · 0 评论 -
翼支付门户之JSP的GZIP实现
HTTP压缩可以大大提高浏览网站的速度,它的原理是,在客户端请求网页后,从服务器端将网页文件压缩,再下载到客户端,由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML、css、Javascript、Text,它可以节省40%左右的流量。更为重要的是,它可以对动态生成的,包括CGI、PHP、JSP、ASP、Servlet、SHTML等输出的网页也能进行压缩,压缩效率惊人。 目前原创 2014-12-17 18:04:48 · 976 阅读 · 0 评论 -
翼支付门户架构之redis安装
一、下载redis 本次部署测试采用的redis版本是redis-2.8.19.tar.gz; 二、安装redis 下载后解压 tar -zxvf redis-2.8.19.tar.gz到任意目录,例如/home/bppf_tools/redis/redis-2.8.19 解压后,进入redis目录 cd /home/bppf_tools/redis/redis-2.8.19 执原创 2014-12-19 16:26:51 · 1194 阅读 · 0 评论 -
翼支付门户架构之使用YUI Compressor优化你的网页
使用YUI Compressor优化你的网页 YUI Compressor是做什么的? 这个小工具主要是用来压缩CSS和JavaScript文件的,当然你觉得可以混淆这些文件里的代码也是可以的,不过我们使用它还是看中其压缩优化的功能。 为什么要优化? 因为这样可以减少网页传输中不必要的字节数,节省带宽,加快页面的访问速度。 使用YUI Compressor的好处? 方便快捷,压缩后的代原创 2014-12-23 15:41:22 · 1245 阅读 · 0 评论 -
翼支付门户架构之redis主从配置
环境描述: 主redis:172.25.132.21 6379 从redis:172.25.132.21 6380 1、将主从redis配置文件redis.conf中的“aemonize no”改为“yes”; 2、修改从redis配置文件redis.conf中的port 6379改为6380,添加slaveof 127.0.0.1 6379; 3、启动主从服务; 4、测试数据同步原创 2014-12-25 15:34:56 · 1260 阅读 · 0 评论 -
翼支付重构门户架构之主从切换
主从切换: 1、停止主redis: [root@esxi3v03 redis-2.8.19]# ps -ef | grep redis root 21436 1 0 Dec19 ? 00:00:00 src/redis-server *:6380 root 45105 1 0 16:47 ? 00:00:00 src/原创 2014-12-25 17:14:30 · 901 阅读 · 0 评论 -
翼支付门户架构之redis之RDB和AOF
Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。 AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文转载 2014-12-26 10:26:51 · 1051 阅读 · 0 评论 -
翼支付门户架构之redis高可用部署及监控
一、Redis Sentinel简介 Redis Sentinel是redis自带的集群管理工具,主要功能有 1、监控(Monitoring):Redis Sentinel实时监控主服务器和从服务器运行状态; 2、提醒(Notification):当被监控的某个Redis服务器出现问题时,Redis Sentinal可以向系统管理员发送通知,也可以通过API向其他程序发送通知; 3、自动故原创 2014-12-26 11:04:23 · 1538 阅读 · 0 评论 -
关于大型网站技术演进的思考(七)--存储的瓶颈(7)
本文开篇提个问题给大家,关系数据库的瓶颈有哪些?我想有些朋友看到这个问题肯定会说出自己平时开发中碰到了一个跟数据库有关的什么什么问题,然后如何解决的等等,这样的答案没问题,但是却没有代表性,如果出现了一个新的存储瓶颈问题,你在那个场景的处理经验可以套用在这个新问题上吗?这个真的很难说。 其实不管什么样的问题场景最后解决它都要落实到数据库的话,那么这个问题场景一定是击中了数据库的某个痛点,转载 2015-03-15 20:56:42 · 267 阅读 · 0 评论 -
翼支付门户CAS单点登录相关介绍
一、什么是CAS CAS及单点登录服务。用户只要到CAS认证一次,即可以在不同的平台应用中跳转,不需要二次输入密码。门户使用CAS是由于需要接入供应链平台。供应链平台主要为企业商户提供贷款服务,接入CAS后,商户通过门户登录后,可通过相应链接直接登录到供应链平台,而不需要进行二次登录;同时,门户注销登录后,供应链管理平台也将同步注销。 二、CAS的意义: 日后对于基于企业账户的平台应用都可以原创 2015-04-07 08:40:18 · 1586 阅读 · 0 评论