您的位置:首页 > 运维架构 > 网站架构

慕课网电商项目笔记02——大型java项目架构演进解析

2020-01-31 19:38 821 查看

淘宝架构体系

小型项目:在同一服务器上搭建文件+数据库

分离业务:三台服务器搭载三种服务


使用分布式缓存:2/8原则 :80%的业务访问都集中在20%数据上
缓存分为两种:Application Server的本地缓存和远程缓存
远程缓存分为远程的单机缓存和分布式缓存(图中则为分布式缓存)

则需要思考:
具有哪种业务特点的数据使用缓存?
具有哪种业务特点的数据使用本地缓存?
具有哪种业务特点的数据使用远程缓存?
分布式缓存在扩容时会碰到什么问题?该如何解决?
分布式缓存具有什么缺点?

负载均衡调度器,服务器集群

使用轮询或者最小连接的负载均衡策略,这叫导致了我们第一次访问A服务器将Session信息保存到了A服务器,第二次访问B服务器时,访问不到存储在A服务器上的Session信息,那么我们就要考虑Session管理,使用Session sticky粘滞会话解决这个问题

Session管理四种方案

Session sticky

缺点:Application1重启,Session全部丢失。
负载均衡成为一个有状态的机器,要实现容灾会有麻烦

Session Copy

缺点:占用内存过多,不适合做大规模集群

Cookie方案

带着携带cookie信息的session访问应用服务器
缺点:
cookie的长度有限制性的
cookie保存在浏览器中安全性有问题

Session服务器

缺点:
Session Server是单点的,如何解决单点?如何保证它的可用性?
解决方案就是将它也做成一个集群,这种情况适用于session数量,web服务器大的情况。
当改成这种架构后,我们在写应用时也要调整存储Session的业务逻辑。

面试遇到一些问题
为什么做单点登录?
都有哪些解决方案?
为什么要选择这种解决方案?
各有什么优缺点?
在选择这种解决方案是如何平衡和取舍得?

主、从数据库

将读操作全部引入R——Slave数据库中
将写操作全部引入W——Master数据库中

同时,应用要接入多数据源,并且通过统一的数据访问模型进行访问。
因为数据库实现了读写分离,应用程序也应做出相应改变,
如图Application Server中实现了数据访问模块,让写代码的人不知道读写分离的存在,这样数据库的读写就对业务代码没有了侵入。
这里就引出了一个代码层次的演变,
如何支持多数据源,
如何封装对业务没有侵入,
如何使用目前业务的ORM框架完成对主从数据库的读写分离,
是否需要更换ORM。
又各有什么优缺点
如何取舍
当我们访问量过大的时候,数据库的IO非常大,我们又会遇到以下问题
我们主库和从库在复制时候有没有延时
如果我们将主库和从库在分机房部署的话 ,跨机房同步数据问题
应用对数据源的路由问题

CDN和反向代理服务器

使用CDN可以很好地解决不同的地区访问速度问题,
反向代理则在机房中可以缓存用户资源
文件则改为了分布式文件集群
在使用分布式文件系统时,我们又应考虑如下几个问题
如何不影响已部署在线上的业务访问
是否需要业务部门帮忙清洗数据
是否需要备份服务器
是否需要重新做域名解析
将数据库业务拆分
将数据业务拆分分成不同的库后又会带来哪些新问题?
跨业务事务,跨库事务,如何解决?
分布式事务,或者去掉事务,不追求强事务
水平拆分:有哪些水平拆分方式
SQL路由
分页

使用NOSQL Server

过程中…

安全性 、数据分析、监控、反作弊… … …

继续发展…

SOA架构、服务化、消息队列、任务调度、多机房… … …

高大上项目技术架构和开发设计实现不是一蹴而就的

  • 点赞
  • 收藏
  • 分享
  • 文章举报
JavaKobeBryant 发布了15 篇原创文章 · 获赞 11 · 访问量 380 私信 关注
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: