`
stonebaba
  • 浏览: 3303 次
  • 性别: Icon_minigender_1
  • 来自: 北京
最近访客 更多访客>>
社区版块
存档分类
最新评论

试读《大型网站系统与Java中间件实践》的感想

 
阅读更多

       很高兴又碰到了图书试读活动,还好这次活动我还能赶在最后一天参加,哈哈,赢取获奖机会应该是很能引起激情的一方面因素,更重要的是能通过阅读这样的书籍来总结自己的工作,开拓还未知晓的知识和技能。

       以前我主要从事传统行业的软件开发工作,近2年有机会接触到准电商网站系统的建设,以前所熟悉的内网业务系统架构在面对互联网应用和访问时,居然显得力不从心。在这2年接触的第一个项目时,对网站搭建只满足于多假设几台应用服务器,通过负载均衡设备进行一下配置形成集群服务器,可是这样的架构,在网站运行不到1个月的情况下,几乎天天遇到应用服务响应缓慢甚至彻底中断服务的情况,实话说,要是不了解网站应用的架构,真的是应付不了这样的问题了,后来经历了长达半年的各种折磨,总算对网站架构摸出了些路子,结合作者这本书的内容,我也说说感受。

       我是觉得没有哪个网站从一开始就能够是大型网站,也没有哪个网站一上线就能吸引来庞大的用户,高并发访问,形成海量的数据,都经历了从小发展到大的过程。我认为大型网站应用系统应该有这几个特点:
1、用户分布广、网络环境复杂;
2、高并发、流量大;
3、海量的数据存储;
4、安全问题高度集中;
5、变更和发布频繁

       我们当时在完善网站系统性能、稳定性、可用性时,依次经历了这样的过程:
1、 初期、使用负载均衡配置应用服务器集群;(后来经不住并发访问,频繁的压死服务);
2、 初期改进,加入了反向代理服务器,进一步增强负载均衡能力,将动静资源分离,并缓存静态资源;(后来还是会遇到压死服务的情况);
3、 初期完善,加入CDN,对全站静态资源进一步进行缓存(这时网站较为稳定了);
4、 中期,因用户对动态资源的访问增加,静态资源缓存作用越发不明显,我们将频繁访问的数据进行了缓存来解决;
5、 中期改进,应用服务此时运行平稳,系统瓶颈出现在了大文件并发下载上,系统总是下载文件失败,这时改变了应用直接访问NAS的方式,引入分布式文件系统,这个过程中的文件数据迁移占据了我们工作的主要内容;
6、 中期完善,将数据库进行分库分表,把读写分开,这时应为初期对应用系统设计时忽略了这点,所以分库时,程序修改较大;
7、 后期,系统运行总算是稳定了,但是遭受到了黑客的攻击,还好,黑客哥哥没有造成太大的破坏,没有篡改系统、应用的数据和信息,这时我们才意识到网站防攻击的脆弱,才逐步建立安全防护机制,引入安全防护设备,一定程度提高了网站的安全防护能力。

 

       以上是我们工作的一个逐步过程,通过看这本书,发现作者描述网站演化的过程,竟然出奇的相似,所以我只能感叹当时做这些工作时,没能及时遇到这本书,走了不少弯路。

       本书中,作者描述了网站架构随需求逐渐演化的过程:
单机部署 -> 拆分数据库与应用(各自采用独立的服务器) -> 应用服务器采用集群方式 -> 引用负载均衡设备(session问题) -> 数据库读写分离 -> 引入搜索引擎 -> 引入数据缓存 -> 引入分布式存储系统 -> 数据拆分 -> 应用拆分 -> 服务化

       在这个过程中突然想到前几年流行的应用系统SOA架构技术,其实看看大型网站最后的结构,从硬件、应用方面看都像是SOA思想的延伸,我认为在最终形成的架构中,这两几项内容具有一定的难度和复杂度:
1、分布式的session保持机制


关于分布式session保持机制,我们当时只是靠应用中间件自身提供的机制来进行session同步,这个缺点正如作者所说:网络宽带开销大、session有变化就需要在各web服务器之间进行同步,如果session数据大,机器保存session的内存占用会严重
本书中,作者提到了其他三种session保持机制
(1)、粘性session 缺点: 单机故障,会话数据丢失
(2)、session数据集中存储: 缺点:引入了网络操作,存在时延和不稳定性  web服务器大、session数多、这个方案的优势明显
(3)、cookie解决方案: 缺点:cookie有长度限制、安全性、数据中心的整体外部带宽消耗
使用哪种方式,的确需要根据系统的需求来进行确定。

 

2、分布式数据库的数据同步、数据库读写分离、主库性能的提升
数据复制性存在难度,数据库本身带有复制功能,但是有时延,另外应用对于数据源的选择是一个较为棘手的问题,我们目前只是固定哪些应用能访问哪些数据库。

 

3、数据拆分
(1)专库专用,数据垂直拆分,不同的表,拆分到不同的库,难点问题多数据源配置,跨业务的事务
(2)数据水平拆分,同一表的数据拆到两个数据库,sql在进行操作时,要能确定访问的数据在哪里

这几个问题作者在试读章节中没有过多的展开,都留在了后续章节,这确实够吊人胃口啦。
从试读章节,我感觉作者的思路很清晰,能引人入胜,对疑难问题都或多或少的提出了解决方案,非常有助于拓展读者思路,我是很期待在后续章节看到关于中间件的使用,对各种难题都采用了什么解决方案。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics