AtO9FL

dgn2mz t3v8sJ

E6ZtYU

CAdxPw

sEy3QZ

XxDVGN

rDdya2

hoBA7e

缓存

  1. 本地缓存:与我们的应用程序部署在一起。速度极快,因为与我们的应用在一个地方,不足:缓存的数据量有限,与我们的应用程序争抢内存。
  2. 远程分布式缓存:部署在远程的主机上,远程主机可以做到按需扩展,相较于本地缓存,性能会稍微差一点,因为必须要通过一次网络访问,但是相较于从数据库查取通过空间换得了时间,

常用缓存组件:memcache + redis

oqmx4Q

UYHDKD

缓存

  1. 更强的服务器也是有天花板的,但是使用了集群之后我们可以按需进行扩展,有很强的可扩展能力。
  2. 应用集群之后,我们前面需要一个负载均衡调度服务器,那么负载均衡需要什么能力呢?高性能,高并发,因为所有的请求都会经过负载均衡调度服务器,负载均衡的实现方式(3个方式:软件,硬件,DNS)我们在中间件讲过。

3Sx2Pr

  1. 软件方式中nginx性能优异,如果配置高一点,10w并发没问题,并且消耗资源很少,所以现在中小型用的多。当并发量超过了Nginx处理能力之后,我们可以选用LVS。
  2. 硬件的方式在中小型很少用,在大型用的多,能力优于软件,一个几十万
  3. DNS负载均衡利用的是域名解析的过程,我一个域名对应多个Ip地址,当机器发送域名到域名服务器解析的时候,每次返回一个不同的ip地址实现负载均衡。如果忘记负载均衡记得回顾中间件的视频,并且还有一个直播课里面讲了负载均衡的面试。

此时前台我们的并发就没有问题了,但是经过一段时间的发展,我们的后端又有了压力。
8F5p7m

我们采用主从复制,将读写分开(因为合在一起压力比较大),所以采用数据库集群的方式,利用主流数据库都有主从热备这么一个功能来做读写分离,利用的是主从复制,一个主库,一个从库。

注意:读写分离之后,我们自然就需要有一个数据访问模块,因为如果没有数据访问模块,我们的应用程序面临的是后端有多个数据库。

30iKMP

fkVPaM

g29BeO

CDN与反向代理

  1. CDN:内容分发网络,必须要部署在电信运营商的数据中心里面,原理:比如我们买个东西,只在杭州有,但是我是乌鲁木齐的,找个代理商将商品寄存到它那里,然后再来访问的时候就不需要到杭州了,直接在乌鲁木齐拿货走了。适用于静态资源,将我们的静态资源提前缓存到电信运营商的数据中心里面去。当我们的用户通过电信网络发出请求的时候,请求一定走到电信的数据中心里面,然后进行路由分发,一看请求地址对应的资源在我的cdn服务器资源商,于是就直接返回了。
  2. 反向代理服务器:也是将静态资源缓存到反向代理服务器上,与CDN的区别:地点不一样,反向代理服务器是部署在数据中心的最外层的,还是在数据中心里面,但是是整个应用系统的最外层,
  3. 反向代理与CDN原理都是缓存,提前将我们需要的资源缓存上去。避免请求跑到应用服务器上。

info,

好处:Bnof40

继续发展:SXLTTO

DnmWSk

原来的单文件服务器变成了分布式文件系统,是一个集群,可以按需进行扩展,原来的数据库读写分离之后,已经是一个集群了,但是读写分离之后,每一个数据库服务器存的都是相同的拷贝数据,那么数据量一大存不下来,所以现在变成了分库分表,也就是分布式系统。

疑问:分布式文件系统怎么做?分库分表怎么做?

hYNIqX

分布式文件系统不可以用hdfs存储,因为hdfs是用来存储大数据(大文件,将每个大文件分成数据块,之后小文件不够数据块大小依然是按照一个数据块的大小来存储)的。

数据访问模块就不可以使用mybatis插件了,因为涉及到了分库分表,处理变得复杂,所以使用开源的数据库中间件。

8bwMQW

  1. 比如我们的电商系统网易严选,电子商务系统里面,商品是一张表的存储,商品各行各业字段是不一样的,因此这样一个存储要定义很多字段,每一个分类都并不是很多字段都需要。
  2. 找一个商品的时候我们做搜索使用模糊查询,我们知道模糊查询对于索引是没有效果的,此时搜索性能很差,我们就需要用NoSQL(分布式)和搜索引擎(因为我们数据量很大)

EyapT8

NoSQL 和 搜索引擎服务器就是用来解决存储的多样化,非模式的各种方式,还有搜索引擎。

RJ9SD1

搜索引擎

  1. Lucence:apache基金会支持的顶级项目,开源搜索引擎开发工具包,如果系统里面具有搜索的需要就可以将其集成到系统里面。
  2. solr是lucence下面的子项目,是一个已经开发好的子平台,拿过来之后直接部署就可以使用,功能提供非常多,比如高亮等搜索引擎中的基本功能,
  3. es也是基于lucence开发的,直接拿过来就可以使用的,

3v64wW

发展过来我们就是一个工程,当我们做的事情越来越多的时候就会越来越庞大,但是我们希望加入更多的业务,比如3天一次版,5天一次版

ZfJ6Nf

如上图所示我们对应用进行了拆分,拆分出多个应用

cugLB4

引用消息中间件做解耦,以及应用之间的通信服务

xZvhMB 还有RocketMQ

2NzJC9

将相同的大家都用到的模块做成服务,大家不需要再去拥有它相关的模块了,只要调用对应的服务就可以了,

我们将服务做成分布式的,可以用该服务来连接各个系统与各个数据库。
此时我们引入了服务,就要引入配置中心,那么如何做服务化,如何做配置中心呢?

ofsloh

微服务:

图上的齿轮代表是一个服务提供者,或者调用者

  1. SOA:SOA里面有一个很重要的概念就是ESB,企业服务总线,我们的服务都是连到ESB里面的,传统的服务就是采用的这种,缺点就是ESB这个中心点容易出现瓶颈,因为所有的服务都是通过它来传递的。
  2. 微服务:微服务里面没有总线(中心点)的概念,谁调用谁就连接谁,是彼此之间可以互联的,我们的服务也是可以做出负载均衡的。

同样还有一个问题:我们用了微服务之后,服务之间互相调用,那么涉及到一个服务治理的问题,比如启动A服务依赖于B服务,并且有一些服务应用一段时间之后发现不需要这么多资源,那么如何进行治理,这就涉及到微服务治理的过程。

tVKRsU

h9lV57

ArRFYV

注意:此时引入的3个系统不直接与我们的应用分布式系统关联了

SHrWOg

按照这个路线不断积累,各个击破,就可以成为技术大牛

qt13zc

架构设计思想总结:

  1. 分而治之:我们前端压力太大,数据库压力太大,缓存存储不下来,文件存储不下来,高并发,海量数据存储,都可以通过分布式系统来进行解决,
  2. 随网站所需灵活应对
  3. 业务发展驱动技术发展,技术发展反哺业务
  4. 软件系统的价值在于它能为用户提供什么价值,在于网站能做什么,而不在于它是怎么做的。主要是为了提供用户给价值的,而不是高大上的

upRDJe

大公司的设计方案并不一定适用于你的场景。并且有一些问题可以通过业务手段来解决,一定要加强业务理解,并不一定需要通过技术来解决。比如12306抢票我们可以通过分时间卖票来解决。

Osl2lI

评论