如何读懂Web服务的系统架构图

Web服务的一个重要特点就是流量大、数据多,仅靠一台服务器肯定难以支撑大规模的服务。 所以我们经常会看到诸如以下的一些术语,教人好生不懂:

*:系统架构、物理架构、Web服务基础设施

*:应用服务器

*:数据库服务器

*:索引服务器

*:反向代理服务器

*:缓存服务器

*:分布式、可扩展性

*:cpu负载、IO负载

如果你也不懂,那么本文对你来说就是一个很好的开始,关于web服务架构方面,前面还有几篇不错的文章可供参考阅读---大型网站架构演化历程(上)、大型网站架构演化历程(下)、大型网站的灵魂——性能(请戳我)。

本文的主要目标—读懂下面这张图例:

cpu负载和I/O负载

我们从CPU和IO说起。 一个典型的Web服务就是网站服务——用户通过浏览器向服务器发起请求,服务器从数据库提取数据后,加工处理返回HTML页面给用户。

上图中的4个箭头“<—”都需要消耗Server的CPU计算资源,而从Database中获取数据则消耗IO资源。 当用户数量、请求数量上升时,Server的CPU资源告急(IO资源负载也有增加);当储存的数据量上升时,Server的IO资源也要告急。

比如说单台Server每分钟可以处理3000次请求(PV, Page View),那么每月就可以处理100万PV,超过这个数量服务器就撑不住了; 每次请求都需要从文件系统提取数据的话,由于读取磁盘所需的时间是内存的100000-1000000倍,每分钟的请求数多了数据提取速度必然跟不上,数据库就挂了。

可扩展性

如何处理规模逐渐增大服务需求呢?这要求你的系统要有可扩展性:

横向扩展:横向扩展又叫分布式,一台Server撑不住我就多来几台。 但现实远比理想复杂。

纵向扩展:纵向扩展是金融高富帅或者企业软件比较常采用的方法,因为服务器的价格和性能不成正比,性能达到一定程度后,每一分性能的提高需要投入更多的钱——服务器性能的边际价格是不断上升的。 对于互联网的草根创业团队来说,这显然是不可接受的。

cpu能力的扩展

CPU负载的分散比较容易,因为CPU的计算不存在依赖性,即当前请求的结果不依赖于上一次请求的结果。 HTTP协议的stateless就是一个很好的例子。 这样CPU撑不住的时候,我直接clone几台完全一起的就好了,而被克隆的这种服务一般就称作应用服务器。

应用服务器和Web服务器的界限并不很清晰。 Web服务器负责接收用户发过来的请求和返回资源对象给用户,而应用服务器则负责通过计算产生这个资源对象(比如调用CGI脚本)。

这样CPU的负载问题就解决了,我们的架构变成了这个样子。

I/O能力的扩展

内存读取的速度远高于磁盘,根据操作系统缓存(Cache)的原理,我们提高数据读取速度的基本思路是——提高内存大小可以显著的降低IO负载,即为你的Server换上更大更多的内存条。 相应的基本方针——当操作系统的缓存无法处理时,再进一步考虑分布式。 IO负载分散的本质也就是廉价小容量内存的分散。

IO负载的分散可比CPU的难多了,由于存在数据同步的问题,我们这里不讨论数据库服务器之间全盘的数据复制和冗余化。 既然数据量太大,大到一台服务器的内存装不下,那我们就把数据分割开来——数据分割(数据压缩也可以达到一定的效果)。

Web服务的请求是存在访问模式,比如爬虫和普通用户的访问(爬虫会请求很早以前的页面,而普通用户大多访问当前的热门页面),我们把应对用户的热门的资源对象放在一台服务器,应对爬虫的资源对象放在另一台。

即使不存在访问模式,我们也可以通过分区(Partitioning),即表分割来做到。 比如现在MySQL数据库里有一个用户ID表,用户量增长后表的record数是13亿,我们根据ID的大小来排序,分割成几个ID表,每个表几千万个ID,这样单个表大小就是GB级别——内存够装了。

不管是哪一种情况,我们都需要一台索引服务器,来做应用服务器和数据服务器的mapping。

那么现在我们的架构就是:

本文的说明就到这里为止了,相信你现在再回头看开头的那张系统架构图将会非常容易了吧。

转自:灯塔大数据

原文地址:https://www.cnblogs.com/zytrue/p/8494268.html

时间: 2024-11-13 10:44:54

如何读懂Web服务的系统架构图的相关文章

Spring Cloud--鸿鹄Cloud分布式微服务云系统—架构图

这边结合了当前大部分企业的通用需求,包括技术的选型比较严格.苛刻,不仅要用业界最流行的技术,还要和国际接轨,在未来的5~10年内不能out.作为公司的架构师,也要有一种放眼世界的眼光,不仅要给公司做好的技术选型,而且还要快速响应企业的业务需求,能够为企业快速定制化业务. 以下是我为公司规划的大型互联网分布式企业微服务云架构: 从现在开始,我这边会将近期研发的spring cloud微服务云架构的搭建过程和精髓记录下来,帮助更多有兴趣研发spring cloud框架的朋友,大家来一起探讨sprin

零售系统架构图

对零售系统分析了下,然后设计了个架构图,基本有了这个架构图,剩下就是对具体页面功能逻辑进行设计而已.在设计这个架构图的过程,有一些想法 1.业务是基于网上一个文章“新零售-从业务到产品”有兴趣可以看看,文章上面也有一套架构图.不过看了文章及架构,是基于自身业务逻辑来设计,而不是基于通用saas设计,所以抽离了下. 2.基于saas设计的一些考虑点: A.要考虑客户可能没有WMS.TMS.ERP等系统情况,说白了,就是要考虑完全没有外部系统的情况下,单靠这套系统就能撑起来所有业务.一开始是没有增加

微服务架构理解[架构图]

微服务架构 概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议. 定义:围绕业务领域组件来创建应用,这些应用可独立地进行开发.管理和迭代.在分散的组件中使用云架构和平台式部署.管理和服务功能,使产品交付变得更加简单. 本质:用一些功能比较明确.业务比较精练的服务去解决更大.更实际的问题. 基于微服务架构的设计: 目的:有效的拆分应用,实现敏捷开发和部署 微服务的具体特征 官方的定义: 1.一些列的独立的服务共同组成

Java架构:一文读懂微服务架构的重构策略

你很有可能正在处理大型复杂的单体应用程序,每天开发和部署应用程序的经历都很缓慢而且很痛苦.微服务看起来非常适合你的应用程序,但它也更像是一项遥不可及的必杀技.如何才能走上微服务架构的道路?下面将介绍一些策略,帮你摆脱单体地狱,而无须从头开始重写你的应用程序. 通过开发所谓的绞杀者应用程序(strangler application),可以逐步将单体架构转换为微服务架构.绞杀者应用程序的想法来自绞杀式藤蔓,这些藤蔓在雨林中生长,它们包围绕树木生成,甚至有时会杀死树木.绞杀者应用程序是一个由微服务组

三分钟读懂Oracle数据库容灾架之DataGuard

Oracle数据库目前依然处于商用数据库的霸主地位. 运行在Oracle数据库上的核心业务及核心数据的安全性尤为重要. 目前市场上针对Oracle数据库常见的容灾产品大致可以分为两大类. Oracle 公司自己的容灾产品 非Oracle公司的容灾产品 Oracle公司目前的容灾产品有我们常见的DataGuard和属于中间件部门的Oracle GoldenGate(以下简称OGG)产品.非Oracle公司的有DSG迪思杰 及DDS九桥,这两种产品和OGG在实现原理上大致相同. Oracle Gol

hbase 学习(十六)系统架构图

转自:http://www.cnblogs.com/cenyuhai/p/3708135.html HBase 系统架构图 组成部件说明  Client:  使用HBase RPC机制与HMaster和HRegionServer进行通信  Client与HMaster进行通信进行管理类操作  Client与HRegionServer进行数据读写类操作  Zookeeper:  Zookeeper Quorum存储-ROOT-表地址.HMaster地址  HRegionServer把自己以Ephe

Android系统架构图

认识Android系统架构图 一.Linux Kernel层(Android系统底层一些硬件驱动) Display Driver: 显示驱动 Camera Driver: 相机驱动 Bluetooth Driver :    蓝牙驱动 Flash Mem Driver:  闪存驱动 Binder(IPC) Driver: 进程(通信)驱动 USB Driver : USB驱动 Keypad Driver:   键盘驱动 WiFi Driver:    wifi驱动 Aduio Driver:  

Android 系统架构图

Android软件栈的顶层是应用,中间是中间件(由应用框架.库和Android运行时组成),底层则是带有各种驱动的Linux内核. 如下图示: 对应这三层有相关的嵌入式水平,如下:

选课系统架构图

原文地址:https://www.cnblogs.com/caoyu080202201/p/12696901.html