精华内容
下载资源
问答
  • 所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较...
  • 高并发架构解析

    2020-02-05 23:02:04
    高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己...

    前言

    高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。

    为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案。

    在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家。

    服务器架构

    业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。

    一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn,这些都是能让业务程序流畅运行的强大后盾。

    服务器这块多是需要运维人员来配合搭建,具体我就不多说了,点到为止。

    大致需要用到的服务器架构如下:

    服务器

    ​ 均衡负载(如:nginx,阿里云SLB)

    ​ 资源监控

    ​ 分布式

    数据库

    ​ 主从分离,集群

    ​ DBA 表优化,索引优化,等

    ​ 分布式

    nosql

    ​ 主从分离,集群

    ​ 主从分离,集群

    ​ 主从分离,集群

    ​ redis

    ​ mongodb

    ​ memcache

    cdn

    ​ html

    ​ css

    ​ js

    ​ image

    并发测试

    高并发相关的业务,需要进行并发的测试,通过大量的数据分析评估出整个架构可以支撑的并发量。

    测试高并发可以使用第三方服务器或者自己测试服务器,利用测试工具进行并发请求测试,分析测试数据得到可以支撑并发数量的评估,这个可以作为一个预警参考,俗话说知己自彼百战不殆。

    第三方服务:

    ​ 阿里云性能测试

    并发测试工具:

    ​ Apache JMeter

    ​ Visual Studio性能负载测试

    ​ Microsoft Web Application Stress Tool

    实战方案

    通用方案

    日用户流量大,但是比较分散,偶尔会有用户高聚的情况;

    场景: 用户签到,用户中心,用户订单,等

    服务器架构图:

    img

    说明:

    场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,双11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中DB的查询;优先查询缓存,如果缓存不存在,再进行DB查询,将查询结果缓存起来。

    更新用户相关缓存需要分布式存储,比如使用用户ID进行hash分组,把用户分布到不同的缓存中,这样一个缓存集合的总量不会很大,不会影响查询效率。

    方案如:

    用户签到获取积分

    ​ 计算出用户分布的key,redis hash中查找用户今日签到信息

    ​ 如果查询到签到信息,返回签到信息

    ​ 如果没有查询到,DB查询今日是否签到过,如果有签到过,就把签到信息同步redis缓存。

    ​ 如果DB中也没有查询到今日的签到记录,就进行签到逻辑,操作DB添加今日签到记录,添加签到积分(这整个DB操作是一个事务)

    ​ 缓存签到信息到redis,返回签到信息

    ​ 注意这里会有并发情况下的逻辑问题,如:一天签到多次,发放多次积分给用户。

    ​ 我的博文《大话程序猿眼里的高并发》(http://blog.thankbabe.com/2016/04/01/high-concurrency/)有相关的处理方案。

    用户订单

    ​ 这里我们只缓存用户第一页的订单信息,一页40条数据,用户一般也只会看第一页的订单数据

    ​ 用户访问订单列表,如果是第一页读缓存,如果不是读DB

    ​ 计算出用户分布的key,redis hash中查找用户订单信息

    ​ 如果查询到用户订单信息,返回订单信息

    ​ 如果不存在就进行DB查询第一页的订单数据,然后缓存redis,返回订单信息

    用户中心

    ​ 计算出用户分布的key,redis hash中查找用户订单信息

    ​ 如果查询到用户信息,返回用户信息

    ​ 如果不存在进行用户DB查询,然后缓存redis,返回用户信息

    其他业务

    ​ 上面例子多是针对用户存储缓存,如果是公用的缓存数据需要注意一些问题,如下

    ​ 注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询,可以使用管理后台更新缓存,或者DB查询的锁住操作。

    ​ 我的博文《大话Redis进阶》(http://blog.thankbabe.com/2016/08/05/redis-up/)对更新缓存问题和推荐方案的分享。

    以上例子是一个相对简单的高并发架构,并发量不是很高的情况可以很好的支撑,但是随着业务的壮大,用户并发量增加,我们的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务有自己的并发架构,自己的均衡服务器,分布式数据库,nosql主从集群,如:用户服务、订单服务;

    消息队列

    秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求

    场景:定时领取红包,等

    服务器架构图:

    img

    说明:

    场景中的定时领取是一个高并发的业务,像秒杀活动用户会在到点的时间涌入,DB瞬间就接受到一记暴击,hold不住就会宕机,然后影响整个业务;

    像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务,前面提到的通用方案就无法支撑,并发的时候都是直接命中DB;

    设计这块业务的时候就会使用消息队列的,可以将参与用户的信息添加到消息队列中,然后再写个多线程程序去消耗队列,给队列中的用户发放红包;

    方案如:

    定时领取红包

    ​ 一般习惯使用 redis的 list

    ​ 当用户参与活动,将用户参与信息push到队列中

    ​ 然后写个多线程程序去pop数据,进行发放红包的业务

    ​ 这样可以支持高并发下的用户可以正常的参与活动,并且避免数据库服务器宕机的危险

    附加:

    ​ 通过消息队列可以做很多的服务。

    ​ 如:定时短信发送服务,使用sset(sorted set),发送时间戳作为排序依据,短信数据队列根据时间升序,然后写个程序定时循环去读取sset 队列中的第一条,当前时间是否超过发送时间,如果超过就进行短信发送。

    一级缓存

    高并发请求连接缓存服务器超出服务器能够接收的请求连接量,部分用户出现建立连接超时无法读取到数据的问题;

    因此需要有个方案当高并发时候时候可以减少命中缓存服务器;

    这时候就出现了一级缓存的方案,一级缓存就是使用站点服务器缓存去存储数据,注意只存储部分请求量大的数据,并且缓存的数据量要控制,不能过分的使用站点服务器的内存而影响了站点应用程序的正常运行,一级缓存需要设置秒单位的过期时间,具体时间根据业务场景设定,目的是当有高并发请求的时候可以让数据的获取命中到一级缓存,而不用连接缓存nosql数据服务器,减少nosql数据服务器的压力

    比如APP首屏商品数据接口,这些数据是公共的不会针对用户自定义,而且这些数据不会频繁的更新,像这种接口的请求量比较大就可以加入一级缓存;

    服务器架构图:

    img

    合理的规范和使用nosql缓存数据库,根据业务拆分缓存数据库的集群,这样基本可以很好支持业务,一级缓存毕竟是使用站点服务器缓存所以还是要善用。

    静态化数据

    高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。

    对于更新频繁度不高,并且数据允许短时间内的延迟,可以通过数据静态化成JSON,XML,HTML等数据文件上传CDN,在拉取数据的时候优先到CDN拉取,如果没有获取到数据再从缓存,数据库中获取,当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN,这样在高并发的时候可以使数据的获取命中在CDN服务器上。

    CDN节点同步有一定的延迟性,所以找一个靠谱的CDN服务器商也很重要

    其他方案

    对于更新频繁度不高的数据,APP,PC浏览器,可以缓存数据到本地,然后每次请求接口的时候上传当前缓存数据的版本号,服务端接收到版本号判断版本号与最新数据版本号是否一致,如果不一样就进行最新数据的查询并返回最新数据和最新版本号,如果一样就返回状态码告知数据已经是最新。减少服务器压力:资源、带宽等.

    分层,分割,分布式

    大型网站要很好支撑高并发,这是需要长期的规划设计

    在初期就需要把系统进行分层,在发展过程中把核心业务进行拆分成模块单元,根据需求进行分布式部署,可以进行独立团队维护开发。

    分层

    将系统在横向维度上切分成几个部分,每个部门负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统

    比如把电商系统分成:应用层,服务层,数据层。(具体分多少个层次根据自己的业务场景)

    应用层:网站首页,用户中心,商品中心,购物车,红包业务,活动中心等,负责具体业务和视图展示

    服务层:订单服务,用户管理服务,红包服务,商品服务等,为应用层提供服务支持

    数据层:关系数据库,nosql数据库 等,提供数据存储查询服务

    分层架构是逻辑上的,在物理部署上可以部署在同一台物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,分别部署在不同的服务器上,使网站可以支撑更多用户访问

    分割

    在纵向方面对业务进行切分,将一块相对复杂的业务分割成不同的模块单元

    包装成高内聚低耦合的模块不仅有助于软件的开发维护,也便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展

    比如用户中心可以分割成:账户信息模块,订单模块,充值模块,提现模块,优惠券模块等

    分布式

    分布式应用和服务,将分层或者分割后的业务分布式部署,独立的应用服务器,数据库,缓存服务器

    当业务达到一定用户量的时候,再进行服务器均衡负载,数据库,缓存主从集群

    分布式静态资源,比如:静态资源上传cdn

    分布式计算,比如:使用hadoop进行大数据的分布式计算

    分布式数据和存储,比如:各分布节点根据哈希算法或其他算法分散存储数据

    img

    集群

    对于用户访问集中的业务独立部署服务器,应用服务器,数据库,nosql数据库。 核心业务基本上需要搭建集群,即多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务, 服务器集群能够为相同的服务提供更多的并发支持,因此当有更多的用户访问时,只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时,可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上,因此可以提高系统的可用性

    应用服务器集群

    ​ nginx 反向代理

    ​ slb

    ​ … …

    (关系/nosql)数据库集群

    ​ 主从分离,从库集群

    img

    异步

    在高并发业务中如果涉及到数据库操作,主要压力都是在数据库服务器上面,虽然使用主从分离,但是数据库操作都是在主库上操作,单台数据库服务器连接池允许的最大连接数量是有限的

    当连接数量达到最大值的时候,其他需要连接数据操作的请求就需要等待有空闲的连接,这样高并发的时候很多请求就会出现connection time out 的情况

    那么像这种高并发业务我们要如何设计开发方案可以降低数据库服务器的压力呢?

    如:

    ​ 自动弹窗签到,双11跨0点的时候并发请求签到接口

    ​ 双11抢红包活动

    ​ 双11订单入库等

    设计考虑:

    ​ 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了

    ​ 数据持久化是否允许延迟?

    ​ 如何让业务接口不直接操作DB,又可以让数据持久化?

    方案设计:

    ​ 像这种涉及数据库操作的高并发的业务,就要考虑使用异步了

    ​ 客户端发起接口请求,服务端快速响应,客户端展示结果给用户,数据库操作通过异步同步

    ​ 如何实现异步同步?

    ​ 使用消息队列,将入库的内容enqueue到消息队列中,业务接口快速响应给用户结果(可以温馨提示高峰期延迟到账)

    ​ 然后再写个独立程序从消息队列dequeue数据出来进行入库操作,入库成功后刷新用户相关缓存,如果入库失败记录日志,方便反馈查询和 重新持久化

    ​ 这样一来数据库操作就只有一个程序(多线程)来完成,不会给数据带来压力

    补充:

    ​ 消息队列除了可以用在高并发业务,其他只要有相同需求的业务也是可以使用,如:短信发送中间件等

    ​ 高并发下异步持久化数据可能会影响用户的体验,可以通过可配置的方式,或者自动化监控资源消耗来切换时时或者使用异步,这样在正常流量的情况下可以使用时时操作数据库来提高用户体验

    ​ 异步同时也可以指编程上的异步函数,异步线程,在有的时候可以使用异步操作,把不需要等待结果的操作放到异步中,然后继续后面的操作,节省了等待的这部分操作的时间

    img

    缓存

    高并发业务接口多数都是进行业务数据的查询,如:商品列表,商品信息,用户信息,红包信息等,这些数据都是不会经常变化,并且持久化在数据库中

    高并发的情况下直接连接从库做查询操作,多台从库服务器也抗不住这么大量的连接请求数(前面说过,单台数据库服务器允许的最大连接数量是有限的)

    那么我们在这种高并发的业务接口要如何设计呢?

    设计考虑:

    还是逆向思维,压力在数据库,那么我们就不进行数据库查询

    数据不经常变化,我们为啥要一直查询DB?

    数据不变化客户端为啥要向服务器请求返回一样的数据?

    方案设计:

    数据不经常变化,我们可以把数据进行缓存,缓存的方式有很多种,一般的:应用服务器直接Cache内存,主流的:存储在memcache、redis内存数据库

    Cache是直接存储在应用服务器中,读取速度快,内存数据库服务器允许连接数可以支撑到很大,而且数据存储在内存,读取速度快,再加上主从集群,可以支撑很大的并发查询

    根据业务情景,使用配合客户端本地存,如果我们数据内容不经常变化,为啥要一直请求服务器获取相同数据,可以通过匹配数据版本号,如果版本号不一样接口重新查询缓存返回数据和版本号,如果一样则不查询数据直接响应

    这样不仅可以提高接口响应速度,也可以节约服务器带宽,虽然有些服务器带宽是按流量计费,但是也不是绝对无限的,在高并发的时候服务器带宽也可能导致请求响应慢的问题

    补充:

    缓存同时也指静态资源客户端缓存

    cdn缓存,静态资源通过上传cdn,cdn节点缓存我们的静态资源,减少服务器压力

    img

    面向服务

    SOA面向服务架构设计

    微服务更细粒度服务化,一系列的独立的服务共同组成系统

    使用服务化思维,将核心业务或者通用的业务功能抽离成服务独立部署,对外提供接口的方式提供功能。

    最理想化的设计是可以把一个复杂的系统抽离成多个服务,共同组成系统的业务,优点:松耦合,高可用性,高伸缩性,易维护。

    通过面向服务化设计,独立服务器部署,均衡负载,数据库集群,可以让服务支撑更高的并发

    服务例子:

    ​ 用户行为跟踪记录统计

    说明:

    ​ 通过上报应用模块,操作事件,事件对象,等数据,记录用户的操作行为

    ​ 比如:记录用户在某个商品模块,点击了某一件商品,或者浏览了某一件商品

    背景:

    ​ 由于服务需要记录用户的各种操作行为,并且可以重复上报,准备接入服务的业务又是核心业务的用户行为跟踪,所以请求量很大,高峰期会产生大量并发请求。

    架构:

    ​ nodejs WEB应用服务器均衡负载

    ​ redis主从集群

    ​ mysql主

    ​ nodejs+express+ejs+redis+mysql

    ​ 服务端采用nodejs,nodejs是单进程(PM2根据cpu核数开启多个工作进程),采用事件驱动机制,适合I/O密集型业务,处理高并发能力强

    业务设计:

    ​ 并发量大,所以不能直接入库,采用:异步同步数据,消息队列

    ​ 请求接口上报数据,接口将上报数据push到redis的list队列中

    ​ nodejs写入库脚本,循环pop redis list数据,将数据存储入库,并进行相关统计Update,无数据时sleep几秒

    ​ 因为数据量会比较大,上报的数据表按天命名存储

    接口:

    ​ 上报数据接口

    ​ 统计查询接口

    ​ 上线跟进:

    ​ 服务业务基本正常

    ​ 每天的上报表有上千万的数据

    冗余,自动化

    当高并发业务所在的服务器出现宕机的时候,需要有备用服务器进行快速的替代,在应用服务器压力大的时候可以快速添加机器到集群中,所以我们就需要有备用机器可以随时待命。 最理想的方式是可以通过自动化监控服务器资源消耗来进行报警,自动切换降级方案,自动的进行服务器替换和添加操作等,通过自动化可以减少人工的操作的成本,而且可以快速操作,避免人为操作上面的失误。

    冗余

    ​ 数据库备份

    ​ 备用服务器

    自动化

    ​ 自动化监控

    ​ 自动化报警

    ​ 自动化降级

    通过GitLab事件,我们应该反思,做了备份数据并不代表就万无一失了,我们需要保证高可用性,首先备份是否正常进行,备份数据是否可用,需要我们进行定期的检查,或者自动化监控, 还有包括如何避免人为上的操作失误问题。(不过事件中gitlab的开放性姿态,积极的处理方式还是值得学习的)

    总结

    高并发架构是一个不断衍变的过程,冰洞三尺非一日之寒,长城筑成非一日之功 。

    打好基础架构方便以后的拓展,这点很重要。

    此文章转载自民工哥技术之路公众号

    展开全文
  • 高并发的大型网站架构设计

    万次阅读 多人点赞 2018-01-28 23:42:50
    最近在学习大型网站的架构设计,便想把学习过程中的一些东西总结记录下来,以便复习和巩固提高。先来看看大型网站架构图: 从左边开始,先是CDN服务器和反向代理服务器,都用于缓存一些用户需要请求的资源。两者...

    最近在学习大型网站的架构设计,便想把学习过程中的一些东西总结记录下来,以便复习和巩固提高。先来看看大型网站架构图:

    大型网站架构图

    从左边开始,先是CDN服务器和反向代理服务器,都用于缓存一些用户需要请求的资源。两者的区别在于CDN部署在网络提供商的机房,用户可以就近获取;反向代理则部署在网站中心机房。使用CDN和反向代理的目的都是尽快返回数据给用户。这样可以加快返回用户资源的速度,也减轻了后端服务器的负载压力。
    往下走,是一台负载均衡调度服务器,用于将用户的请求发送到服务器集群上。这里面A,B应用服务器可以是Tomcat服务器集群,只不过它上面只部署了Action,也就是我们平时写的controller层的代码。在这里面去调用被分别部署在不同服务器上的业务层代码(大型网站会进行业务拆分,将不同的应用独立部署)。如果某些业务请求量较大,业务处理时间较长,可以根据实际情况来将其加入消息队列,以达到快速返回的目的。最后,由分布式的业务服务器去调用分布式的数据库系统实现数据的存储。右边,文件这些东西可以部署在分布式的文件服务器上。右上,使用分布式缓存服务器将平时最常访问的20%数据(二八定律:80%的业务访问集中在20%的数据上)缓存起来。最下面两个,由于网站业务相当复杂,采用一些非关系数据库如nosql和非数据库查询技术如搜索引擎进行进行数据的存储和检索。
    以上,就是一个大型网站的大体架构。
    总体架构讲完了,接下来讲一点具体的东西。大型网站核心架构要素:性能,可用性,伸缩性,扩展性,安全性。
    先来讲性能:

    web前端性能优化:

    一般来讲,web前端主要优化手段有优化浏览器访问,使用反向代理,CDN等。

    浏览器访问优化:

    1 减少http请求
    http请求的开销都很昂贵,应该尽量减少http请求次数。主要手段是将javascrit,css,图片合并成一个文件,这样浏览器只需一次请求。
    
    2 使用浏览器缓存
    对网站而言,css,javascript,logo,图标这些资源更新频率低,可以设置http头中的Cache-Control和Expires属性将其缓存在浏览器中。
    
    3 启用压缩
    可以在服务器端对文件进行压缩,文本文件的压缩效率可达80%以上,因此HTML,CSS,Javascript文件启用GZip压缩可以达到较好的效果
    
    4 css文件放在页面最上面,javascript放在页面最下面
    浏览器在css全部下载完之后才进行页面渲染,而javascript则是加载后就立即执行。因此先进行css文件的下载,javascript放在最后即可。
    

    cdn加速

    CDN(内容分发网络)本质仍是一个缓存,而且将数据缓存在离用户最近的地方,使用户以最快速度获取数据。一般缓存静态资源。
    

    反向代理

    反向代理服务器可以保护服务器的安全,来自互联网的请求必需经过代理服务器。所以也可以在代理服务器放一些静态数据,当用户第一次访问静态内容时,静态内容就被缓存在方向代理服务器上,其他用户请求进来时,就可以直接返回,减轻web服务器负载压力。
    

    应用服务器性能优化

    服务器的优化手段主要有缓存,集群,异步等。
    

    异步操作:

    在高并发情况下,若不使用消息队列,用户请求直接写入数据库会对数据库造成巨大的压力,同时使响应延迟加剧。使用消息队列,异步写入数据库,可以起到很好的削峰作用,改善网站的扩展性,提升网站性能。
    

    使用集群:

    在网站高并发访问的场景下,使用负载均衡技术为应用构建一个堕胎服务器组成的集群,将并发访问请求分发到多台服务器上处理,避免单一服务器因负载压力过大而响应缓慢。
    

    代码优化:

    1 多线程
    从资源利用的角度来看,使用多线程的原因主要有两个:
    
    • io阻塞:当线程进行io处理时,会阻塞cpu以等待io。利用多线程io阻塞与执行交替进行,可以最大限度利用cpu。

    • 多cpu:一个服务器有多个cpu,在这个手机都有四核cpu的时代要想做大限度使用这些cpu,必需启用多线程。

    2 资源复用
    资源复用主要有两种模式:单例和对象池。
    
    • 单例:由于web开发中主要使用贫血模式,使用很多无状态对象,无需重复创建,因此使用单例模式自然而然的事。

    • 线程池:对象池通过复用对象实例,减少对象创建和资源消耗。

    3 数据结构
    在不同的场景中使用适当的数据结构,改写数据和计算特性可以极大优化程序的性能。
    
    4 垃圾回收
    如果web应用运行在JVM等具有垃圾回收功能的环境中,理解垃圾回收机制有助于程序优化和参数调优,以及编写内存安全的代码。
    

    网站架构的伸缩性设计

    一般来说。网站的伸缩性设计可分为两类:一类是根据功能进行物理分离实现伸缩,一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务,提供不同的功能;后者是集群内的服务器部署相同的服务实现相同的功能。
    

    应用服务器集群的伸缩性设计

    负载均衡是实现伸缩性设计的关键技术。因为它能将用户的请求按照某种规则分发到集群不同的服务器上,且能感知或配置集群的服务器数量,及时发现新上线或下线的服务器,以此来实现应用服务器集群的可伸缩性。实现负载均衡的技术有以下几种:
    
    • http重定向负载均衡

         http服务器就是一台普通的应用服务器,唯一功能就是根据根据用户的http请求计算一台真实的web服务器地址。这种方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问,性能较差;实践中不常采用。
      
    • dns域名解析负载均衡

       每次域名解析请求都会根据负载均衡算法计算一个不同的ip地址返回。优点是将负载均衡工作交给dns,省掉了网站管理维护负载均衡服务器的麻烦。缺点是dns负载均衡的控制权在域名服务商那里,网站无法对其做更多的改善和更强大的管理。
      
    • 反向代理负载均衡

      反向代理服务器需要双网卡及内部外部两套ip地址。其优点是和反向代理服务器功能集成在一起,部署简单。缺点是所有请求均经过此,其性能可能成为瓶颈。
      
      • ip负载均衡

        在网络层通过修改请求目标地址进行负载均衡。ip负载均衡在内核进程完成数据分发,有更好的处理性能。但对需要提供下载服务或视频服务的大型网站而言,难以满足需求。

      • 数据链路层负载均衡

        在通信协议的数据链路层修改mac地址进行负载均衡。此模式是目前大型网站采用最广的一中负载均衡手段。

    数据库存储服务器集群的伸缩

    这里主要将关系型数据库的伸缩设计。对于进行了水平分库分表的数据库,可以用一些分布式数据库产品例如Mycat,Cobar.

    利用分布式消息队列降低降低系统耦合性

    如果模块间不存在直接调用,那么新增或修改对其他模块的影响就最小。通过在低耦合的模块间传输事件消息,来保持模块的松散耦合。最常用的是分布式消息队列。在伸缩性方面,由于消息队列上的服务器上的数据是即时被处理的,可以看作无状态的服务器,伸缩性比较简单,将新服务器加入分布式消息队列集群中,通知生产者服务器更改消息队列服务器列表即可。在可用性方面,为避免内存空间不足的问题,会将消息写入磁盘。
    

    网站应用攻击与防御:

    从互联网诞生之日起,各种web攻击和信息泄漏也从未停止。在此讲一下主要的攻击手段及防御措施。

    • xss攻击

      xss即跨站点脚本攻击,致黑客通过篡改网页,注入恶意html脚本。主要防御手段有两种:
      
      1 消毒
      
      对某些html危险字符转义,如“>”转义为“&gt”。
      
      2 HttpOnly
      
      即浏览器禁止页面javascript访问带有HttpOnly属性的cookie。
      
      • sql注入

      sql注入,攻击者在http请求中注入恶意sql命令。防御方法,还是消毒,过滤请求数据中可能注入的sql。或者参数绑定,如mybatis的#{},将攻击者的sql视为参数,而不是可执行sql。

      • csrf攻击

      跨站点请求伪造,攻击者通过跨站请求,以合法用户身份进行非法操作。其核心是利用服务器session或浏览器cookie策略。盗取用户身份。防御方法
      1 表单token。在页面表单加入一个随机数作为token值,提交到服务器进行检查。
      2 验证码
      3 Refer Check
      http请求头的请求域中记录着请求来源,可检查请求来源验证其是否合法。

    web应用防火墙
    ModSecurity,一种开源的web应用防火墙,探测攻击并保护web程序。
    
    网站安全漏洞扫描
    指根据一定规则构造攻击性url模拟黑客行为的工具。
    

    由于本博客只是对大型网站的架构及其用到的技术做一个大致的描述(不太好做详细的讲解,因为这里牵扯的知识点实在太多,而每个知识点又是可以单独提出来写成一片或几篇博客的那种),所以对大多数知识点的讲解只是浅尝辄止,如果想了解更多细节的同学,可以自行百度或者阅读本文的主要参考文献:

    大型网站技术架构核心原理与案列分析

    展开全文
  • 一:数据库 ...不到不得已时,网站更常用的数据库拆分手段是业务分库,将不同业务的数据部署在不同的物理服务器上。 分库分表分区 数据库索引 数据库连接池 SQL优化 二:缓存 使用缓存改善

             其中第1部分架构为综述。第2-8部分各个端用到的技术,点到为止,没有详述。第910部分是监控和部署,排查问题和解决问题时配合使用。

                           

         一:服务器总体架构综述

     

    经历的阶段:

    1:应用服务和数据服务,应用专门的图片服务器,视频服务器。

    2:缓存改善网站性能,redis,memcached缓存。

    3:应用服务器集群改善网站的并发处理能力,这个时候就应该读写分离或双主读写分离。

    4:使用反向代理和 CDN加速网站

    5:分布式数据库系统,数据库分表分区阶段

    6NoSQL服务器,减轻应用程序管理诸多数据源的麻烦。

    7:业务拆分,将一个网站拆分成许多不同的应用,每个应用独立部署。

     

       经历上面七个阶段后,大体服务器架构如下图:

                               



    二:数据库技术

    应用服务和数据服务分离;

    数据库读写分离

    分布式数据库系统
    分库分表

    数据库索引

    数据库连接池
    SQL
    优化

    数据库相关设置


    三:缓存技术

    使用缓存改善网站性能;

    提高缓存命中率;

    redis集群相关设置

     

    四:后端技术

    重定向

    使用反向代理

    DNS轮询,不能按服务器能力分配任务
    CDN,
    而且按流量计费,价格也比较昂贵。
    IP
    负载均衡:F5VS/NAT(基于网络地址转换技术)、VS/TUN(基于IP隧道技术)和VS/DR(基于直接路由技术)

    镜像(同学所在的教育行业在用)

                       五:业务拆分

    将一个网站拆分成许多不同的应用,每个应用独立部署。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系

    六:前端

    页面静态化
    前端缓存
    IOS
    ,安卓自身数据库使用

    IOS,安卓自身文件使用

    八:其他

    替换ApacheNginx
    队列系统就出场了,就以RabbitMQ为例时

    mysql硬件设置

     

    九:监控软件

    najios  监控服务运行状态和网络信息;
    zabbix
    监控服务运行状态和网络信息;
    cactic
    把机器信息和数据信息图表化地展现给用户。

    十:部署软件

    saltstack
    chef

    puppet
    ansibel


    展开全文
  • 高并发、高性能 Web 架构

    万次阅读 2017-02-28 14:59:50
    上图展示了一个典型的,三层架构性能 Web 应用。这种成熟的架构多年以来已被广泛部署于包括 Google、Yahoo、Facebook、Twitter、Wikipedia 在内的诸多大型 Web 应用中。   反向代理服务 ...

    典型 Web App 架构

    以下是一个典型的高负载 web 应用示例:

    上图展示了一个典型的,三层架构的高性能 Web 应用。这种成熟的架构多年以来已被广泛部署于包括 Google、Yahoo、Facebook、Twitter、Wikipedia 在内的诸多大型 Web 应用中。

     

    反向代理服务

    位于三层构架中最外层的反向代理服务器负责接受用户的接入请求,在实际应用中,代理服务器通常至少还要完成以下列表中的一部分任务:
    • 连接管理:分别维护客户端和应用服务器的连接池,管理并关闭已超时的长连接。
       
    • 攻击检测和安全隔离:由于反向代理服务无需完成任何动态页面生成任务,所有与业务逻辑相关的请求都转发至后端应用服务器处理。因此反向代理服务几乎不会被应用程序设计或后端数据漏洞所影响。反向代理的安全性和可靠性通常仅取决于产品本身。在应用服务的前端部署反向代理服务器可以有效地在后端应用和远程用户间建立起一套可靠的安全隔离和攻击检测机制。

      如果需要的话,还可以通过在外网、反向代理、后端应用和数据库等边界位置添加额外的硬件防火墙等网络隔离设备来实现更高的安全性保证。
       
    • 负载均衡:通常使用轮转(Round Robin)或最少连接数优先等策略完成基于客户请求的负载均衡;也可以使用 SSI 等技术将一个客户请求拆分成若干并行计算部分分别提交到多个应用服务器。
       
    • 分布式的 cache 加速:可以将反向代理分组部署在距离热点地区地理位置较近的网络边界上。通过在位于客户较近的位置提供缓冲服务来加速网络应用。这实际上就构成了 CDN 网络。
       
    • 静态文件伺服:当收到静态文件请求时,直接返回该文件而无需将该请求提交至后端应用服务器。
       
    • 动态响应缓存:对一段时间内不会发生改变的动态生成响应进行缓存,避免后端应用服务器频繁执行重复查询和计算。
       
    • 数据压缩传输:为返回的数据启用 GZIP/ZLIB 压缩算法以节约带宽。
       
    • 数据加密保护(SSL Offloading):为与客户端的通信启用 SSL/TLS 加密保护。
       
    • 容错:跟踪后端应用服务器的健康状况,避免将请求调度到发生故障的服务器。
       
    • 用户鉴权:完成用户登陆和会话建立等工作。
       
    • URL别名:对外建立统一的url别名信息,屏蔽真实位置。
       
    • 应用混搭:通过SSI和URL映射技术将不同的web应用混搭在一起。
       
    • 协议转换:为使用 SCGI 和 FastCGI 等协议的后端应用提供协议转换服务。

    目前比较有名的反向代理服务包括:Apache httpd+mod_proxy / IIS+ARR / Squid / Apache Traffic Server / Nginx / Cherokee / Lighttpd / HAProxy 以及 Varnish 等等。

     

    应用服务

    应用服务层位于数据库等后端通用服务层与反向代理层之间,向上接收由反向代理服务转发而来的客户端访问请求,向下访问由数据库层提供的结构化存储与数据查询服务。

    应用层实现了 Web 应用的所有业务逻辑,通常要完成大量的计算和数据动态生成任务。应用层内的各个节点不一定是完全对等的,还可能以 SOA、μSOA 等架构拆分为不同服务集群。

    上图给出了一个典型的高并发、高性能应用层节点工作模型。每个 Web 应用节点(在图 5中由标有"App"字样的方框表示)通常都会工作在自己的服务器(物理服务器或VPS)之上,多个应用节点可以有效地并行工作,以方便地实现横向扩展。

    在上图所示的例子中,Web 应用节点由 IO 回调线程池、Web 请求队列以及后台工作线程池等三个重要部分组成,其伺服流程如下:

    1. 当一个 Web 请求到达后,底层操作系统通过 IOCP、epoll、kqueue、event ports、real time signal (posix aio)、/dev/poll、pollset 等各类与具体平台紧密相关的 IO 完成(或 IO 就绪)回调机制通知 AIO(Asynchronous IO)回调线程,对这个已到达的 Web 请求进行处理。
       
    2. 在 AIO 回调池中的工作线程接收到一个已到达的 Web 请求后,首先尝试对该请求进行预处理。在预处理过程中,将会使用位于本地的高速缓存来避免成本较高的数据库查询。如果本地缓存命中,则直接将缓存中的结果(仍然以异步 IO 的方式)返回客户端,并结束本次请求。
       
    3. 如果指定的 Web 请求要求查询的数据无法被本地缓存命中,或者这个 Web 请求需要数据库写入操作,则该请求将被 AIO 回调线程追加到指定的队列中,等待后台工作线程池中的某个空闲线程对其进行进一步处理。
       
    4. 后台工作线程池中的每个线程都分别维护着两条长连接:一条与底层到数据库服务相连,另一条则连接到分布式缓存(memcached)网络。通过让每个工作线程维护属于自己的长连接,后台工作线程池实现了数据库和分布式缓存连接池机制。长连接(Keep-Alive)通过为不同的请求重复使用同一条网络连接大大提高了应用程序处理效率和网络利用率。
       
    5. 后台工作线程在 Web 请求队列上等待新的请求到达。在从队列中取出一个新的请求后,后台工作线程首先尝试使用分布式缓存服务命中该请求中的查询操作,如果网络缓存未命中或该请求需要数据库写入等进一步处理,则直接通过数据库操作来完成这个 Web 请求。
       
    6. 当一个 Web 请求被处理完成后,后台工作线程会将处理结果作为 Web 响应以异步 IO 的方式返回到指定客户端。
       

    上述步骤粗略描述了一个典型 Web 应用节点的工作方式。值得注意的是,由于设计思想和具体功能的差异,不同的 Web 应用间,无论在工作模式或架构上都可能存在很大的差异。

    需要说明的是,与 epoll/kqueue/event ports 等相位触发的通知机制不同,对于 Windows IOCP 和 POSIX AIO Realtime Signal 这类边缘触发的 AIO 完成事件通知机制,为了避免操作系统底层 IO 完成队列(或实时信号队列)过长或溢出导致的内存缓冲区被长时间锁定在非分页内存池,在上述系统内的 AIO 回调方式实际上是由两个独立的线程池和一个 AIO 完成事件队列组成的:一个线程池专门负责不间断地等待系统 AIO 完成队列中到达的事件,并将其提交到一个内部的 AIO 完成队列中(该队列工作在用户模式,具有用户可控的弹性尺寸,并且不会锁定内存);与此同时另一个线程池等待在这个内部 AIO 完成队列上,并且处理不断到达该队列的 AIO 完成事件。这样的设计降低了操作系统的工作负担,避免了在极端情况下可能出现的消息丢失、内存泄露以及内存耗尽等问题,同时也可以帮助操作系统更好地使用和管理非分页内存池。

    作为典型案例:包括搜索引擎、Gmail 邮件服务在内的大部分 Google Web 应用均是使用 C/C++ 实现的。得益于 C/C++ 语言的高效和强大,Google 在为全球 Internet 用户提供最佳 Web 应用体验的同时,也实现了在其遍及全球的上百万台分布式服务器上完成一次 Web 搜索,总能耗仅需 0.0003 kW·h 的优异表现。关于 Google Web 应用架构以及硬件规模等进一步讨论,请参考:http://en.wikipedia.org/wiki/Google 以及 http://en.wikipedia.org/wiki/Google_search

     

    数据库和memcached服务

    数据库服务为上层 Web 应用提供关系式或结构化的数据存储与查询支持。取决于具体用例,Web 应用可以使用数据库连接器之类的插件机制来提供对不同数据库服务的访问支持。在这种架构下,用户可以灵活地选择或变更最适合企业现阶段情况的不同数据库产品。例如:用户可以在原型阶段使用 SQLite 之类的嵌入式引擎完成快速部署和功能验证;而在应用的初期阶段切换到廉价的 MySql 数据库解决方案;等到业务需求不断上升,数据库负载不断加重时再向 Clustrix、MongoDB、Cassandra、MySql Cluster、ORACLE 等更昂贵和复杂的解决方案进行迁移。

    Memcached 服务作为一个完全基于内存和 <Key, Value> 对的分布式数据对象缓冲服务,拥有令人难以置信的查询效率以及一个优雅的,无需服务器间通信的大型分布式架构。对于高负载 Web 应用来说,Memcached 常被用作一种重要的数据库访问加速服务,因此它不是一个必选组件。用户完全可以等到现实环境下的数据库服务出现了性能瓶颈时在部署它。值得强调的是,虽然 memcached 并不是一个必选组件,但通过其在 YouTube、Wikipedia、Amazon.com、SourceForge、Facebook、Twitter 等大型 Web 应用上的多年部署可以证明:memcached 不但能够在高负载环境下长期稳定地工作,而且可以戏剧性地提升数据查询的整体效率。有关 memcached 的进一步讨论,请参考:http://en.wikipedia.org/wiki/Memcached

    当然,我们也应该注意到:以 memcached 为代表的分布式缓存系统,其本质上是一种以牺牲一致性为代价来提升平均访问效率的妥协方案——缓存服务为数据库中的部分记录增加了分布式副本。对于同一数据的多个分布式副本来说,除非使用 Paxos、Raft 等一致性算法,不然无法实现强一致性保证。

    矛盾的是,memory cache 本身就是用来提升效率的,这使得为了它使用上述开销高昂的分布式强一致性算法变得非常不切实际:目前的分布式强一致性算法均要求每次访问请求(无论读写)都需要同时访问包括后台数据库主从节点在内的多数派副本——显然,这还不如干脆不使用缓存来的有效率。

    另外,即使是 Paxos、Raft 之类的分布式一致性算法也只能在单个记录的级别上保证强一致。意即:即使应用了此类算法,也无法凭此提供事务级的强一致性保证。

    除此之外,分布式缓存也增加了程序设计的复杂度(需要在访问数据库的同时尝试命中或更新缓存),并且还增加了较差情形下的访问延迟(如:未命中时的 RTT 等待延迟,以及节点下线、网络通信故障时的延迟等)。

    与此同时,可以看到:从二十年前开始,各主流数据库产品其实均早已实现了成熟、高命中率的多层(磁盘块、数据页、结果集等)缓存机制。既然分布式缓存有如此多的缺陷,而数据库产品又自带了优秀的缓存机制,它为何又能够成为现代高负载 Web App 中的重要基石呢?

    其根本原因在于:对于十年前的技术环境来说,当时十分缺乏横向扩展能力的 RDBMS(SQL)系统已成为了严重制约 Web App 等网络应用扩大规模的瓶颈。为此,以 Google BigTable、Facebook Cassandra、MongoDB 为代表的 NoSQL 数据库产品,以及以 memcached、redis 为代表的分布式缓存产品纷纷粉墨登场,并各自扮演了重要作用。

    与 MySQL、ORACLE、DB2、MS SQL Server、PostgreSQL 等当时的 "传统" SQL数据库产品相比,无论 NoSQL 数据库还是分布式缓存产品,其本质上都是以牺牲前者的强一致性为代价,来换取更优的横向扩展能力。

    应当看到,这种取舍是在当时技术条件下做出的无奈、痛苦的抉择,系统因此而变得复杂——在需要事务和强一致性保障,并且数据量较少的地方,使用无缓存层的传统 RDBMS;在一致性方面有一定妥协余地,并且读多写少的地方尽量使用分布式缓存来加速;在对一致性要求更低的大数据上使用 NoSQL;如果数据量较大,同时对一致性要求也较高,就只能尝试通过对 RDMBS 分库分表等方法来尽量解决,为此还要开发各种中间件来实现数据访问的请求分发和结果集聚合等复杂操作……各种情形不一而足,而它们的相互组合和交织则再次加剧了复杂性。

    回顾起来,这是一个旧秩序被打破,新秩序又尚未建立起来的混乱时代——老旧 RMDBS 缺乏横向扩展能力,无法满足新时代的大数据处理需求,又没有一种能够替代老系统地位,可同时满足大部分用户需求的普适级结构化数据管理方案。

    这是一个青黄不接的时代,而 BigTable、Cassandra、memcached 等产品则分别是 Google、Facebook 以及 LiveJournal 等厂商在那个时代进行 "自救" 的结果。这样以:"花费最小代价,满足自身业务需求即可" 为目标的产物自然不太容易具备很好的普适性。

    然而今天(2015),我们终于就快要走出这个窘境。随着 Google F1、MySQL Cluster(NDB)、Clustrix、VoltDB、MemSQL、NuoDB 等众多 NewSQL 解决方案的逐步成熟以及技术的不断进步,横向扩展能力逐渐不再成为 RDBMS 的瓶颈。今天的架构设计师完全可以在确保系统拥有足够横向扩展能力的同时,实现分布式的事务级(XA)强一致性保证:

    如上图所示,在 NewSQL 具备了良好的横向扩展能力后,架构中不再迫切需要分布式缓存和 NoSQL 产品来弥补这方面的短板,这使得设计和开发工作再次回归到了最初的简洁和清晰。而对象存储(Object Storage)服务则提供了对音频、视频、图片、文件包等海量非结构化BLOB数据的存储和访问支持。

    这样简洁、清晰、朴素的架构使一切看起来仿佛回归到了多年以前,对象存储服务就像 FAT、NTFS、Ext3 等磁盘文件系统,NewSQL 服务则好像当年 MySQL、SQL Server 等 "单机版" 数据库。但一切却又已不同,业务逻辑、数据库和文件存储均已演进成为支持横向扩展的高可用集群,在性能、容量、可用性、可靠性、可伸缩性等方面有了巨大的飞跃:人类总是以螺旋上升的方式不断进步——在每一次看似回归的变迁中,实包含了本质的升华。

    随着 GlusterFS、Ceph、Lustre 等可 mount 且支持 Native File API 的分布式文件系统越来越成熟和完善,也有望于大部分场合下逐渐替换现有的对象存储服务。至此 Web App 架构的演进才能算是完成了一次重生——这还算不上是涅槃,当我们能够在真正意义上实现出高效、高可用的多虚一(Single System Image)系统时,涅槃才真正降临。那时的我们编写分布式应用与如今编写一个单机版的多线程应用将不会有任何区别——进程天然就是分布式、高可用的!

     

    三层架构的可伸缩性

    小到集中部署于单台物理服务器或 VPS 内,大到 Google 遍及全球的上百万台物理服务器所组成的分布式应用。前文描述的三层 Web 应用架构体现出了难以置信的可伸缩性。

    具体来说,在项目验证、应用部署和服务运营的初期阶段,可以将以上三层服务组件集中部署于同一台物理服务器或 VPS 内。与此同时,可通过取消 memcached 服务,以及使用资源开销小并且易于部署的嵌入式数据库产品来进一步降低部署难度和系统整体资源开销。

    随着项目运营的扩大和负载的持续加重,当单服务器方案和简单的纵向扩展已无法满足项目运营负荷时,用户即可通过将各组件分布式地运行在多台服务器内来达到横向扩展的目的。例如:反向代理可通过 DNS CNAME 记录轮转或 3/4 层转发(LVS、HAProxy等)的方式实现分布式负载均衡。应用服务则可由反向代理使用基于轮转或最小负载优先等策略来实现分布式和负载均衡。此外,使用基于共享 IP 的服务器集群方案也能够实现负载均衡和容错机制。

    与此类似,memcached 和数据库产品也都有自己的分布式运算、负载均衡以及容错方案。此外,数据库访问性能瓶颈可通过更换非关系式(NoSQL)的数据库产品,或使用主-从数据库加复制等方式来提升。而数据库查询性能则可通过部署 memcached 或类似服务来极大程度地改善。

    展开全文
  • 分布式架构 高并发处理

    千次阅读 2019-05-05 21:44:34
    微服务架构 高并发处理 高并发介绍 在同时或者极短时间内,有大量请求到达服务端,每个请求都需要服务端耗费资源进行处理,并做出相应反馈 服务端比如同时开启进程数,能同时运行的线程数、网络连接数、CPU运算...
  • 高并发电商平台架构实践

    千次阅读 2016-09-02 09:45:39
    层,事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器 / 反向代理软件。可以针对域名、目录结构、正则规则针对 http 做一些分流。通过 端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态...
  • 本文来自携程技术中心基础业务研发部的《应用架构涅槃》系列分享。据基础业务研发部负责人李小林介绍,互联网二次革命的移动互联网时代,如何吸引用户、留住用户并深入挖掘用户价值,在激烈的竞争中脱颖而出,是各大...
  • 一、高并发架构设计杂写

    千次阅读 2016-07-27 16:29:37
    解决企业搞并发的痛点,难在哪里?有套路吗? 我想随便讲讲大数据高并发貌似很高大上的内容...从物理架构上来说,怎么做好负载、集群、转发或者就近代理。从软件的角度也无非怎么做缓存、动静分离、读写分离等。  
  • 在不同的架构设计方法中出现的软件架构视图种类很多,本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图,并通过具体案例的分析说明如何运用它们进行架构设计。 当观察和描述事物大局的时候,逻辑架构和...
  • 在这样的情况下,高性能的物理硬件固然是基础,然而如果开发人员不了解与 Java 高并发相关的技术原理,就无法写出最优化的代码。 市面上 Java 相关的书籍,大多比较适合初学者,只涵盖基础内容,并不多见那种深入...
  • 虹膜登录系统的扫描、处理和识别过程处于同一物理机下,会导致存在用户使用代价高和受益用户少等问题。为此,基于BIS架构构建一种虹膜登录系统模型。通过网络实现扫描端和处理端的分离,将虹膜扫描端置于浏览器中,处理...
  • 构建高并发高可用的电商平台架构实践

    万次阅读 多人点赞 2013-10-03 14:42:24
    各个维度总结电商平台中的高并发高可用的架构实践,从架构设计的理念到平台的逻辑架构,以及到平台架构中各个模块的介绍
  • 高并发系统数据库架构设计

    千次阅读 2016-06-08 11:56:22
    在WEB网站的规模从小到大不断扩展的过程中,数据库的访问压力也不断的增加,数据库的架构也需要动态扩展,在数据库的扩展过程基本上包含如下几步,每一个扩展都可以比上一步骤的部署方式的性能得到数量级的提升。...
  • 在这种新形势下,传统应用架构不得不变,做为工程师也必然要自我涅槃,改为大数据及新的高并发架构,来应对业务需求激增及高速迭代的需要。计算分层分解、去SQL、去数据库化、模块化拆解的相关技改工作已经刻不容缓...
  • 逻辑架构和物理架构

    千次阅读 2018-10-16 16:04:34
    逻辑架构和物理架构 在实际工作中,我们经常听到“架 构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什 么,更...
  • 高并发高负载系统架构

    千次阅读 2012-12-03 17:56:40
    而后在Yahoo3721负载搜索引擎前端平台开发,又在猫扑处理过大型社区猫扑大杂烩的架构升级等工作,同时自己接触和开发过不少大中型网站的模块,因此在大型网站应对负载和并发的解决方案上有一些积累和经验,可以和...
  • 导读:分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分别部署在不同的服务器上,是网站拥有更多的计算资源以应对...
  • 这代表着系统能够容纳更的负载、更大的数据集,并且系统是可维护的。扩展和语言、某项具体的技术都是无关的。扩展可以分为两种:1. 垂直扩展(stade up),通俗的说就是将某台单一的机器的性能提升的更,如添加...
  • 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 物理架构4.4.6 开发...
  • 大数据和高并发解决方案

    千次阅读 2019-04-29 15:59:24
    是对于一些高并发的并且修改频繁修改的数据,在每次修改的时候首先将数据保存到缓存中,然后定时将缓存中的数据保存到数据库中,程序可以在读取数据时可以同时读取数据库中和缓存中的数据。 例如:我现在在编写这...
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...
  • 从各个角度总结了电商平台中的架构实践,由于时间仓促,定了个初稿,待补充完善,欢迎大家一起交流。 转载请声明出处:http://blog.csdn.net/yangbutao/article/details/12242441 作者:杨步涛 关注分布式架构、...
  • 架构设计,难免有时候被人问及系统的瓶颈在哪,那首先来了解下什么是瓶颈? 打个形象的比方,人的嘴巴可以吞下一整个面包,但是却咽不下去,因为食管不给力,它比较细,所以嘴巴能吞下的食物大小要受到食管的粗细...
  • 为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战,大型互联网公司在实践中提出了许多解决方案,以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又...
  • 高并发Web架构

    千次阅读 2015-11-26 15:38:44
    高并发Web架构 (一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 80,430
精华内容 32,172
关键字:

高并发物理架构