第三课(一)|学习笔记

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 快速学习第三课(一)

开发者学堂课程【高校精品课-西安交通大学-数据库理论与技术:第三课】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/12/detail/25


第三课(一)

 

内容介绍:

一、 背景

二、 阶段一:单机阶段

三、 阶段二:应用服务器和数据库服务器分离

四、 阶段三:应用服务器集群

五、 阶段四:数据库压力变大,数据库读写分离

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

七、 阶段六:引入缓存机制缓解数据库的压力

八、 阶段七:数据库垂直/水平拆分

九、 阶段八:应用的拆分

十、 分布式系统的意义

十一、分布式系统的优势

十二、主流的分布式架构:SOA 架构

十三、主流的分布式架构:ESB(企业服务总线)

十四、SOA 所要解决的核心问题

十五、主流的分布式架构:微服务(MicroServives)架构

十六、微服务的特征

十七、SOA 和微服务架构的差别

十八、分布式架构的理论基础


一、 背景

随着社会发展,技术进步,早期的基础架构都属于集中式,既主机架构或者大型机架构,是高度集中的。

有几个问题:1、成本非常高,既价格很高,2、维护困难。

当年 APN 的主机,在80年时,主机4381,一个电缆5000块。主机时价格很高,IBN 与大学合作项目,给国内几所大学送几所大迎机,大迎机标称六千万人民币。主机可25万人同时连接,而且很稳定,可十年从来不档期,一直运行,一秒钟都不档期。银行后台使用这种系统,系统非常稳固,价格非常高。维护变得不在主流,取而代之是分布架构,现在的主机为分布式架构,从集中式到分布式架构,经历几个阶段,了解各个阶段的架构,才能理解分布式架构的一些特点。

大型主机,从一开始,成熟的大型网站并非是一开始就设计非常好,也并不是一开始就具备高性能,高并发,高可用,高安全性等的特性,实际是发展当中逐步演化的。假设网站一开始非常简单,非常简陋,逐步发展,发展就是随着用户数量增加,业务数量增加,功能扩展,架构不断完善,不断发展。

针对不同特征的系统,各系统的侧重点不同,比如:

淘宝这类电商网站,京东,淘宝,天猫,拼多多。解决问题,首先是商品的搜索,商品的陈列。人家的目的一般是购物,买东西。要搜索很方便,假设要买的东西很容易找到,分享找不到就不买;买了后下单领东西,另外还有支付的问题。淘宝能成功,解决支付问题既使用支付宝。买家卖家一开始支付就是大问题,在网上买东西,把钱先付,买家不放心,担心给了钱不给东西;卖家如果没有收到钱,拿东西给客户担心不给钱,卖家也不放心。钱就先收在支付宝,买家卖家都放心,解决了信任问题。

腾讯属于社交类网站,微信这类。解决数亿级别用户的实时消息传递。因在微信朋友群里发东西,发各种信息,该量非常大,每个人的量不大,但中国几亿人十几亿人,几亿或者十几亿网民,这数量实时传递。

百度类是搜索引擎,海量数据的搜索既解决问题。

因此每一个业务都有不同的系统架构。这就是一个大背景。

下面给出一个网站架构的大概演变过程。

假设需要搭建一个简单的电商系统,从系统中看系统的架构演变过程。

接下来的演示模型,系统主要关注数据量、访问量的提升。网站结构的变化,而不关注具体业务的功能点。网站有业务功能点不关注,关注数据量、业务量上来后,架构怎么适应。

这个过程是为了让大家了解网站演讲过程中的一些问题和应对策略。

假定系统网站具备一下功能:

1、 用户模块:用户的注册,登录和用户的管理。

2、 商品模块:商品的展示。

3、 交易模块:创建交易和支付。

既三个主要功能模块。

 

二、阶段一:单机阶段

最早,最简单阶段:单机阶段。

image.png

单机阶段:网站的初期,互联网发展早期,很简陋,只有一台机器,数据库、应用、所有的东西都放在这台机器上。既像刚创业,一两个刚毕业大学生,自己弄机器,建网站,开始做生意,创业。

特点:单台服务器上运行所有的程序、软件,所有的软件都部署在一台机上,就完成一个简单系统的搭建,这个阶段追求的是效率,不快。因这个最简单,弄一台机器,电脑城里传一个或者买一个品牌机,然后安装软件,系统就建立起来。这是最简单的。

 

三、阶段二:应用服务器和数据库服务器分离

业务量一上来,机器就出现故障。因数据库,程序都在上面,一台机器根本运行不了。网站上线,访问量上升,服务器负载不断提升,需要在服务器还没有超载时做好规划,提升网站的负载能力。

假若此时没办法在代码层面进行优化提高,那么在单台机器的性能遇到瓶颈的时候,增加机器是一个比较简单的方式。因为这时是提升两种,一种机器本身的升级,既原来买的机器不够,换台更大更贵的机器,用内存更多,硬盘更多。但这种总有天花板,体积工号都会限制,必须横向,一台机器不够,就两台。增加机器是一个比较简单好用的方式,投入产出比比较高。

这个阶段增加机器的主要目的是将web服务器和数据库服务器拆分开来,这样做的话不仅提高了单机的负载能力,也提高了整个系统的容灾能力。好处对容灾能力提升,单台机器有个问题,机器一旦坏掉或者出故障,就什么都没有。

架构图如下:

image.png

模块,商品模块,交易模块,都放于外部应用容器中。底下是数据库。这是已经将数据库与应用服务器拆分开,既应用服务器与数据服务器分离,互不影响。减少了网站宕机的风险,此阶段开始关注到应用服务器的管理。

 

四、阶段三:应用服务器集群

这个阶段,访问量还在不断增加,假设创业做得好,业务还在不断增加,这种互联网增加的规律与传统企业不一样,传统企业也有可能爆发性,但互联网的爆发性速度更快,因在于其的时空界限消失。假设开一个网站,流量好,吸引人,就很受欢迎,访问量不断增加,单台服务器无法满足要求。

假定数据服务器还没有遇到性能问题,那可以通过增加应用服务器来将应用服务器集群化,这样就将用户请求分流到各个服务器中,达到继续提升负载能力的目的。

此时应用服务器间是互相独立的,之间没有直接交互,而是依赖数据服务器提供服务,相当于将其想象成为一个大厅,原本一个大厅,现作出两个大厅,当用户进入,也进入不同大厅,但方法可以有很多种,按区域划分,也可能按专业,假设电商当中,这类商品位于这区域,另一商品位于另一区域,有许多种分类方法。将负载分散开,但数据库后台还是一个。 

这阶段的问题:

l 用户请求交由谁转发到具体的服务器上既负载均衡的问题。(谁来服务负载均衡)

l 用户每次访问到的服务器不一样,这时 session,中间的问题如何共享。

此时架构又要变化:

image.png

进入时,先有负载均衡器或者负载服务器,相当于接待站,根据情况分配。综合考虑,负载轻重,一般原则安排到负载轻的地方。

l 负载均衡又分为软负载和硬负载。

l 软负载,,可以选择反向代理 Nginx、Apache 服务器等

l 硬负载可以选择 F5等。

l Session 共享问题可以通过配置 tomcat 既外部容器的 session 共享解决。

 

五、阶段四:数据库压力变大,数据库读写分离

数据库压力越来越大,前端东西越来越多。后端数据库实现读写分离,既将读写分开。

l 架构演变到上面阶段,并非终点。

l 通过上面的设计,应用层的性能被拉上来了,但数据库的负载也逐步增大,那么,如何去提高数据库层面的负载或者性能。

l 有了前面的设计思路以后,自然会想到通过增加服务器来提高性能。

l 数据库也是集群,假设将数据库一分为二,然后对于数据库的请求,分别放在两台数据库服务器上,那必定会造成数据库数据不统一的问题。

以上为分布式数据库,有些分布式数据库是因为一台数据库满足不了要求,就使用两台,以此类推。多台后,数据分开后带来的最大问题:1、数据的一致性问题。因为重复存,假设数据在每个服务器上都存有,访问方便,但有个问题。更新,假设有三台服务器,三个副本,更新时三台都要更新,有的更新,有的没有,就会使访问不一致。会使内容不一致,就会产生差异,从而产生问题。既数据库数据的不统一,不一致。

l 所以首先考虑读写分离。数据不一致,主要是由写操作引起。因

写操作导致数据变化,多个副本时,所以该架构叫做读写分离。 

读写分离的基本思路:

有的数据库做写,或者一部分数据只有一个一般一写多读。该数据有一个主服务器,只能由主服务写,其他只能去读。另一种架构:一台服务器管理数据更新或者修改的问题,读放置其他服务器,但有很多应用只是读。假设商品的查,一般只读不改。商品的商家可能修改,或者有些应用在后台修改,假设商品新上架,或者商品下架,造成商品目录修改。作为一般的用户只是观看,读的一般比改得多,往往就会一写多读。一台服务器负责写,可能带十台更多的。这种架构在云原生中就是一种基本架构,后面会有讲解。读写分离架构设计的变化带来如下问题:

主从数据库之间的数据需要同步。mysql 有主从结构,有 master-slave 就一个主带若干个从,主负责写,从负责读。

应用根据业务需求进行数据源的选择。应用可能选择不同数据源,这时可采用第三方数据库中间件来解决这个问题。

 

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

image.png

l 数据库往往有些查找是模糊查找,特别像商品搜索,买东西的人并不是精确知道自己要什么,只知道大概。所以进行搜索时,在数据库中越模糊的搜索,造成的查询很难提升。因查询当中条件写得不好,条件模糊,很难精准定位一个数据。只能查找到一推东西。这就有问题。这时在电商网站搜索是核心功能,即使是做读写分离,这个问题还是无法解决。

l 因此一般引入搜索引擎,搜索引擎能按照内容进行索引,既跟搜索网站一样,只不过现位于电商网站。搜索引擎也有垂直搜索引擎,专门帮助搜索商品,既创业的。大的搜索引擎,综合的搜索引擎被市场占完,国内百度,国外谷歌。搜索当中有细分的领域,当然也有针对不同需求,有的专门找工作,找科研成果,找各种各样的需求,就会进行搜索。这也会带来问题,索引怎么维护,索引的构建,数据同步等,就会带来一系列问题。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
10月前
|
编解码 网络协议
如何轻松地 rip 3D Blu-ray:详细步骤指南
随着3D电影和家庭影院的普及,越来越多的人希望将3D Blu-ray电影转换为数字文件,以便在多种设备上播放。本文介绍了使用DVDFab、MakeMKV+HandBrake和Leawo Blu-ray Ripper等软件轻松rip 3D Blu-ray的方法,帮助用户享受高质量的3D观影体验。这些工具不仅提供了便捷性和高质量的输出,还能节省存储空间。
652 9
基于粒子滤波器的电池剩余使用寿命计算matlab仿真
本研究基于粒子滤波器预测电池剩余使用寿命(RUL),采用MATLAB2022a实现。通过非线性动力学模型模拟电池老化过程,利用粒子滤波器处理非线性和非高斯问题,准确估计电池SOH变化趋势,进而预测RUL。系统仿真结果显示了良好的预测性能。
|
网络协议 数据库连接 Python
python知识点100篇系列(17)-替换requests的python库httpx
【10月更文挑战第4天】Requests 是基于 Python 开发的 HTTP 库,使用简单,功能强大。然而,随着 Python 3.6 的发布,出现了 Requests 的替代品 —— httpx。httpx 继承了 Requests 的所有特性,并增加了对异步请求的支持,支持 HTTP/1.1 和 HTTP/2,能够发送同步和异步请求,适用于 WSGI 和 ASGI 应用。安装使用 httpx 需要 Python 3.6 及以上版本,异步请求则需要 Python 3.8 及以上。httpx 提供了 Client 和 AsyncClient,分别用于优化同步和异步请求的性能。
389 1
python知识点100篇系列(17)-替换requests的python库httpx
|
SQL 关系型数据库 MySQL
【mysql】mysql命令使用大全,你想要的都在这里
【mysql】mysql命令使用大全,你想要的都在这里
546 0
|
网络协议 Linux C++
超级好用的C++实用库之网络
超级好用的C++实用库之网络
158 0
|
数据库连接 程序员 C#
C#(WPF)连接SQLite数据库,利用ViewModel显示数据
对于入门c#(WPF)的初级程序猿
1682 0
C#(WPF)连接SQLite数据库,利用ViewModel显示数据
|
SQL Oracle 关系型数据库
关系型数据库Oracle结束 RMAN 会话:
【7月更文挑战第25天】
383 1
自定义SQL,可以利用MyBatisPlus的Wrapper来构建复杂的Where条件,如何自定义SQL呢?利用MyBatisPlus的Wrapper来构建Wh,在mapper方法参数中用Param注
自定义SQL,可以利用MyBatisPlus的Wrapper来构建复杂的Where条件,如何自定义SQL呢?利用MyBatisPlus的Wrapper来构建Wh,在mapper方法参数中用Param注
|
自然语言处理 JavaScript Java
CodeFuse新开源模型荣登Big Code评测榜首!
使用多任务高效微调框架MFTCoder,以DeepSeek-Coder-33b模型为底座,微调获得的CodeFuse-DeepSeek-33b模型在Big Code Models Leaderboard代码大模型榜单上以43.58% WinRate成为新晋榜首,同时模型在NLP任务上也取得了很好的表现。本文我们将介绍该模型的得来和使用,包括训练数据、训练超参设置、模型评测效果以及如何获取该模型和基于它继续微调。我们已经在HuggingFace和ModelScope开放了模型下载(下载地址在文末),并同步提供了4bit量化版本供大家直接部署到生产环境。
663 0