巨型网址技能架构(2):架构要素和高品质架构

模式:不断重复发生的问题以及解决问题的核心办法,特征是可重复性。

大型网站技术架构核心原理与案例分析(三)大型网站核心架构要素

  • 性能
  • 可用性
  • 伸缩性
  • 扩展性
  • 安全性

架构设计中要考虑的核心五要素;
性能、可用性、扩展性、伸缩性、安全性

上一篇我们把整个架构演变过程大致说了一下,这次我们来说说从哪方面进行考虑设计

大型网站技术架构核心原理与案例分析(二)大型网站架构模式

一、分层

分层是从纵向层面来说的,也可以说是从技术层面来看的,主要分为应用层,服务层,数据层、

应用层:与用户实现交互,MVC是当今最流行的模式、

服务层:为应用层提供各种服务支撑接口,例如登陆验证服务,购物车服务,用户管理服务等、

数据层:提供底层数据支撑,例如数据库,文件系统,搜索,缓存、

分层的好处在于各层之间低耦合,高内聚、

各层之间独立开发,通过服务接口建立联系,实现通讯,这是分布式部署的前提,为网站的后续升级扩大奠定基础、

一、性能

从浏览器导数据库,影响用户请求的所有环节都可以进行性能优化。

  • 浏览器端:浏览器缓存、页面压缩、页面布局、减少cookie等手段;CDN和反向代理服务器
  • 应用服务器:本地缓存和分布式缓存;异步消息队列;集群;代码层面使用多线程、改善内存管理等。
  • 数据库:索引、缓存、SQL优化都比较成熟;NoSQL

衡量指标:响应时间、TPS、系统性能计数器等

性能

为了使网站的能够应对高并发访问,海量数据处理,高可靠运行等一系列问题,我们可以选择横向或纵向两个方向来入手

一、网站架构模式

二、分割

分割是从横向层面而言的,是从业务层面来看的、分割的目的在把一个庞大的软件系统尽可能的切割成若干个功能模块,化大为小,化繁为简、

分割同时也带来了运维的便利,可以方便问题的跟踪定位、

二、可用性

网站高可用的主要手段是冗余

性能的测试指标

  • 响应时间
    应用执行一个操作需要的时间,包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标,直观地反映了系统的“快慢”。下表列出了一些常用的系统操作需要的响应时间。
    图片 1

  • 并发数
    系统能够同时处理请求的数目

  • 吞吐量
    单位时间内系统处理的请求数量;
    如:TPS、QPS(每秒查询数)

随着并发数的增大,吞吐量随着增大;
超过阈值后,并发数继续增大,吞吐量下降,直到吞吐量降为0,网站宕机;

理解上述3个指标:类比高速公路行车
吞吐量就是每天通过的车辆数
并发数是正在行驶的车辆
响应时间是车速


分层

大型网站一般分为三层:

  • 应用层
  • 服务层
  • 数据层

实践中,每一层还可以细分。如应用层又分为视图层和业务逻辑层;服务层分为数据接口层和逻辑处理层。

分层是逻辑上的。在物理部署上,三层可以部署在同一个物理机器上。但随着网站业务的发展,必然要做分离部署。

三、分布式

分层和分割的目的是为了分布式部署,即将不同的服务部署在不同的机器上面,彼此之间通过远程调用协同工作、

分布式部署可以使软件使用更多的CPU,内存和存储资源,能够处理更大的并发量,为更多的用户提供服务、

三、伸缩性

衡量架构伸缩性的主要标准是是否可以使用多台服务器构建集群,是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供与原来无差别的服务。集群中可容纳的总的服务器数量是否有限制。

  • 应用服务器集群,使用合适的负载均衡设备就可以不断添加服务器
  • 缓存服务器集群,新加入的服务器可能导致缓存路由失效,进而导致集群中大部分缓存数据都无法访问。需要改进缓存路由算法。
  • 关系型数据库支持数据复制,主从热备等机制,但很难做到大规模集群伸缩性。因此必须在数据库外实现,通过路由分区等手段将部署有多个数据库的服务器组成集群。
  • NoSQL数据库产品通常对伸缩性支持良好

性能测试方法

  • 性能测试
    以预期设定的性能值为目标,测试是否能满足预期
  • 负载测试
    不断加压到安全临界值
  • 压力测试
    超过安全负载直到崩溃下的最大负载

下图中的横坐标表示消耗的系统资源,纵坐标表示系统处理能力(吞吐量)。在开始阶段,随着并发请求数目的增加,系统使用较少的资源就达到较好的处理能力(a~b段),这一段是网站的日常运行区间,网站的绝大部分访问负载压力都集中在这一段区间,被称作性能测试,测试目标是评估系统性能是否符合需求及设计目标;随着压力的持续增加,系统处理能力增加变缓,直到达到一个最大值(c点),这是系统的最大负载点,这一段被称作负载测试。测试目标是评估当系统因为突发事件超出日常访问压力的情况下,保证系统正常运行情况下能够承受的最大访问负载压力;超过这个点后,再增加压力,系统的处理能力反而下降,而资源消耗却更多,直到资源消耗达到极限(d点),这个点可以看作是系统的崩溃点,超过这个点继续加大并发请求数目,系统不能再处理任何请求,这一段被称作压力测试,测试目标是评估可能导致系统崩溃的最大访问负载压力。

图片 2

性能测试反应的是系统在实际生产环境中使用时,随着用户并发访问数量的增加,系统的处理能力。与性能曲线相对应的是用户访问的等待时间(系统响应时间),如图所示。

图片 3

在日常运行区间,可以获得最好的用户响应时间,随着并发用户数的增加,响应延迟越来越大,直到系统崩溃,用户失去响应。

基本思路

首先可以对整个架构进行分层,一般可以分为
应用层服务层数据层;实践中,大的分层结构中还可以继续分层,比如
应用层 还可以继续分为 视图层业务逻辑层,服务层也可以继续细分为
数据接口层 逻辑处理层

通过分层,我们把一个庞大的系统切分为不同的部分,便于分工开发和维护;各层之间相互有一定的独立性,在网站的开发中可以根据不同的需求进行相应的调整

逻辑上分层之后,在物理部署上也可以根据需求制定不同的策略,刚开始可以部署在同一台物理机上,但是随着业务的发展,必然要对不同的模块进行分离部署

分层架构不仅仅是为了规划软件的逻辑结构以便于开发维护,随着网站的发展,分层架构对网站的高并发分布式架构来说尤为重要

进行了分层以后,接下来可以从纵向进行业务分割

根据不同的业务模块一个项目划分成不同的模块交给单独的团队去开发部署,完成后分别部署在不同的服务器上,通过链接进行互联

再根据不同情况来对不同的节点进行冗余来保证网站的高可用性

接下来进行缓存,CDN,反向代理等等的优化,这里以后再细说


好了,现在我们开始进入正题

分割

按功能纵向分割。大型网站的分割粒度会很细。如应用层按业务,将购物、论坛、搜索、广告分割成不同的应用,由独立团队负责,部署在不同服务器上;在同一个应用内部,如果业务复杂,会继续进行分割,如购物业务可以细分成机票酒店、3C、小商品等业务。

3.1 问题:

1、服务调用必须通过网络,网络传输对性能影响较大、

2、服务器越多,宕机的可能性就越大,若在一个机器中部署多个服务,会降低网站的可用性、

3、数据一致性、分布式事务、会话保持,如何在分布式环境中解决

4、分布式网站导致错误错综复杂,开发管理维护变得困难、

建议:量力而行,按需配置、

四、扩展性

扩展性是对新业务而言的。是否很容易上线新产品,而不必或很少改动既有业务功能。

网站可伸缩架构的主要手段是事件驱动架构分布式服务

事件驱动架构通常利用消息队列实现,将用户请求和其他业务事件构造成消息发布到消息队列,消息的矗立着作为消费者从队列中获取消息进行处理。通过这种方式将消息生产者和消费者分离,可以透明地增加消息生产者任务或消费者任务。

分布式服务则是将业务可复用服务分离,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更时,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。

大型网站为了保持市场地位,还会吸引第三方开发者,调用网站服务,使用网站数据开发周边产品,形成所谓的“生态”。

性能测试报告

测试结果报告应能够反映上述性能测试曲线的规律,阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息,下表是一个简单示例。

图片 4

 

 

架构要素

首先,对于一个高访问量,大数据量的网站我们需要考虑什么呢?


分布式

分层和分割是为了切分后的模块便于分布式部署,但分布式部署也带来其他问题。

  • 网络。服务调用通过网路,严重影响性能。
  • 服务器越多,宕机概率越高,网站可用性降低。
  • 数据一致性和分布式事务难以保证。
  • 导致网站依赖错综复杂,开发管理维护困难。

因此切莫为了分布式而分布式。

常用的分布式方案有以下几种:

  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算
  • 分布式配置
  • 分布式锁
  • 分布式文件系统
3.2 方案:

1、分布式应用和服务

将分层和分割后的应用与服务分布式部署,可以改善系统并发性能和发布速度,减少数据库连接资源消耗,可以使不同应用复用数据库链接、

2、分布式静态资源

动静分离:把网站涉及的JS,CSS,HTML等静态资源与应用服务器分离,独立分布式部署,既提高了网站的响应速度,又降低了应用服务器的负担、

3、分布式数据与存储

大型网站涉及海量数据的处理,海量数据的存储是一个基础性问题,原有的集中式采用磁阵列的方式,对于IO,带宽,容量都带来了极大的挑战、分布式

存储是解决这种问题的唯一途径,分布式存储是分布式计算的前提、

4、分布式计算

海量数据的处理不是一台性能很强的机器能够完成的,必须依靠集体的力量,大家同时工作,才能实现数据的快速处理,给予用户及时响应、

分布式存储是基础,分布式计算是目的、

5、分布式锁

对于同一个资源的并发操作就涉及到分布式锁,例如储户银行借记卡余额,需要对其扣钱和转账操作,如果没有锁就可能出现问题、关系型数据库操作普遍使用锁,

例如update,在此过程中记录是被加锁的、

6、分布式配置

同一个应用在多个节点部署,有时需要在修改配置文件,如何实现一处更改,全部节点即时生效,这就是分布式配置要解决的问题、

目前国内有百度的disconf和淘宝的diamond、

五、安全性

针对现存和潜在的各种攻击与窃密手段,是否有可靠的应对策略。

可用性

性能

首先就是性能了,性能是一个网站的的重要指标,除非是没得选择,就这一个网站,不然用户是绝对不会忍受一个超级慢的网站

正因为性能问题无处不在,解决性能问题的方式也各种各样,从用户请求一个 url
开始,进行的每一个环节都可以进行优化;根据上面的分层,可以大致从三个方面进行优化,应用层优化,服务层优化,数据层优化

涉及到的知识就是 web
前端的优化,应用服务器端的优化和数据的存储,索引,缓存等,这些在后面的内容里会分别展开细说

但性能只是一个网站的必要条件,除此之外,因为无法预知网站可能会面临的压力或是攻击,我们还要保证网站在各种情境下(高并发,高负载,持续压力不均匀等)保持稳定的性能


集群

集群、负载均衡提高可用性。

四、集群

分布式解决了单兵作战的弱点,而集群是解决如何构建一个更加强大的作战集体、在分布式基础上,集群可以做到负载均衡,自动失效转移等等、

高可用的应用服务器

构建高可用的应用服务器关键是session的处理,如果能使得每天机器上处理的请求都无状态,即可实现应用服务器的线性伸缩;服务器宕机后也可随时将请求放到其它机器上再次处理;
而对于需要处理状态信息的应用,解决方案是让每台机器使用共享的Session服务器,本地上还是无状态特征;

可用性

对于大型网站而言,出现宕机的情况是可怕的,因为你可能有上千万的用户量,短短几分钟的宕机都有可能导致网站声誉扫地,如果是电商类的网站,更可能会导致用户的财产损失,甚至会摊上官司,那时候损失的就不仅是金钱和用户了

因此我们要保证能够提供每天 24 小时的可用,但实际中服务器并不能保证每天
24
小时都能平稳的运行,可能出现硬件问题,也可能出现软件问题,总之问题总是会有的

所以我们高可用设计的目标就是在某些服务器宕机的情况下,也能够保证服务或应用正常运行

网站高可用的主要手段是
冗余,应用部署在多台服务器上同时提供访问,数据存储在多台数据服务器之间互相进行热备份,这样任何一台服务器宕机都不会影响服务或应用的整体,也不会产生数据丢失

对于应用服务器而言,多台应用服务器通过一个负载均衡设备组成一个集群同时对外提供服务,当一台服务器宕机后,服务切换到其他服务器上继续执行,这样就可以保证了网站的高可用性,前提是应用服务器不允许存储用户会话信息,否则将会丢失,这样即使用户请求转接到其他服务器上面也无法继续执行

对于数据存储服务器,要提供服务器之间的实时备份,这样当一台服务器宕机的时候,将数据访问切换到其他服务器上,并进行数据恢复和备份

衡量一个系统架构设计是否满足高可用的目标,就是假设其中一台或多台服务器宕机以及出现各种不可预期的问题时,系统整体是否依然可用


缓存

缓存可以加快访问速度,减轻后端应用和数据存储的负载压力。

  • CDN:内容分发网络,部署在离终端用户最近的网络服务商。如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN.
  • 反向代理:属于网站前端架构的一部分。用户请求到达网站所在的数据中心时,最先到达反向代理服务器。缓存静态资源。
  • 本地缓存:应用服务器本地缓存着热点数据,应用程序可以在本机内存中直接访问数据,无需访问数据库。
  • 分布式缓存:大型网站数据量大,单机不能承受内存空间消耗,需要专门的分布式缓存集群。

使用缓存有两个前提条件:

  • 数据访问热点不均衡,有些数据会被频繁访问。
  • 数据在某个时间段有效,不会很快过期。

五、缓存

缓存是改善软件性能的第一手段、缓存适用于频繁读取,较少更新,且长期有效的数据,例如软件系统启动时的配置文件,首页,字典数据等等、

高可用的服务

设计要点

  • 分级管理
    区别核心应用和一般应用;在流量增加到超过网站的处理能力时,为了保证核心应用的可用性,可以将一般应用的服务停止,将资源让位给核心服务;
    比如博客中的博文显示和博客的评论功能;
  • 超时设置
  • 异步调用
  • 服务降级
    eg:twitter:随机拒绝部分请求
  • 幂等性设计
    保证多次调用结果一致

伸缩性

面对着大量用户的高并发访问和海量的数据存储,不可能只用一台服务器就能够满足全部需求,存储全部数据

通过 集群 的方式将多台服务器组成一个整体共同提供服务,所谓 伸缩性
就是指通过不断向集群中加入服务器的手段来应对不断上升的用户并发访问压力和不断增长的数据存储需求

对于应用服务器集群,只要服务器上不存储数据,所有的服务器都是对等的,通过使用合适的负载均衡设备就可以向集群中不断加入新的服务器

对于缓存服务器而言,加入新的服务器可能会导致缓存路由失效,从而导致大部分的缓存数据都无法访问,需要改进缓存路由算法来保证缓存数据可访问

关系数据库虽然支持数据复制,主从热备份等机制,但是很难实现大规模集群的可伸缩性


异步

单一服务器内部可以通过多线程共享内存队列的方式实现异步;分布式系统中,多个集群通过分布式消息队列实现异步。

分布式消息队列可以看做内存队列的分布式部署

异步架构是典型的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以随意变化。

异步消息队列还有如下特性:

  • 提高系统可用性。消费者服务器发生故障后,数据会在消息队列服务器堆积,生产者可以继续处理业务。消费者服务器恢复后可以继续处理消息队列中的数据。
  • 加快网站响应速度。生产者写入消息队列后即可返回,不必等待消费者处理。
  • 削峰。将突然增加的访问请求数据放入消息队列中,等待消费者处理。

需要注意的是,使用异步方式处理业务可能会对用户体验、业务流程造成影响,需要网站产品设计方面的支持。

方案:

1、CDN

部署在距离用户最近的网络服务运营商,用户的网络请求最新到达网络服务商,在网络服务商机房中缓存网站的一些静态资源,例如首页,可以做到以最快的速度给予用户响应、

2、反向代理

反响代理属于网站前端架构的一部分,部署在网站的前端,在数据中心,当用户请求到达数据中心时,最新访问到反向代理,在这里缓存网站的静态资源,无需通过应用服务器给予

响应、

3、本地缓存

在应用服务器内部缓存热点数据,无需查询服务器获取、

4、分布式缓存

大型网站需要缓存很多数据,单个应用服务器无法满足,同时单个缓存服务器会有宕机的问题、分布式缓存可以横向扩充,同时也避免的单点故障、

高可用的数据

CAP原理
一个提高服务的存储系统无法同时满足以下三个条件
一致性(Consistency)
数据可用性(Avalibility)
分区耐受性(Patition Tolerance,系统具有跨网络分区的伸缩性)

WEB架构设计中,通常为了保证高可用性,会牺牲一致性;

数据一致性分为:强一致、用户一致、最终一致;
大型WEB站点一般只保证数据的最终一致性;

可扩展性

网站的扩展性直接关系到网站功能模块的开发,网站快速发展,功能也不断的增加

网站架构的可扩展性的主要目的是使其能够快速的应对需求变化

是为了能够在增加新业务时,尽量实现对现有产品无影响,不需要改动或是改动很少现有业务就能够上线新产品;不同的产品业务之间的耦合度很小,一个产品或业务的改动不会对其他造成影响

大型网一定会吸引到第三方开发者,调用网站服务,开发周边产品,扩展网站业务,这都需要网站提供开放平台接口


冗余

  • 冷备份,数据库定期备份,存档
  • 热备份,数据库主从分离,实时同步
  • 灾备数据中心,全球范围部署

六、异步

系统解耦的手段除了分层、分割、分布式,异步也是一个重要的手段,系统之间的消息传递不再是同步调用,而是将一个业务操作分成多个阶段,每个阶段通过共享数据的方式进行协作、

扩展性

在网站新增业务产品时,实现对现有产品无影响,透明上线新产品。
主要手段

  • 事件驱动
    利用消息队列实现
  • 分布式服务
    将业务和可复用服务分离开

安全性

最后的就是安全性了,互联网是一个开放的平台,任何人在任何地方都可以访问网站,安全架构就是保护网站不受恶意的访问和攻击,保护数据不被窃取


性能,可用性,伸缩性,扩展性,安全性使网站架构的几个核心要素,我们网站架构的目的主要就是为了解决这几个问题,接下来都会分别进行介绍


自动化

  • 自动化代码管理,版本控制、分支创建合并等过程自动化,开发工程师只要提交自己参与开发的产品代号,系统就会自动为其创建开发分支,后期自动代码合并
  • 自动化测试
  • 自动化安全检测
  • 自动化部署
  • 自动化监控、告警,服务器宕机、程序bug、存储空间不足、突然爆发的访问高峰
  • 自动化失效转移,将失效的服务器从集群中隔离,不再响应系统中的应用请求。
  • 自动化失效恢复
  • 自动化降级,拒绝部分请求,关闭部分不重要的服务将负载将至安全水平
  • 自动化分配资源,将空闲资源分配给重要的服务
举例:

用户注册:用户填写注册信息,点击提交,系统返回注册成功与否的信息,并发送邮件和短信通知、

动作:保存注册信息,发送邮件,发送短信

同步调用:先保存注册信息,接着发送邮件,再发送短信、

异步调用:保存注册消息,发送消息通知(邮件消息,短信消息),再由邮件消费者和短信消费者分别读取消息后,各自发送短信和邮件、

在同步调用中如果邮件服务器有问题,那么用户就会在线等待很长时间,同理短信也是如此、

而异步则避免了上述问题、

伸缩性

通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力。
可能加入的服务器有以下4类,其伸缩性能各不相同;

高性能架构

说到高性能,在不同角色的眼中对于性能的定义也不同

  • 用户视角:
    用户感受到的性能,就是从提交后到看到页面的时间,不同计算机性能的差异,不同浏览器解析
    HTML
    的速度,不同网络提供商提供的互联网服务的速度,这些差异都会导致实际时间远大于服务器处理请求的时间
    实践中,我们可以用一些前端架构优化的手段,通过优化 HTML
    样式,利用浏览器异步和并发的特性,调整缓存策略,使用 CDN
    服务,反向代理等,使用户能够尽快的看到内容,即使不对应用服务优化,也能够很好地改善用户体验
  • 开发者视角:
    开发者更关注的是应用服务器的性能,包括响应延迟,系统吞吐量,并发处理,系统稳定性等>
    主要优化手段可以利用缓存加速数据读取,使用集群提高吞吐量,使用异步加快请求响应,优化代码改善程序等
  • 运维人员视角:
    对于运维人员,会更关注一些基础设施的性能和利用率,这里不再多说

安全

  • 通过密码、手机校验码进行身份认证
  • 网络通信加密
  • 验证码
  • 对XSS攻击、SQL注入进行编码转换
  • 对垃圾信息进行过滤
  • 对交易转账等操作进行风险控制
优点:

提高系统可用性加快网站响应速度消除并发访问高峰注意:

在使用异步时,会对用户体验产生影响,必须事先设计好业务流程、

应用服务器

通过设计实现集群内服务器对等,使用合适的负载均衡可保证良好的伸缩性;

性能测试指标

主要的性能测试指标有 响应时间 并发数 吞吐量 性能计数器

  • 响应时间
    指的是从发出这个请求开始到接收到数据的时间,一般情况下这个时间都非常非常的小甚至小于测试的误差值,所以我们可以采用重复请求的方式来获取具体的响应时间,比如请求十万次,记录总时间,然后计算出单次请求的时间

  • 并发数
    指能够同时处理的请求数目,对于网站而言,即并发用户数>
    有几个词可能会产生混淆,这里解释一下
    网站系统用户数 > 网站在线用户数 > 网站并发用户数

  • 吞吐量
    是单位时间能能够处理的请求数,体现的系统的整体处理能力>
    衡量指标有很多,可以是 请求数/秒 页面数/秒 访问人数/天
    处理业务数/小时 等> 常用的量化指标有 TPS(每秒事务数)
    HPS(每秒 HTTP 请求数) QPS(每秒查询数)

  • 性能计数器
    描述服务器或操作系统的一些性能指标,包括系统负载(System
    Load),线程数,内存使用,磁盘和网络 I/O
    等,当这些值超过警告值(安全临界值)时,就会想开发运维人员报警,及时处理异常


二、新浪微博

七、冗余

节点冗余;数据备份冗余;灾备数据中心

缓存服务器

缓存服务器伸缩性良好,但新加入服务器后可能导致缓存路由失效;
通过改进缓存路由算法,比如Memcached的一致性Hash,可实现加入新的缓存服务器后对原有缓存的影响尽量减少;

性能测试方法

性能测试是一个统称,具体可以分为
性能测试负载测试压力测试稳定性测试

  • 性能测试
    以初期设计的指标为预期目标,不断对系统施压,看系统在预期的范围内,能否达到预期的性能

  • 负载测试
    对系统不断增加并发请求以增加系统压力,直到系统某项或多项指标达到安全临界值,这时继续对系统施加压力,系统的处理能力会有所下降

  • 压力测试
    在超过安全负载的情况下,继续施压,直到系统崩溃或不再能够处理任何请求,以此来计算系统的最大压力承受能力

  • 稳定性测试
    在一定的压力(不均匀施压)下,系统能够稳定的运行较长时间


图片 5

测试图

如上图所示,a-b
区间内就是网站日常的运行区间,绝大多数时间都处于这一区间内;而 c
点相当于系统的最大负载点,b-c
段就是因某些原因访问量超过了日常访问压力;超过了 c
点后,继续增加压力,这时候系统的性能就开始下降,但是资源消耗会更多,直到
d 点,系统的崩溃点,超过这个点继续加压的话,系统将不能处理任何请求

性能测试反映的是系统的处理能力,与其对应的是用户的等待时间(响应时间),如下如所示:

图片 6

响应时间

各点与上面的性能测试图都相互对应,直到系统崩溃,用户失去响应


架构

新浪微博最初是一个小网站,采用LAMP架构。应用程序使用PHP开发,所有数据都存储在MySQL数据库中。

后来业务增长,用户增加,新浪微博架构几经重构,形成现在的架构。

  • 最底层是基础服务层,DB、Cache、存储、MQ、实时搜索、IDC同步
  • 中间层是平台服务和应用服务。平台服务包含微博、关系、用户和计数。应用服务包含图片池。
  • 最上层是API和新浪微博的业务层,各种客户端(包括web网站)和第三方应用通过调用API集成到新浪微博系统中。

八、自动化

1、运维自动化

2、自动化代码

3、自动化打包

4、自动化部署

5、自动化测试

6、自动化失效转移与恢复

7、自动化降级

8、自动化资源分配

数据库服务器

很难做到大规模集群的可伸缩性
实现方式有:读写分离、数据表分库
(单表拆分:Cobar)
也可考虑伸缩性方案在数据库之外实现(通过路由分区)

性能优化策略

首先要定位问题产生原因,排查不同环节的日志,分析哪个环节的响应时间与预期不相符,然后分析影响性能的原因,是代码问题还是架构设计不合理,或者系统资源不足

然后就是性能优化,根据网站的分层架构,可以大致的分为 web
前端性能优化,应用服务器性能优化,存储服务器性能优化三大类


具体的优化方法我们下次再写,今天有些晚了,先睡了

部署

新浪微博在早期还使用过一种MPSS(MultiPort Single
Server)的分布式集群部署方案。集群中每台服务器都部署多个服务,每个服务使用不同端口对外提供服务。现在网站应用中常见的是将物理机虚拟化成多个虚拟机,在虚拟机部署应用。这样更加简单,还可以在不同虚拟机使用相同端口号。

九、安全

互联网的开放性使其从诞生开始就面临这巨大的挑战、网站在安全架构方面也积累了诸多模式:

1、通过密码和手机验证码进行身份认证

2、登陆、交易等操作需要网络通信进行加密

3、网站服务器上存储的敏感数据如用户信息等也进行加密处理

4、防止机器人程序滥用网络程序攻击网站

5、网站使用验证码进行识别

6、对于常见的Web攻击:XSS,SQL,CSRF等进行编码转换处理

7、对于垃圾信息,敏感信息进行过滤

8、对于交易转账等重要操作根据交易模式和交易信息进行风险

架构:最高层次的规划,难以改变的决定。

软件架构:有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。

NoSql产品

Nosql数据库就是为海量数据而生,可轻松实现集群规模的线性伸缩;
(Hbase使用Zookeeper选举master)

消息队列

新浪微博的早期架构中,微博发布使用同步推送模式。用户发表微博后,系统立即将微博插入到数据库所有粉丝的订阅列表中。当用户量比较大时,特别是明星用户发微博,会引发大量数据库写操作,超出数据库负载,导致系统性能急剧下降。后来改用异步推拉结合的模式,用户发表微博后,系统将微博写入消息队列后立即返回,用户迅速得到响应。消息队列的消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登陆后再根据关注列表拉去订阅列表。

一、性能

性能是网站的一个重要指标,没有人会忍受慢速。

性能的优化是多层次的,如下:

客户端CDN反向代理应用服务器代码数据库。。。反映性能的指标有:

并发量吞吐量响应时间TPS性能计数器。。。

安全性

99.99%的设计标准:无单点、在线更新、自动切换

缓存

由于微博频繁刷新,新浪微博采用多级缓存策略:

  • 热门微博和明星用户的微博缓存在所有微博服务器上
  • 在线用户的微博和近期微博缓存在分布式缓存集群中

微博操作中的“刷微博”几乎全部都是缓存访问操作,可以获得很好的系统性能。

二、可用性

可用性的重要性取决于业务,如果业务可以忍受,断个几个小时都没有关系。但是对于电子商务类的网站,这是绝对不行的。经常发生停止服务,

会损失大量的金钱,同时客户也会流失。

做的好的大型网站,可用性会有4个9。

附:思维导图

卓越亚马逊地址:
《大型网站技术架构》
点击查看原图

图片 7

Posted by: 大CC | 13APR,2014
博客:blog.me115.com
[订阅]
微博:新浪微博

多数据中心

三、伸缩性

随着业务的不断发展,用户量的不断增加,数据的不断增长,系统也会随之面临更大压力。这就是体现伸缩性的时候,如果大动干戈,则伸缩性的设计

必定不好。如果仅仅添加新的服务器,就可以化解当前的压力,则是伸缩性好的体现。

衡量架构伸缩性的主要标准就是是否可以用多台服务器服务器构建集群,是否容易想集群中添加新的服务器。加入新的服务器是否可以提供无差别的服务。集群中

容纳的服务器数量是否有限制。

自动化工具

四、扩展性

不同于其他架构要素抓哟关注非功能需求,扩展性则直接关注功能性需求。

衡量网站扩展性好坏的主要标准就是在网站增加新的业务产品是,是否可以实现对现有产品透明无影响,不需要任何改动或少许改动就可以上线。

网站可扩展架构的主要技术手段有事件驱动和分布式服务。

事件驱动架构:通常用消息队列来实现。分布式服务:将业务和可复用服务分开,通过分布式服务框架调用。

安全

五、安全性

网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。

衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段,是否有可靠的应对策略。

图片 8

三、总结

山寨与创新的区别在于对问题和需求的真正理解与把握。

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图