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