• 1. SaaS关键技术 ----开源解决方案Copyright © 2009 Neusoft Corporation解决方案技术中心
  • 2. Part 1:IT部署视图演化及挑战 Part 2:动态基础设施 Part 3:SaaS架构关注技术 Part 4: Q&A
  • 3. IT系统部署视图演化-1
  • 4. N轮视图演化后架构
  • 5. (本页无文本内容)
  • 6. 演化面对的挑战基础设施可扩展计算资源快速的供给应用快速部署资源按需分配自动化管理的能力应用架构可扩展应用服务器可水平扩展数据库水平可扩展异步消息队列缓存机制应用负载均衡流程可定制功能可配置
  • 7. Part 1:IT部署视图演化及挑战 Part 2:动态基础设施 Part 3:SaaS架构关注技术 Part 4: Q & A
  • 8. 云计算关键特性计算服务化资源虚拟化管理智能化自服务化
  • 9. 基础设施供应生命周期
  • 10. 资源池动态伸缩CloudCloudDDDDDDDDD
  • 11. Part 1:IT部署视图演化及挑战 Part 2:动态基础设施 Part 3:SaaS关注技术 Part 4:Q&A
  • 12. SaaS关键特性高可用性高伸缩性高性能高伸缩:多租户,功能可配置,流程可配置
  • 13. SaaS 架构关注内容1.数据存储区域2.数据访问区域3.缓存区域4.应用服务服务区域5.Web服务器区域6.分布式文件区域7.MQ消息队列区域8. 负载均衡区域9. 其它技术
  • 14. 数据存储的挑战SaaS数据存储模式完全独立模式(独立数据库模式)部分独立模式(共享数据库、独立数据结构模式)完全共享模式(共享数据库、共享数据结构模式)成长的烦恼高并发的数据读写访问海量数据的高效读写访问及管理高扩展及高可用性
  • 15. 传统解决方案VS 新兴解决方案 SQL 采用集群方式分担系统压力Partition方式Sharding方式 (垂直,水平)读写分离预留字段值对/行专列Xml扩展不足:扩展性不好成本高NoSQL内置集群支持很容易水平扩展强大数据备份功能支持Mapreduce功能不足:不支持SQL目前都是开业的没有商业产品不支持或是局部支持事务
  • 16. SQL集群技术-MySQL集群方案有点缺点速度适用场合NDB可用于负载均衡场合; 可用于高可靠性场合; 高伸缩性; 真正的数据库冗余; 容易维护。 随着数据库的变大,对RAM的需求变得更大,因此成本很高几乎 比典型的单独服务器(无千兆以太网,无SCI卡,存储引擎相关的限制少)慢10倍。冗余,高可靠 性,负载均衡MySQL / GFS-GNBD/ HA (Active/Passive) 高可靠性 某种程度的冗余 按照高可靠性进行伸缩 没有负 载均衡 没有保证的冗余 无法对写操作进行伸缩 对读操作支持得较好需要高可靠性的、读操作密集型的应用MySQL / DRBD / HA (Active/Passive) 高可靠性; 一定程度的冗余; 以 高可靠性名义来看是可伸缩的 没有负载均衡 没有保证的冗余 在写负载方面没有伸缩性 在读写方面相当于单独服务器需要高可靠性、读操作密集型的应用 MySQL Write Master / Multiple MySQL Read Slaves (Active/Active) 读操作的高可靠性; 读操作的负载均衡; 在读 操作负载均衡方面是可伸缩的 无写操作的高可靠性; 无写操作的负载均衡; 在写操作方面无伸缩性 同单独服务器;在读操作方面支持得较好读操作密集型的、需要高可靠性和负载均衡的应用Google MySQL MMM技术
  • 17. Sharding vs PartitionShardingPartition存储依赖可跨越DB 可跨越物理机器可跨越表空间,不同的物理属性 不能跨DB存储存储方式分布式集中式扩展性Scale Out(横向扩展)Scale Up(升级设备)可用性无单点,需要处理跨数据事务存在单点(DB数据本身)应用场景web 2.0多数传统应用
  • 18. 数据切分-SQL实现方式优点缺点垂直切分实现简单扩展能力有限 强耦合的应用不容易垂直切分读写分离可有效分担读的压力 主要在数据库层扩展,应用修改小对读写均衡的应用扩展能有限 依赖于数据库本身的同步能力水平切分SaaS普遍使用 扩展性强实施复杂
  • 19. 垂直shardinguserphrAppDAL
  • 20. 水平shardingPhr 33%Phr 33%AppDALPhr 34%
  • 21. 读写分离phrphrAppDAL读/写读
  • 22. SQL数据访问区域(DAL)1.mysql proxy 实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询,而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 2.Amoeba Amoeba项目是分布式数据库 proxy 开发框架。座落与Client、DB Server(s)之间。对客户 端透明。具有负载均衡、高可用性、sql过滤、读写分离、可路由相关的query到目标数据库、可并发请 求多台数据库合并结果。 主要解决: * 降低 数据切分带来的复杂多数据库结构 * 提供切分规则并降低 数据切分规则 给应用带来的影响 * 降低db 与客户端的连接数 * 读写分离 3.Websphere II
  • 23. Case 1
  • 24. Case 1数据生成分布规则: 按照20会员每天采集一次监控,每次采集10个指标(都为数值型)计算,按照20万会员2010年全年的数据量,共计生成 7.3 亿条记录。分布在4个节点中,每台设备1.825亿条。共计50GB。 血压标签统计地区执行时间120~15090~12080~90test0np_034539ms15732123140882123Transaction NameMinimumAverageMaximumStd. Deviation90 Percentquery0.0010.0343.820.1560.04
  • 25. Sql 数据扩展问题
  • 26. Case 2 –hadoop HBase& Hive2003年Google三篇论文:GFS,MapReduce,Bigtable Hbase是一个分布式开源数据库,基于Hadoop分布式文件系统,模仿并提供了基于Google文件系统的Bigtable数据库的所有功能。 其目标是处理非常庞大的表,可以用普通的计算机处理超过10亿行数据,并且有数百万列元素组成的数据表。 MapReduce是分布式计算软件构架,它可以支持大数据量的分布式并行处理。
  • 27. Hadoop 软件栈
  • 28. Table & Column Family Row Key Timestamp Column Family 血压(高压)血压(低压)phr_user1t312080t213090t1  phr_user2t514070t414585 Row Key: 行键,Table的主键,Table中的记录按照Row Key排序 Timestamp: 时间戳,每次数据操作对应的时间戳,可以看作是数据的version number Column Family:列簇,Table在水平方向有一个或者多个Column Family组成,一个Column Family中可以由任意多个Column组成,即Column Family支持动态扩展,无需预先定义Column的数量以及类型,所有Column均以二进制格式存储,用户需要自行进行类型转换。
  • 29. Case 2 –hadoop HBase& Hive
  • 30. Case 2 - hadoop & Hive交易名称交易响应时间(单位:秒)Average TPSMinimumAverageMaximum90 PercentInsert空表0.0010.0121.0760.03595.863Insert(3.06亿)0.0010.0120.0590.03995.758交易名称交易响应时间(单位:秒)Average TPSMinimumAverageMaximum90 PercentQuery0.0140.1454.2380.19627.47交易响应时间(单位:秒)4节点6节点8节点一个月数据140.007140.061147.029一年数据522.351285.998292.867
  • 31. SQL 与NoSQL整合方案- hadoop & HiveDBMS从MySQL读写部分数据读NoSQLNoSQL同步1.DBMS保存全部数据,主要完成交易类数据的读写 2.通过同步技术把DBMS的数据同步到NoSQL数据库中 3.NoSQL负责完成历史数据的查询统计分析等工作
  • 32. NoSQL数据库--MongoDB
  • 33. MongoDB 与MySQL混搭采用MySQL与mongoDB混搭的模式,利用NoSQL数据 的列可以动态扩展的优势来避免在关系数据库为了 扩展所采用行转列导致的数据爆炸性增长的问题 1.面向集合的存储:适合存储对象及JSON形式的数据。 2.动态查询:Mongo支持丰富的查询表达式。 3.完整的索引支持:包括文档内嵌对象及数组。 Mongo的查询优化 器会分析查询表达式 4.复制及自动故障转移。 不适用: 高度事务性的系统 传统的商业智能应用
  • 34. SQL数据库扩展的问题ID <100ID<200AppDALID<300ID<400
  • 35. NoSQL数据库扩展phrphrAppDALphrphr
  • 36. 数据缓存工作原理DBMS客户端App ServerCacheDBMSCacheCacheCache第一次,从数据库读取数据,并写入缓存 第二次,从缓存读取数据,如果数据不存在, 那么,在去数据库查询数据目的: 避免磁盘IO提高效率,减轻数据库压力
  • 37. 开源缓存对比实现方式优点缺点Terracotta采用JVM的heap复制方式 不是通过对象序列化的方式传输 Java实现可以无缝整合到JEE应用 本身可以提供集群字节码级的监控可能会影响效率 配置比较复杂 memcachedC开发效率高 对CPU资源要求低 水平扩展性强非java应用需要通过socket调用 不提供集群技术,需要自己实现,比较复杂Ehcache/OSCache可以运行在中间价同一个JVM中,执行效力高集群需要作缓存同步 水平扩展能力有限 需要占用JVM的heap
  • 38. 云平台缓存方案客户端App ServerMemcacheEHCacheMemcacheMemcacheMemcacheApp ServerEHCache采用Memcached 作为分布式缓存 为了保证系统执行效率采用ehCache作为二级缓存 在ehcache设置缓存时间,过期后到Memcached 组成的缓存池获得数据。该方案也可以采用Terracotta
  • 39. 应用服务服务区域业务系统的主要业务逻辑运行在应用服务器中,所以,它承担了更大的压力,面临如下挑战: 1.大并发访问需要做应用服务器集群 2.系统为了更可用性和友好性支持无缝切换
  • 40. 应用服务器session管理实现方式优点缺点典型做法session复制复制负载可以得到极好均衡,也可以保持对fail-over支持sesion复制对网络压力比较大。 需要应用服务器支持目前流行的中间件产品都支持sticky session实现简单,在负载均衡层或是proxy层做配置即可 不会因为session同步给网络带来压力不能实现完全负载均衡、无法实现fail overapache 或是其它webserver做propxy基于cache集中式session应用服务器是无状态,可实现完全负载均衡,不会带来因为session复制带来的网络压力实施复杂,对于部分功能需要定制开发使用Terracotta或是memcache等
  • 41. 云下有状态应用方案-memached-session客户端App ServerMemcacheMemcacheMemcacheMemcacheApp Servermemcached-session-manager具有如下特性: 1.支持tomcat6和tomcat7 2.能够保持sticky会话和none sticky会话 3.能够支持tomcat失败转移 4.能够支持Memcached失败转移 5.实现session序列化 6.可以实现session的异步存储 7.Session修改更新Memcached 8.JMX管理和监控
  • 42. 云下有状态应用方案 - Terracotta客户端App ServerTerracoattTerracoattTerracoattTerracoattApp Server1.Terracotta 本身支持集群,避免单点故障(双机或者多机镜像) 2. Terracotta的基础是分布式数据共享和线程协同 3.不是通过对象序列化的方式传输,支持Field级别的变更同步 4.不需要修改程序 5.支持目前主流的中间价agentagent
  • 43. Web server区域Apache vs Nginx vs lighttpd 反向代理等功能 1.作为老牌HttpServer,Apache Httpd在功能表现上令人满意,配置相对简单,功能丰富并且稳定,可以任意编译添加所需功能的模块。 2.Nginx作为新兴的HttpServer,在性能表现上令人满意,功能相对丰富,作为功能相对简单的应用前台HttpServer是可以推荐的,而且HttpServer可以做到动态更改配置文件,不需要长时间中断服务。 3.Lighttpd性能表现很好,但是在功能上有很多不稳定之处。
  • 44. Web server静态资源分离静态资源(图片,js脚本,css等)使用单独的服务器处理请求 http ServerApp server浏 览 器静态资源静态资源动态请求动态请求动态请示动态请示
  • 45. 分布式文件作用 SaaS业务系统面临着海量小图片数据的存储问题,这些图片数据大小在几K~几十K不等但数目非常庞大,处理这些海量数据小文件传统文件系统已经不能满足要求,系统在scaling的过程中都遇到了这样的问题:磁盘IO过高;备份困难;单点问题,容量和读写无法水平扩展,还存在故障的可能。使用分布式存储技术来解决图片数据管理和容量扩展等方面的问题客户端App ServerNAS存储/磁盘阵列App Server
  • 46. 分布式文件系统工作原理存储节点,即Storage Cluster,完成文件管理的所有功能。包括存储、同步和提供存取接口;同时通过对meta data的管理实现了IO的并行和高效访问。 具有云存储虚拟、自治、高效特点的实验项目,支持多盘组、异构整合。 Tracker,即跟踪器主要负责IO调度,通过负载均衡方式实现可靠、快速的资源存取。 Client可以是以Service的方式对云存储提供IO服务。MogileDFS VS FastDFS
  • 47. Case3 GIS系统地图栅格数据测试
  • 48. 消息队列程序解耦 消息可靠性到达 异步通信提供效率
  • 49. 企业级消息队列1.消息严格的排序; 2.支持事务 3.信息通过持久化的方式保证安全可靠 代表产品: 1.Apache ActiveMQ 2.Jboss MQ 3.IBM MQ 4.Weblogic JMS 适合场景: 企业级应用中消息可靠传输
  • 50. 互联网消息队列1.消息不需要严格的排序; 2.不支持事务大多数情况可接受 3.读写数据非常快 4.横向扩展性好 代表产品: Kestrel 适合场景: 1.互联网应用中消息动态
  • 51. Case4 Kestrel性能表现线程并发数存入10000条消息总时间(单位:秒)平均 TPS第一次第二次第三次平均 13.1446286813.3789056913.2551921773.2595755163067.88102.3287159322.2632132852.2974953192.2964748454354.5502.6794187122.6436958022.5845161462.6358768873793.8
  • 52. 负载均衡区域http重定向 DNS负载均衡 反向代理负载均衡 IP负载均衡 对应产品包括: nginx apache httpd LVS(网络第四层工作) F5(硬件,四层/七层) redware (硬件,四层/七层)
  • 53. LVS结构工作模式: Virtual Server via Network Address Translation(VS/NAT) Virtual Server via IP Tunneling(VS/TUN) Virtual Server via Direct Routing(VS/DR) 协议内容TCPHTTP,FTP,PROXY,SMTP,POP3,IMAP4,DNS,LDAP,HTTPS,SSMTP 等UDPDNS,NTP,ICP,视频、音频流播放协议等
  • 54. LVS HA结构
  • 55. Case5 熙康数据上传业务
  • 56. Case5 熙康数据上传业务 该架构主要分为如下几个部分: 引入LVS主备的负载均衡模式 引入基于LVS的Tomcat负载均衡 引入ActiveMQ 的Master/Slave的模式 引入基于MMM的MySQL高可用模式 引入基于Spring的多线程技术 红色部分可以考虑在未来架构中引入Memcached 为了更好的利用系统资源,LVS,tomcat,ActiveMQ等均部署在基于XenServer的虚拟机上。
  • 57. Case5 测试结果
  • 58. 其它技术单点登陆 CMS Portal等
  • 59. Part 1:IT部署视图演化及挑战 Part 2:动态基础设施 Part 3:SaaS关注技术 Part 4:Q&A
  • 60. Copyright © 2009 Neusoft Corporation