电商平台分布式架构设计_第1页
电商平台分布式架构设计_第2页
电商平台分布式架构设计_第3页
电商平台分布式架构设计_第4页
电商平台分布式架构设计_第5页
已阅读5页,还剩12页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、 电商平台分布式架构设计什么是软件架构?不同人的答案会有所不同,而我认为一个好的软件架构除了要具备业务功能外,还应该具备一定的高性能、高可用、高伸缩性及可拓展等非功能需求。而软件架构是由业务架构和技术架构两部分组成,因为有了业务结构才会催生出软件架构,进而来满足业务上的需求,所以,在做软件架构设计时,需要分为业务架构设计和技术软件架构设计,二者不可分离哦!那么,接下来就以本人实际工作中的电商平台为例,进行说明电商平台架构设计,因为不同行业产品系统不同业务不同,而催生的系统软件的实现要求及架构设计就不同了!l 架构设计的必要l 电商平台的需求l 平台的业务架构l 平台的技术架构l 平台架构的总结

2、一、架构设计的必要架构师,我想很多人都知道,其实该职位头衔在最早的IT领域是没有的,它是近些年来由互联网的发展所引发的需求,因为现阶段的数据量及高并发的活跃好动,引起了不少传统的技术人员的力不从心,企业愈发关注到了系统架构的重要性,所以不同行业开始招募架构技术人员,架构师就诞生了。1、架构设计的条件我个人不建议具备下面条件的人员急着做架构,其实架构师的头衔并没有想象的那么神秘,到底是什么节点的同学:A、对架构不感兴趣,但又迫于需求;B、入IT行业,年限小于4年的;C、主观能动性弱,又安于现状的;注意,上面只是个人的想法,不具有代表性,只要你能够循序渐进,秒杀上面几条不满只是时间的问题。2、架构

3、设计的优势A、更好的梳理业务的结构体系;B、更好的拓展、维护及性能优化;C、更好的适应企业业务灵活的推进;D、更好的适应大数据的冲洗和应对;E、更好的稳定性、低成本及快速迭代;3、架构设计的注意架构设计需要注意的地方,不是怎么把架构搭建起来,而是必须根据业务需求,严格分析,实现该需求需要什么技术会更好及更长远发展的考虑;另外,构建好的架构虽然可以运行,但是性能需要跟起来,否则架构设计会适得其反,增加不必要的工作量,那么下面就详细介绍下架构设计的策略。二、电商平台的需求1、客户需求A、在线购物、在线支付或货到付款;B、购买商品后,客户可以与客服沟通;C、购买商品过程,物流的管理及跟踪;D、收取到

4、商品后,商品、物流评价打分;客户的需求为最高,也代表了企业的核心需求,当然,企业需求还包括其它很多非功能性需求,具体请查看需求梳理部分。2、需求梳理客户需求功能需求非功能需求在线购买商品购物车、结算及会员管理用户体验(性能、可用性)在线与客服沟通在线客服功能即时通信能力在线支付或货到付款多种支付方式,含在线支付或货到付款安全、加密、多种支付方式灵活切换在线商品、物流评论打分商品、物流评价打分物流体系对接上面只是对电商平台需求的简单列举,还有很多需求未列出,这里只是为了分析和设计电商平台架构做准备,具体的其它需求,可以参看京东、淘宝等商城。三、平台的业务架构根据业务的需求进行子系统模块划分,可以

5、划分为商品子系统、购物子系统、支付子系统、物流子系统、客服子系统、评论子系统;而非核心需求可拆分出客服子系统、评论子系统及接口子系统。另外,根据各个子系统的核心等级,可拆分出核心子系统和非核心子系统,前者包括商品子系统、购物子系统、支付子系统及物流子系统;后者,则包括评论子系统、客服子系统及接口子系统。需要注意的是一般大型电商平台的物流系统是单独分离出来的系统(入库、出库、库存管理、配送管理及货品管理),而这里划分为子系统的主要目的是为演示核心架构,本架构中物流子系统一般作为对接和管理独立子系统的对接模块哦。1、业务拆分目的A、为了解决各个模块子系统间的耦合、维护及拓展性;B、方便单独部署子系

6、统,避免集中部署导致一个出问题,全部不能用;C、分配专门的团队,负责具体的子系统,最大化工作效率安排;D、应对大数据,高压力时,保护核心子系统正常使用;2、业务的架构图在上面的业务架构图中,将核心和非核心业务进行拆分,同时每个系统都要独立部署实现,做到大数据量压下,各个系统独立运作,提高可用性,必要时可以暂停掉非核心系统的资源开销,保证核心业务正常为用户服务。四、平台的技术架构在上面业务架构图基础上,我们需要一个技术架构的演变过程,一切只为满足用户的体验和支撑为前提,所以技术架构的搭建不是一蹴而就的,而是随着业务的不断衍变,系统的架构会逐渐完善更新,以实现应对业务数据量的冲击。1、基本的架构设

7、计记得很早的时候,很多中小企业所采用的架构设计十分简单,基本使用一台服务器来满足一切需求部署,比如:一台服务器同时用作应用部署、数据库存储以及图片存储等,不料的是待用户数据达到50万以上,系统出现很多性能问题,尽管对数据库和程序做个各种性能优化,结果仍无明显改善,架构如下:后来,IT程序猿发现图片的读写严重影响了系统性能,并将图片单独存放在独立服务器中,并且在架构中引入了Cache中间件,比如:Memcache,这种做法是可取的,而且比原来性能提高了1-2个性能级别,架构设计如下:2、初级的架构设计前几年,一般的电商网站的做法是选用三台服务器,一台部署应用,一台部署数据库,一台部署NFS文件系

8、统,做到将各个规模庞大并耗用性能的部分剥离到不同服务器设备,再配备必要的缓存中间件,基本可以满足近1000万的数据量,具体的架构图如下:但是,目前主流使用的网站架构已经不同,大多采用集群的方式来实现负载均衡和高可用性,架构可以是下面的样子:注意:如果涉及到多台网站服务器的话,就会存在Session如何同步的问题,一般也是最为常用的做法,就是使用Cache中间件来存储和管理Session信息。3、优化的架构设计这里为解决高并发,高可用的大型电商网站的架构设计方案,主要采用了分布式、集群、负载均衡、反向代理、消息队列及多级缓存技术。该架构设计方案,是现今比较流程的大型电商网站采用的架构模式,比如:

9、淘宝、京东等,也许会有细微不同的地方,但大同小异哦!具体的架构图方案如下:3.1、应用集群部署3.2、分布式分布式,即为借助互联网环境连接不同服务器,并各个连接的服务器之间通信交互,提供服务异步调用和返回的通信机制。在这里,主要就是实现商品评论、购物客服、支付接口及物流打分系统各自所在服务器间的通信化,我们可以通过RPC协议直接在他们之间交互通信即可,而上面优化的架构即为分布式架构。3.3、集群集群,分为服务器集群、数据库集群及缓存中间件集群等,但这里主要指的是数据库的集群设计。数据库集群,可以实现主备数据库,做到读写分离以及高可用的实现。大型网站需要存储大规模的数据量,需要实现高可用、高并发

10、、高性能的系统设计,一般采用冗余的方式进行系统设计,具体如下架构:冗余方式设计数据库集群,最为常用的方式为:读写分离和分库分表了。主数据库服务器只负责写入数据,而备用服务器数据库只负责读取数据,可以做到降低数据库的IO压力;另外,如果业务系统比较庞大,可以进一步根据业务的关系度及增长频率分库,若库中的但表数据量比较大,可进一步分表,具体的分库分表可查看我的博客文章数据库的分库分表。3.4、消息队列消息队列,是分布式系统的常用组合,其可以解决子系统或模块间的异步通信,实现高可用,高性能的通信系统,比如:可以用在购物和配送环节,如下:A、用户下单后,写入消息到队列,并立即返回结果给客户端;B、库存

11、子系统,读取消息队列,完成消减库存;C、配送子系统,读取消息队列,并进行配送货品;目前常使用的MQ技术有:Rabbit MQ、Active MQ、Zero MQ及MS MQ,需要根据具体的使用场景进行选择。具体的架构如下:3.5、缓存策略缓存,是一种缓解系统压力的存储技术,主要使用在缓存数据库IO压力而设计。按照位置的不同,可以分为本地缓存和分布式缓存两种,本篇架构采用两级缓存,一级缓存为本地缓存,二级缓存为分布式缓存。而一级缓存一般用来缓存基本不变或规律变化的数据,二级缓存用来缓存所有需要的数据信息,应用程序首先访问一级缓存;如果一级缓存没有需要的信息,那么取访问分布式缓存,如果分布式缓存也没找到需要的信息,最后去访问数据库获得数据。另外,根据业务需要,缓存分为自动过期和触发过期,具体的架构图如下:3.6、服务抽象化抽象化概念,可以很好的实现低耦合,高拓展作用,我们可以将各个子系统公

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论