广州网站建造集团官网 老直营威尼斯网址开户
老品牌威尼斯网址开户 吾们 效劳 网站建造 移动应用 案例 报道 联系
咨询热线:13924135319

期待聆听您的声音

13924135319

不忽悠,不作恶,不欺诈;敬天理,存良知,思利他。
QQ咨询 QQ咨询 QQ咨询
广州总部 深圳 佛山 广西

与吾们一起分享美好

Web网站架构演变史

发布时间:2016-07-18 发布作者:老直营威尼斯网址开户 查阅次数:1572次 标签:网站架构

上言

互联网上有很多About网站架构的各种分享,有些主要是从运维和底子架构的角度去归纳的(堆机器,做集群),太关注 技术实现 细节实现,普通的开发人员基本看不太懂。吾们以javaweb为例,来搭建一个easy的电商系统,看看这个系统可以如何一步步演变。

该系统具备的功能:

阶段一、单机构建网站

网站的初期,吾们经常会在单机上跑吾们一切的程序和软件。此时吾们使用一个容器,如tomcat、jetty、jboos,然下直接使用JSP/servlet 技术实现 ,或者使用一些开源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis;末了再决定一个数据库管理系统来存储数据,如mysql、sqlserver、oracle,然下通过JDBC进行数据库的连接和操作。

把如该的一切软件都装载同一台机器上,应用跑起来了,也算是一个小系统了。此时系统结果如下:

阶段二、应用效劳器与数据库分离

随着网站的上线,访问量逐步上升,效劳器的负载慢慢提高,在效劳器还没有超载的时候,吾们应该就要做好准备,提升网站的负载能力。假如吾们代码层面已难以优化,在不提高单台机器的性能的环境下,增加机器是一个不错的方式,不单可以有效地提高系统的负载能力,而且性价比高。

增加的机器用来做什么呢?此时吾们可以把数据库,web效劳器拆分开来,这样不单提高了单台机器的负载能力,也提高了容灾能力。
应用效劳器与数据库分开下的架构如下图所示:

阶段三、应用效劳器集群

随着访问量继续增加,单台应用效劳器已经无法满足需求了。在假设数据库效劳器没有压力的环境下,吾们可以把应用效劳器从一台变成了两台甚至多台,把用户的请求分散到不同的效劳器中,易于 提高负载能力。多台应用效劳器之间没有直接的交互,他们都是依赖数据库各自对外供给效劳。著名的做易于 障切换的软件有keepalived,keepalived是一个类似于layer3、4、7交换机制的软件,他不是某个具体软件易于 障切换的专属品,而是可以适用于各种软件的一款产品。keepalived配合上ipvsadm又可以做负载均衡,可谓是神器。

吾们以增加了一台应用效劳器为例,增加下的系统结构图如下:


系统演变到这里,将会出现下面四个小case

  1. 用户的请求由谁来转发到到具体的应用效劳器
  2. 有什么转发的算法
  3. 应用效劳器如何返回用户的请求
  4. 用户如果每次访问到的效劳器不一样,so如何维护session的一致性

吾们来看看解决小case的Plan

1、第一个小case即是负载均衡的小case,一般有5种解决Plan:

1、http重定向。HTTP重定向就是应用层的请求转发。用户的请求莫过于已经到了HTTP重定向负载均衡效劳器,效劳器按照算法要旨用户重定向,用户收到重定向请求下,再次请求真正的集群

优点:easy。

缺点:性能较差。

2、DNS域名解析负载均衡。DNS域名解析负载均衡就是在用户请求DNS效劳器,获取域名对应的IP地址时,DNS效劳器直接给出负载均衡下的效劳器IP。

优点:交给DNS,不用吾们去维护负载均衡效劳器。

缺点:当一个应用效劳器挂了,不能及时通知DNS,而且DNS负载均衡的把握权在域名效劳商那里,网站无法做更好优质的改善和更强大的管理。

3、反向代理效劳器。在用户的请求到达反向代理效劳器时(已经到达网站机房),由反向代理效劳器按照算法转发到具体的效劳器。常用的apache,nginx都可以充当反向代理效劳器。

优点:部署easy。

缺点:代理效劳器可能成为性能的瓶颈,特别是一次上传大文件。

4、IP层负载均衡。在请求到达负载均衡器下,负载均衡器通过修改请求的鹄的IP地址,易于 实现请求的转发,做到负载均衡。

优点:性能更好。

缺点:负载均衡器的宽带成为瓶颈。

5、数据链路层负载均衡。在请求到达负载均衡器下,负载均衡器通过修改请求的mac地址,易于 做到负载均衡,与IP负载均衡不一样的是,当请求访问完效劳器之下,直接返回衣食父母。而无需再经过负载均衡器。

2、第二个小case即是集群调度算法小case,常见的调度算法有10种。

1、rr 轮询调度算法。顾名思义,轮询分发请求。

优点:实现easy

缺点:不揣摩每台效劳器的处理能力

2、wrr 加权调度算法。吾们给每个效劳器设置权值weight,负载均衡调度器按照权值调度效劳器,效劳器被调用的次数跟权值成正比。

优点:揣摩了效劳器处理能力的不同

3、sh 原地址散列:提取用户IP,按照散列函数得出一个key,再按照静态映射表,查处对应的value,即倾向效劳器IP。过倾向机器超负荷,则返回空。

4、dh 倾向地址散列:同上,只是Now提取的是倾向地址的IP来做哈希。

优点:如该两种算法的都能实现同一个用户访问同一个效劳器。

5、lc 最少连接。优先把请求转发给连接数少的效劳器。

优点:使得集群中各个效劳器的负载更好均匀。

6、wlc 加权最少连接。在lc的底子上,为每台效劳器加上权值。算法为:(活动连接数*256+非活动连接数)÷权重 ,计算出来的值小的效劳器优先被决定。

优点:可以按照效劳器的能力分配请求。

7、sed 最短期望延迟。莫过于sed跟wlc类似,相似处是不揣摩非活动连接数。算法为:(活动连接数+1)*256÷权重,同样计算出来的值小的效劳器优先被决定。

8、nq 永不排队。改进的sed算法。吾们想一下什么环境下才能“永不排队”,那就是效劳器的连接数为0的时候,so假如有效劳器连接数为0,均衡器直接把请求转发给它,无需经过sed的计算。

9、LBLC 基于局部性的最少连接。均衡器按照请求的鹄的IP地址,找出该IP地址最近被使用的效劳器,把请求转发之,若该效劳器超载,最采取应用最少连接数算法。

10、LBLCR 带复制的基于局部性的最少连接。均衡器按照请求的鹄的IP地址,找出该IP地址最近使用的“效劳器”,care,并不是具体某个效劳器,然下采取应用最少连接数从该组中挑出具体的某台效劳器出来,把请求转发之。若该效劳器超载,so按照最少连接数算法,在集群的本效劳器组的效劳器中,找出一台效劳器出来,加入本效劳器组,然下把请求转发之。

3、第三个小case是集群模式小case,一般3种解决Plan:

1、NAT:负载均衡器接收用户的请求,转发给具体效劳器,效劳器处理完请求返回给均衡器,均衡器再重新返回给用户。

2、DR:负载均衡器接收用户的请求,转发给具体效劳器,效劳器出来玩请求下直接返回给用户。需要系统支持IP Tunneling协议,难以跨平台。

3、TUN:同上,但无需IP Tunneling协议,跨平台性好,大部分系统都可以支持。

4、第四个小case是session小case,一般有4种解决Plan:

1、Session Sticky。session sticky就噬涎同一个用户在某一个会话中的请求,都分配到固定的某一台效劳器中,这样吾们就不需要解决跨效劳器的session小case了,常见的算法有ip_hash法,即上面提到的两种散列算法。

优点:实现easy。

缺点:应用效劳器重启则session消失。

2、Session Replication。session replication就是在集群中复制session,使得每个效劳器都保存有全部用户的session数据。

优点:减轻负载均衡效劳器的压力,不需要要实现ip_hasp算法来转发请求。

缺点:复制时宽带开销大,访问量大的话session占用内存大且糜费。

3、Session数据聚集存储:session数据聚集存储就是利用数据库来存储session数据,实现了session和应用效劳器的解耦。

优点:相比session replication的Plan,集群间对于宽带和内存的压力减少了很多。

缺点:需要维护存储session的数据库。

4、Cookie Base:cookie base就噬涎session存在cookie中,有浏览器来告诉应用效劳器我的session是什么,同样实现了session和应用效劳器的解耦。

优点:实现easy,基本免维护。

缺点:cookie长度限制,安全性低,宽带消耗。

值得一提的是

nginx目上支持的负载均衡算法有wrr、sh(支持一致性哈希)、fair(本人觉得可以归结为lc)。但nginx作为均衡器的话,还可以一同作为静态资源效劳器。

keepalived+ipvsadm比较强大,目上支持的算法有:rr、wrr、lc、wlc、lblc、sh、dh

keepalived支持集群模式有:NAT、DR、TUN

nginx本身并没有供给session同步的解决Plan,而apache则供给了session共享的支持。

好了,解决了如该的小case之下,系统的结构如下

阶段四、数据库读写分离化

上面吾们总是假设数据库负载正常,但随着访问量的的提高,数据库的负载也在慢慢增大。so可能有人马上就想到跟应用效劳器一样,把数据库一份为二再负载均衡即可。但对于数据库来说,并没有soeasy。假如吾们easy的把数据库一分为二,然下对于数据库的请求,分别负载到A机器和B机器,so显而易见会遭成两台数据库数据不统一的小case。so对于这种环境,吾们可以先揣摩使用读写分离的方式。

读写分离下的数据库系统结构如下:

这个结构改动下也会带来两个小case

  1. 主从数据库之间数据同步小case
  2. 应用对于数据源的决定小case

解决小casePlan

  1. 吾们可以使用MYSQL自带的master+slave的方式实现主从复制。
  2. 采取应用第三方数据库中点件, 诸如mycat。mycat是从cobar发展而来的,而cobar噬息里开源的数据库中点件,下来停止开发。mycat是国内比较好的mysql开源数据库分库分表中点件。

阶段五、用搜索引擎缓解读库的压力

数据库做读库的话,常常对模糊查找力不从心,即使做了读写分离,这个小case还未能解决。以吾们所举的交易网站为例,发布的商品存储在数据库中,用户最常使用的功能就是查找商品,尤其噬洗照商品的标题来查找对应的商品。对于这种需求,一般吾们都是通过like功能来实现的,但是这种方式的代价非常大。此时吾们可以使用搜索引擎的倒排索引来完成。

搜索引擎具有以下优点

它能够大大提高查问速度。

引入搜索引擎下也会带来以下的开销

搜索引擎并不能替代数据库,他解决了某些场景下的“读”的小case,是否引入搜索引擎,需要综合揣摩整个系统的需求。引入搜索引擎下的系统结构如下:

阶段六、用缓存缓解读库的压力

1、下台应用层和数据库层的缓存

随着访问量的增加,逐渐出现了许多用户访问同一部分始末的环境,对于这些比较热门的始末,没需要每次都从数据库读取。吾们可以使用缓存 技术实现 , 诸如可以使用google的开源缓存 技术实现 guava或者使用memcacahe作为应用层的缓存,也可以使用redis作为数据库层的缓存。

其余,在某些场景下,关系型数据库并不是很适合, 诸如我想做一个“每日输入密码错误次数限制”的功能,思路大概是在用户登录时,如果登录错误,则记录下该用户的IP和错误次数,so这个数据要放在哪里呢?假如放在内存中,so显然会占用太大的始末;假如放在关系型数据库中,so既要建立数据库表,还要简历对应的java bean,还要写SQL等等。而归纳一下吾们要存储的数据,无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据,吾们可以用NOSQL数据库来代替上卫的关系型数据库。

2、页面缓存

除了数据缓存,还有页面缓存。譬喻使用HTML5的localstroage或者cookie。

优点

缺点

值得一提的是

缓存集群的调度算法不同与上面提到的应用效劳器和数据库。最好采取应用“一致性哈希算法”,这样才能提高命中率。这个就不展开讲了,有兴趣的可以查阅相关资料。

加入缓存下的结构

阶段七、数据库水平拆分与垂直拆分

吾们的网站演进到Now,交易、商品、用户的数据都还在同一个数据库中。尽管采取了增加缓存,读写分离的方式,但随着数据库的压力继续增加,数据库的瓶颈越来越突出,此时,吾们可以有数据垂直拆分和水平拆分两种决定。

7.1、数据垂直拆分

垂直拆分的意思噬涎数据库中不同的业务数据拆分道不同的数据库中,结合Now的例子,就噬涎交易、商品、用户的数据分开。

优点

缺点

小case

  1. 需要揣摩原来跨业务的事务
  2. 跨数据库的join

解决小casePlan

  1. 吾们应该在应用层尽量避免跨数据库的事物,如果非要跨数据库,尽量在代码中把握。
  2. 吾们可以通过第三方应用来解决,如上面提到的mycat,mycat供给了丰富的跨库joinPlan,详情可参考mycat官方文档。

垂直拆分下的结构如下

7.2、数据水平拆分

数据水平拆分就噬涎同一个表中的数据拆分到两个甚至多个数据库中。产生数据水平拆分的原因是某个业务的数据量或者更新量到达了单个数据库的瓶颈,这时就可以把这个表拆分到两个或更好优质个数据库中。

优点

小case

  1. 访问用户信息的应用系统需要解决SQL路由的小case,因为Now用户信息分在了两个数据库中,需要在进行数据操作时了解需要操作的数据在哪里。
  2. 主键的处理也变得不同, 诸如原来自增字段,Now不能easy地继续使用了。
  3. 如果需要分页,就麻烦了。

解决小casePlan

  1. 吾们灰子 强梢酝ü梢越饩龅谌街械慵,如mycat。mycat可以通过SQL解析模块对吾们的SQL进行解析,再按照吾们的配置,把请求转发到具体的某个数据库。
  2. 吾们可以通过UUID保证唯一或自定义IDPlan来解决。
  3. mycat也供给了丰富的分页查问Plan,譬喻先从每个数据库做分页查问,再合并数据做一次分页查问等等。

数据水平拆分下的结构

阶段八、应用的拆分

8.1、拆分应用

随着业务的发展,业务越来越多,应用越来越大。吾们需要揣摩如何避免让应用越来越臃肿。这就需要把应用拆开,从一个应用变为俩个甚至更好优质。灰子 且晕崦巧厦娴睦樱崦强梢园延没А⑸唐贰⒔灰撞鸱挚1涑伞坝没А⑸唐贰焙汀坝没В灰住绷礁鲎酉低场

拆分下的结构:


小case

  1. 这样拆分下,可能会有一些同样的代码,如用户相关的代码,商品和交易都需要用户信息,以是在两个系统中都保留差不多的操感化户信息的代码。如何保证这些代码可以复用是一个需要解决的小case。

解决小case

  1. 通过走效劳化的路线来解决

8.2、走效劳化的道路

为了解决上面拆分应用下所出现的小case,吾蒙涎公共的效劳拆分出来,形成一种效劳化的模式,简称SOA。

采取应用效劳化之下的系统结构:

优点

小case

  1. 如何进行远程的效劳调用

解决方法

  1. 吾们可以通过下面的引入消息中点件来解决

阶段九、引入消息中点件

随着网站的继续发展,吾们的系统中可能出现不同语言开发的子模块和部署在不同平台的子系统。此时吾们需要一个平台来传递可靠的,与平台和语言无关的数据,并且能够把负载均衡透明化,能在调用过程中收集调用数据并归纳之,推测出网站的访问增长率等等一系列需求,对于网站应该如何成长做出预测。开源消息中点件有阿里的dubbo,可以搭配Google开源的分布式程序协调效劳zookeeper实现效劳器的注册与发现。

引入消息中点件下的结构:

十、总结

如该的演变过程只是一个例子,并不适合一切的网站,实际中网站演进过程与自身业务和不同遇到的小case有密切的关系,没有固定的模式。只有认真的归纳和不断地探究,才能发现适合自己网站的架构。


解读大型网站系统架构的演化之路

中国较小漏洞报告平台乌云网和漏洞盒子暂停效劳整顿

吾们的地位

广州 广州市天河区岗顶百脑汇高技术大厦B塔27楼 020-6235 2949

深圳 深圳市南山区汉京万国大厦18A 159 8916 9178

广西 茂名市茂南区油城三路广西创业创新孵化基地B110 159 8916 9178

吾们的效劳

网站及移动应用 牛逼直营网站 APP开发 小程序开发 WeChat运营

系统应用开发 OA/ERP/CRM/HR系统开发 教学管理系统 电商系统 应用型软件系统定制开发

了解吾们

集团官网简介 联系吾们 吾们的案例 讯息报道

使用条款 隐私声明 Cookies

© 2009-2020 老直营威尼斯网址开户 版权一切 广ICP备16051058号

XML 地图 | Sitemap 地图