大用户量下的系统架构_第1页
大用户量下的系统架构_第2页
大用户量下的系统架构_第3页
大用户量下的系统架构_第4页
大用户量下的系统架构_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

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

文档简介

无限扩展大用户量下的系统架构问题一个高并发的系统一个稳定的系统一个高扩展性的架构一个简洁的方案我们需要的是2解析系统架构中的底层元素稳定性和扩展性后台数据处理前台用户请求实时数据和非实时数据要做到这一点必须要考虑....3简洁简洁是最重要的设计依据将复杂的系统拆分成简洁的模块减少系统维护的代价限制使用复杂的功能4简洁的Sql必须对Sql的使用做限制绝对不允许出现跨表的查询DB的设计更大程度上取决于缓存的设计防止穿透缓存直接到达DB的访问将业务逻辑放到代码中实现,不要忘了DB的主要作用毕竟是存储5简洁的缓存必须限制使用缓存的方法本地缓存/集群缓存维护缓存的数据拒绝维护多个缓存之间的同步6简洁的服务什么才是服务没有业务逻辑的基础服务包含业务逻辑的复杂服务独立折分和部署数据读写部分只交给服务处理尽量减少服务之间的相互依赖Controll负责服务之间的调度7简洁的扩展因为简洁,所以容易Mysql的读写分离和分库分布式的Memcache多个Service的布署多个Controller的布署8强大工欲善其事,必先利其器尽可能多的做设计尽可能少的写实现尽可能多的测试尽可能多的分析9强大的DALDAL应该做到的事情控制Sql的使用一个黑盒子详细的日志记录10强大的ScallopScallop又该做什么零代码,非侵入和SCA的完美融合如何控制Service的加入和移除保留多种负载均衡模式的扩展性11强大的SCA你做什么都可以告诉SCA轻代码非侵入性RMI/WebService/JMS简单的服务和复杂的服务12强大的代码生成工具什么才是工程师必须做的你来做数据库/Service/复杂业务逻辑我来做底层代码/Service/配置文件的实现不把时间花费在重复执行的环节上13核心系统设计中考虑的核心拆解模块模块之间如何交互计算的部分存储的部分交互的部分变化的部分14将系统拆解成Service为什么选择Service复用高内聚调试部署15RMI是系统调用的核心最常使用的调用方式高效很低的学习曲线16JMS是系统解耦的核心什么时候使用JMS解决长尾逻辑更轻松的方式稳定的消息系统17ETL是计算部分的核心如何使用ETLETL用来做数据转换ETL不应该直接读写自己的DBETL一般情况下只允许部署一台ETL的日志监控和统计邮件ETL的部署18缓存架构是系统性能的核心缓存,还是缓存缓存是用来解决并发问题的缓存不是内存数据库缓存是分级别的19存储系统的扩展性虽然我们拥有缓存,但是Mysql依然做好了大数据量的准备读写分离是需要的虽然单表的性能支持千万级别的记录,还是需要使用分库的功能分库对Sql的使用要求更严格20Comet是用户交互的核心已经相当成熟的技术框架Erlang对大规模用户量的支持Comet技术对用户交互的体难21Drools和Groovy是动态计算的核心总有些非实时的计算那些变动比较大的业务逻辑工程师和业务人员的协作22核心回顾系统设计中考虑的核心拆解模块(Service)模块之间如何交互(RMI/JMS)计算的部分(ETL)存储的部分(Mysql/读写分离/分库)交互的部分(Comet)变化的部分(Drools/Groovy)23系统架构图ServiceServiceServiceServiceServiceService

温馨提示

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

评论

0/150

提交评论