内容简介:我们以淘宝架构为例,了解下大型电商项目的服务端架构是怎样的,如图1所示:上面是一些安全体系系统,如数据安全体系、应用安全体系、前端安全体系等。中间是业务运营服务系统,如会员服务、商品服务、店铺服务、交易服务等。
我们以淘宝架构为例,了解下大型电商项目的服务端架构是怎样的,如图1所示:
上面是一些安全体系系统,如数据安全体系、应用安全体系、前端安全体系等。
中间是业务运营服务系统,如会员服务、商品服务、店铺服务、交易服务等。
还有共享业务,如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
最下面是中间件服务,如MQS即队列服务,OCS即缓存服务等。
图片来自包图网
图中也有一些看不到,例如高可用的体现、实现双机房容灾和异地机房单元化部署,为淘宝业务提供稳定、高效和易于维护的基础架构支撑。
图1
这是一个含金量非常高的架构,也是一个非常复杂而庞大的架构。当然这个架构不是一天两天演进而成,也不是一上来就设计并开发成这么高大上的。
这边我想说的是,小型公司要怎么做架构呢?对很多创业公司而言,很难在初期就预估到流量十倍、百倍以及千倍以后的网站架构会是一个怎样的状况。同时,如果系统初期就设计一个千万级并发的流量架构,也很难有公司可以支撑这个成本。
因此,一个大型服务系统都是从一步一步走过来的,在每个阶段,找到对应该阶段网站架构所面临的问题,然后在不断解决这些问题,在这个过程中整个架构会一直演进。
一、单服务器-俗称all in one
从一个小网站说起。一台服务器也就足够了。文件服务器,数据库,还有应用都部署在一台机器,俗称ALL IN ONE。
随着我们用户越来越多,访问越来越大,硬盘、CPU、内存等都开始吃紧,一台服务器已经满足不了。这时看到下一步演进。
二、数据服务与应用服务分离
三、使用缓存
包括本地缓存、远程缓存、远程分布式缓存。
因为 80% 的业务访问都集中在 20% 的数据上,也就是我们经常说的28法则。如果能将这部分数据缓存下来,性能一下子就上来了。而缓存又分为两种:本地缓存和远程缓存缓存,以及远程分布式缓存,我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。
思考的点
- 具有哪种业务特点数据使用缓存?
- 具有哪种业务特点的数据使用本地缓存?
- 具有哪种务特点的数据使用远程缓存?
- 分布式缓存在扩容时会碰到什么问题?如何解决?分布式缓存的算法都有哪几种?各有什么优缺点?
四、使用负载均衡,进行服务器集群
增加了负载均衡、服务器集群之后,我们可以横向扩展服务器,解决了服务器处理能力的瓶颈。
思考的点
- 负载均衡的调度策略都有哪些?
- 各有什么优缺点?
- 各适合什么场景?
打个比方,我们有轮询、权重、地址散列,地址散列又分为原ip地址散列hash、目标ip地址散列hash,最少连接,加权最少连接,还有继续升级的很多种策略......我们都来分析一下。
典型负载均衡策略分析
- 轮询:优点-实现简单,缺点-不考虑每台服务器处理能力
- 权重:优点-考虑了服务器处理能力的不同
- 地址散列:优点-能实现同一个用户访问同一个服务器
- 最少连接:优点-使集群中各个服务器负载更加均匀
- 加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。
继续引出问题的场景
Session管理-Session Sticky粘滞会话
打个比方,如果我们每次吃饭都要保证用的是自己的碗筷,只要我们在一家饭店里存着自己的碗筷,并且每次去这家饭店吃饭就好了。
对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。
解决了我们session共享的问题,但是它有什么缺点呢?
一台服务器运行的服务挂掉,或者重启,上面的 session 都没了。
负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊。
Session管理-Session 复制
就像我们在所有的饭店里都存一份自己的碗筷。这样随意去哪一家饭店吃饭都OK,不适合做大规模集群,适合机器不多的情况。
解决了我们session共享的问题,但是它有什么缺点呢?
应用服务器间带宽问题,因为需要不断同步session数据。
大量用户在线时,服务器占用内存过多。
Session管理-基于Cookie
打个比方,就是我们每次去饭店吃饭,都带着自己的碗筷去。
解决了我们session共享的问题,但是它有什么缺点呢?
cookie 的长度限制。
cookie存于浏览器,安全性是一个问题。
Session管理-Session 服务器
打个比方,就是我们的碗筷都存在了一个庞大的橱柜里,我们去任何一家饭店吃饭,都可以从橱柜中拿到属于我们自己的碗筷。
解决了我们session共享的问题,这种方案需要思考哪些问题呢?
保证 session 服务器的可用性,session服务器单点如何解决?
我们在写应用时需要做调整存储session的业务逻辑。
打个比方,为了提高session server的可用性,我们可以继续给session server做集群。
五、中间总结
所以网站架构在遇到某些指标瓶颈、演进的过程中,都有哪些解决方案?它们都有什么优缺点?业务功能上如何取舍?如何做出选择?这个过程才是最重要的。
在解决了横向扩展应用服务器之后,我们继续回到目前的架构图:
数据库的读及写操作都还需要经过数据库。当用户量达到一定量,数据库将会成为瓶颈。又该如何解决呢?
六、数据库读写分离
思考的点
- 如何支持多数据源?
- 如何封装对业务没有侵入?
- 如何使用目前业务的ORM框架完成主从读写分离?是否需要更4. 换ORM模型?ORM模型之间各有什么优缺点?
- 如何取舍?
数据库读写分离会遇到如下问题:
- 在master和slave复制的时候,考虑延时问题、数据库的支持、复制条件的支持。
- 当为了提高可用性,将数据库分机房后,跨机房传输同步数据,这个更是问题。
- 应用对于数据源的路由问题。
七、使用反向代理和CDN加速网站响应
八、分布式文件系统
思考的点
- 分布式文件系统如何不影响已部署在线上的业务访问?不能让某个图片突然访问不到呀。
- 是否需要业务部门清洗数据?
- 是否需要重新做域名解析?
这时数据库又出现了瓶颈。
九、数据垂直拆分
数据库专库专用,如图Products、Users、Deal库。解决写数据时并发量大的问题。
思考的点
- 跨业务的事务如何解决?使用分布式事务、去掉事务或不追求强事务。
- 应用的配置项多了。
- 如何跨库进行数据的join操作?
这个时候,某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈。
十、数据水平拆分
如图,我们把User拆成了User1和User2,将同一个表的数据拆分到两个数据库中,解决了单数据库的瓶颈。
思考的点
- 水平拆分的策略都有哪些?各有什么优缺点?
- 水平拆分的时候如何清洗数据?
- SQL的路由问题,需要知道某个User在哪个数据库上。
- 主键的策略会有不同。
假设系统中需要查询2017年4月份已经下单过的用户名的明细,而这些用户分布在user1和user2上,我们后台运营系统在展示时如何分页?
这个时候,公司对外部做了流量导入,我们应用中的搜索量飙升,继续演进。
十一、拆分搜索引擎
总结
本文只是一个举例演示,各个服务的技术架构需要根据自己业务特点进行优化和演进,所以大家的过程也不完全相同。
最后的这个示例也不是完美的,例如负载均衡还是一个单点,也需要集群,我们这个架构也只是冰山一角。因为在架构演进的过程中,还要考虑系统的安全性、数据分析、监控、反作弊等,同时往后继续发展,也要考虑到SOA架构、服务化、消息队列、任务调度、多机房等。
从以上对架构演进的讲解,也可以看出来,所有大型项目的架构和代码,都是一步一步根据实际的业务场景和发展情况发展演变而来,在不同的阶段,会使用的不同的技术,不同的架构来解决实际的问题,所以说,高大上的项目技术架构和开发设计实现不是一蹴而就的。
正是所谓的万丈高楼平地起。在架构演进的过程中,小到核心模块代码,大到核心架构,都会不断演进的,这个过程值得我们去深入学习和思考。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- FreeSky主题访问量统计修复
- 一年,近8w访问量,码云 Star 4k+
- 万亿级日访问量下,Redis 在微博的 9 年优化历程
- 万亿级日访问量下的京东HBase平台异地多活实践
- Go实现网站访问量控制(滑动窗口算法,类似利用Redis List数据结构属性)
- 『互联网架构』软件架构-分布式架构(14)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Python for Data Analysis
Wes McKinney / O'Reilly Media / 2012-11-1 / USD 39.99
Finding great data analysts is difficult. Despite the explosive growth of data in industries ranging from manufacturing and retail to high technology, finance, and healthcare, learning and accessing d......一起来看看 《Python for Data Analysis》 这本书的介绍吧!