从0开始 独立完成企业级Java电商网站开发(服务端)--笔记1 架构演进

高大上的淘宝架构
我们以淘宝架构为例,了解下大型的电商项目的服务端的架构是怎样,如图所示
在这里插入图片描述
上面是一些安全体系系统,如数据安全体系、应用安全体系、前端安全体系等。
中间是业务运营服务系统,如会员服务、商品服务、店铺服务、交易服务等。
还有共享业务,如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
最下面呢,是中间件服务,如MQS即队列服务,OCS即缓存服务等。

图中也有一些看不到,例如高可用的一个体现,实现双机房容灾和异地机房单元化部署,为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

这是一个含金量非常高的架构,也是一个非常复杂而庞大的架构。当然这个也不是一天两天演进成这样的,也不是一上来就设计并开发成这样高大上的架构的。

这边就要说一下,小型公司要怎么做呢?对很多创业公司而言,很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时,如果系统初期就设计一个千万级并发的流量架构,很难有公司可以支撑这个成本。

因此,一个大型服务系统都是从小一步一步走过来的,在每个阶段,找到对应该阶段网站架构所面临的问题,然后在不断解决这些问题,在这个过程中整个架构会一直演进。
那我们来一起看一下。

单服务器

在这里插入图片描述
从一个小网站说起。一台服务器也就足够了。文件服务器,数据库,还有应用都部署在一台机器,俗称ALL IN ONE

随着我们用户越来越多,访问越来越大,硬盘,CPU,内存等都开始吃紧。一台服务器已经满足不了。

这个时候看一下下一步演进

数据服务与应用服务分离
file
我们将数据服务和应用服务分离,给应用服务器配置更好的 CPU,内存。而给数据服务器配置更好更大的硬盘。

分离之后提高一定的可用性,例如Files Server挂了,我们还是可以操作应用和数据库等。
随着访问qps越来越高,降低接口访问时间,提高服务性能和并发,成为了我们下一个目标,发现有很多业务数据不需要每次都从数据库获取。

使用缓存
包括本地缓存,远程缓存,远程分布式缓存
file
因为 80% 的业务访问都集中在 20% 的数据上,也就是我们经常说的28法则。如果我们能将这部分数据缓存下来,性能一下子就上来了。而缓存又分为两种:本地缓存和远程缓存缓存,以及远程分布式缓存,我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。

使用负载均衡,进行服务器集群
在这里插入图片描述
增加了负载均衡,服务器集群之后,我们可以横向扩展服务器,解决了服务器处理能力的瓶颈。

典型负载均衡策略分析

轮询:优点:实现简单,缺点:不考虑每台服务器处理能力
权重:优点:考虑了服务器处理能力的不同
地址散列:优点:能实现同一个用户访问同一个服务器
最少连接:优点:使集群中各个服务器负载更加均匀
加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。

继续引出问题的场景

我们的登录的时候登录了A服务器,session信息存储到A服务器上了,假设我们使用的负载均衡策略是ip hash,那么登录信息还可以从A服务器上访问,但是这个有可能造成某些服务器压力过大,某些服务器又没有什么压力,这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈,并且请求不够分散。

这时候我们使用轮询或者最小连接负载均衡策略,就导致了,第一次访问A服务器,第二次可能访问到B服务器,这个时候存储在A服务器上的session信息在B服务器上读取不到。

Session共享解决方案
Session Sticky粘滞会话
我们使用session sticky这种方式来解决这个问题,它的处理规则是对于同一个连接中的数据包,负载均衡会将其进行NAT转换后,转发至后端固定的服务器进行处理
file
打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷,而只要我们在一家饭店里存着我们的碗筷,只要我们每次去这家饭店吃饭就好了。

对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。

缺点

一台服务器运行的服务挂掉,或者重启,上面的 session 都没了
这样导致了负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊

Session 复制
即当browser1经过负载均衡服务器把session存到application1中,会同时把session复制到application2中,所以多台服务器都保存着相同的session信息。
file
就像我们在所有的饭店里都存一份自己的碗筷。我们随意去哪一家饭店吃饭都OK,不适合做大规模集群,适合机器不多的情况。

缺点

应用服务器间带宽问题,因为需要不断同步session数据
当遇到大量用户在线时,服务器占用内存过多

基于Cookie
就是说我们每次都用携带session信息的cookie去访问应用服务器
file

打个比方,就是我们每次去饭店吃饭,都自己带着自己的碗筷。

缺点

cookie 的长度有限制
cookie存于浏览器,安全性是一个问题

Session 服务器
把session做成了一个session服务器,比如可以使用redis实现。这样每个用户访问到应用服务器,其session信息最终都存到session server中,应用服务器也是从session server中去获取session。
在这里插入图片描述
打个比方,就是我们的碗筷都存在了一个庞大的橱柜里,我们去任何一家饭店吃饭,都可以从橱柜中拿到属于我们自己的碗筷。

保证 session 服务器的可用性,session服务器单点如何解决?
我们在写应用时需要做调整存储session的业务逻辑
打个比方,我们为了提高session server的可用性,可以继续给session server做集群

目前架构图
**file**

数据库读写分离
数据库的读及写操作都还需要经过数据库。当用户量达到一定量,数据库将会成为瓶颈,我们继续演进。

file

使用数据库提供的热备功能,将所有的读操作引入slave 服务器,因为数据库的读写分离了,所以,我们的应用程序也得做相应的变化。我们实现一个数据访问模块(图中的data access module)使上层写代码的人不知道读写分离的存在。这样多数据源读写分离就对业务代码没有了侵入。这里就引出了代码层次的演变

数据库读写分离会遇到的问题

在master和slave复制的时候,考虑延时问题、数据库的支持、复制条件的支持。
当为了提高可用性,将数据库分机房后,跨机房传输同步数据,这个更是问题。
以及应用对于数据源的路由问题

使用反向代理和 CDN 加速网站响应
file

使用 CDN 可以很好的解决不同的地区的访问速度问题,反向代理则在服务器机房中缓存用户资源。

分布式文件系统
这个时候我们的文件服务器又出现了瓶颈,我们将文件服务器改成了分布式文件服务器集群。
file

数据库分库分表
这个时候我们的数据库又出现了瓶颈,我们选择专库专用的形式,进行数据的垂直拆分,相关的业务独用自己的一个库,我们解决了写数据并发量大的问题。

随着访问量过大,数据量过大,某个业务的数据库数据量和更新量已经达到了单个数据库的瓶颈了,这个时候就需要进行数据库的水平拆分。

file

如图,我们把User拆成了User1和User2,将同一个表的数据拆分到两个数据库中,解决了单数据库的瓶颈。

拆分搜索引擎
在网站发布并进行了大规模的推广后,导致我们应用服务器的搜索量又飙升

file

使用搜索引擎,解决数据查询问题。部分场景可使用 NoSQL 提高性能,开发数据统一访问模块,解决上层应用开发的数据源问题。如图data access module 可以访问数据库,搜索引擎,NoSQL

总结
这个只是一个举例演示,各个服务的技术架构是需要根据自己业务特点进行优化和演进的,所以大家的过程也不完全相同。

最后的这个也不是完美的,例如负载均衡还是一个单点,也需要集群,我们的这个架构呢也只是冰山一角,沧海一粟。在架构演进的过程中,还要考虑系统的安全性、数据分析、监控、反作弊等等…,同时继续发展呢,SOA架构、服务化、消息队列、任务调度、多机房等等… …

从刚才对架构演进的讲解,也可以看出来,所有大型项目的架构和代码,都是这么一步一步的根据实际的业务场景,和发展情况发展演变而来的,在不同的阶段,会使用的不同的技术,不同的架构来解决实际的问题,所以说,高大上的项目技术架构和开发设计实现不是一蹴而就的。

正是所谓的万丈高楼平地起。在架构演进的过程中,小到核心模块代码,大到核心架构,都会不断演进的,这个过程值得我们去深入学习和思考。一起加油吧~~

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页