开源SaaS解决方案

1、SaaS关键技术 -开源解决方案Copyright 2009 Neusoft Corporation解决方案技术中心Part 1：IT部署视图演化及挑战Part 2：动态基础设施Part 3：SaaS架构关注技术Part 4： Q&AIT系统部署视图演化-1N轮视图演化后架构演化面对的挑战基础设施可扩展计算资源快速的供给应用快速部署资源按需分配自动化管理的能力应用架构可扩展应用服务器可水平扩展数据库水平可扩展异步消息队列缓存机制应用负载均衡流程可定制功能可配置Part 1：IT部署视图演化及挑战Part 2：动态基础设施Part 3：SaaS架构关注技术Part 4： Q & A云计算关键特性

2、计算服务化资源虚拟化管理智能化自服务化基础设施供应生命周期资源池动态伸缩CloudCloudDDDDDDDDDPart 1：IT部署视图演化及挑战Part 2：动态基础设施Part 3：SaaS关注技术Part 4：Q&ASaaS关键特性高可用性高伸缩性高性能高伸缩：多租户，功能可配置，流程可配置SaaS 架构关注内容1.数据存储区域2.数据访问区域3.缓存区域4.应用服务服务区域5.Web服务器区域6.分布式文件区域7.MQ消息队列区域8. 负载均衡区域9. 其它技术数据存储的挑战SaaS数据存储模式完全独立模式（独立数据库模式）部分独立模式（共享数据库、独立数据结构模式）完全共享模式（共享

3、数据库、共享数据结构模式）成长的烦恼高并发的数据读写访问海量数据的高效读写访问及管理高扩展及高可用性传统解决方案VS 新兴解决方案 SQL 采用集群方式分担系统压力Partition方式Sharding方式 （垂直，水平）读写分离预留字段值对/行专列Xml扩展不足：扩展性不好成本高NoSQL内置集群支持很容易水平扩展强大数据备份功能支持Mapreduce功能不足：不支持SQL目前都是开业的没有商业产品不支持或是局部支持事务SQL集群技术-MySQL集群方案有点缺点速度适用场合NDB可用于负载均衡场合； 可用于高可靠性场合； 高伸缩性； 真正的数据库冗余； 容易维护。随着数据库的变大，对RAM的

4、需求变得更大，因此成本很高几乎 比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍。冗余，高可靠 性，负载均衡MySQL / GFS-GNBD/ HA (Active/Passive) 高可靠性 某种程度的冗余 按照高可靠性进行伸缩没有负 载均衡 没有保证的冗余 无法对写操作进行伸缩对读操作支持得较好需要高可靠性的、读操作密集型的应用MySQL / DRBD / HA (Active/Passive) 高可靠性； 一定程度的冗余； 以 高可靠性名义来看是可伸缩的没有负载均衡 没有保证的冗余 在写负载方面没有伸缩性在读写方面相当于单独服务器需要高可靠性、读操作密集型的应

5、用 MySQL Write Master / Multiple MySQL Read Slaves (Active/Active) 读操作的高可靠性； 读操作的负载均衡； 在读 操作负载均衡方面是可伸缩的无写操作的高可靠性； 无写操作的负载均衡； 在写操作方面无伸缩性同单独服务器；在读操作方面支持得较好读操作密集型的、需要高可靠性和负载均衡的应用Google MySQL MMM技术Sharding vs PartitionShardingPartition存储依赖可跨越DB可跨越物理机器可跨越表空间,不同的物理属性不能跨DB存储存储方式分布式集中式扩展性Scale Out(横向扩展)Scale

6、 Up(升级设备)可用性无单点，需要处理跨数据事务存在单点(DB数据本身)应用场景web 2.0多数传统应用数据切分-SQL实现方式优点缺点垂直切分实现简单扩展能力有限强耦合的应用不容易垂直切分读写分离可有效分担读的压力主要在数据库层扩展，应用修改小对读写均衡的应用扩展能有限依赖于数据库本身的同步能力水平切分SaaS普遍使用扩展性强实施复杂垂直shardinguserphrAppDAL水平shardingPhr 33%Phr 33%AppDALPhr 34%读写分离phrphrAppDAL读/写读SQL数据访问区域(DAL)1.mysql proxy 实现“读写分离（Read/Write Sp

7、litting）”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。2.Amoeba Amoeba项目是分布式数据库 proxy 开发框架。座落与Client、DB Server(s)之间。对客户 端透明。具有负载均衡、高可用性、sql过滤、读写分离、可路由相关的query到目标数据库、可并发请 求多台数据库合并结果。 主要解决： * 降低 数据切分带来的复杂多数据库结构 * 提供切分规则并降低 数据切分规则 给应用带来的影响 * 降低db 与客户端的连接数 * 读写分离3.Websphere IICase 1

8、 Case 1数据生成分布规则：按照20会员每天采集一次监控，每次采集10个指标（都为数值型）计算，按照20万会员2010年全年的数据量，共计生成 7.3 亿条记录。分布在4个节点中，每台设备1.825亿条。共计50GB。血压标签统计地区执行时间120150901208090test0np_034539ms15732123140882123Transaction NameMinimumAverageMaximumStd. Deviation90 Percentquery0.0010.0343.820.1560.04Sql 数据扩展问题Case 2 hadoop HBase& Hive2003年

9、Google三篇论文:GFS,MapReduce,Bigtable Hbase是一个分布式开源数据库，基于Hadoop分布式文件系统，模仿并提供了基于Google文件系统的Bigtable数据库的所有功能。 其目标是处理非常庞大的表，可以用普通的计算机处理超过10亿行数据，并且有数百万列元素组成的数据表。MapReduce是分布式计算软件构架，它可以支持大数据量的分布式并行处理。Hadoop 软件栈Table & Column FamilyRow Key Timestamp Column Family 血压（高压）血压（低压）phr_user1t312080t213090t1phr_user2

10、t514070t414585Row Key: 行键，Table的主键，Table中的记录按照Row Key排序Timestamp: 时间戳，每次数据操作对应的时间戳，可以看作是数据的version numberColumn Family：列簇，Table在水平方向有一个或者多个Column Family组成，一个Column Family中可以由任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。Case 2 hadoop HBase& HiveCase 2 - hadoop

11、& 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.867SQL

12、 与NoSQL整合方案- hadoop & HiveDBMS从MySQL读写部分数据读NoSQLNoSQL同步1.DBMS保存全部数据，主要完成交易类数据的读写2.通过同步技术把DBMS的数据同步到NoSQL数据库中3.NoSQL负责完成历史数据的查询统计分析等工作NoSQL数据库-MongoDBMongoDB 与MySQL混搭采用MySQL与mongoDB混搭的模式，利用NoSQL数据的列可以动态扩展的优势来避免在关系数据库为了扩展所采用行转列导致的数据爆炸性增长的问题1.面向集合的存储：适合存储对象及JSON形式的数据。2.动态查询：Mongo支持丰富的查询表达式。3.完整的索引支持：包括

13、文档内嵌对象及数组。 Mongo的查询优化 器会分析查询表达式4.复制及自动故障转移。不适用：高度事务性的系统传统的商业智能应用SQL数据库扩展的问题ID 100ID200AppDALID300ID400NoSQL数据库扩展phrphrAppDALphrphr数据缓存工作原理DBMS客户端App ServerCacheDBMSCacheCacheCache第一次，从数据库读取数据，并写入缓存第二次，从缓存读取数据，如果数据不存在， 那么，在去数据库查询数据目的：避免磁盘IO提高效率，减轻数据库压力开源缓存对比实现方式优点缺点Terracotta采用JVM的heap复制方式不是通过对象序列化的方

14、式传输Java实现可以无缝整合到JEE应用本身可以提供集群字节码级的监控可能会影响效率配置比较复杂memcachedC开发效率高对CPU资源要求低水平扩展性强非java应用需要通过socket调用不提供集群技术，需要自己实现，比较复杂Ehcache/OSCache可以运行在中间价同一个JVM中，执行效力高集群需要作缓存同步水平扩展能力有限需要占用JVM的heap云平台缓存方案客户端App ServerMemcacheEHCacheMemcacheMemcacheMemcacheApp ServerEHCache采用Memcached 作为分布式缓存为了保证系统执行效率采用ehCache作为二级

15、缓存在ehcache设置缓存时间，过期后到Memcached 组成的缓存池获得数据。该方案也可以采用Terracotta应用服务服务区域业务系统的主要业务逻辑运行在应用服务器中，所以，它承担了更大的压力，面临如下挑战：1.大并发访问需要做应用服务器集群2.系统为了更可用性和友好性支持无缝切换应用服务器session管理实现方式优点缺点典型做法session复制复制负载可以得到极好均衡，也可以保持对fail-over支持sesion复制对网络压力比较大。需要应用服务器支持目前流行的中间件产品都支持sticky session实现简单，在负载均衡层或是proxy层做配置即可不会因为session同

16、步给网络带来压力不能实现完全负载均衡、无法实现fail overapache 或是其它webserver做propxy基于cache集中式session应用服务器是无状态，可实现完全负载均衡，不会带来因为session复制带来的网络压力实施复杂，对于部分功能需要定制开发使用Terracotta或是memcache等云下有状态应用方案-memached-session客户端App ServerMemcacheMemcacheMemcacheMemcacheApp Servermemcached-session-manager具有如下特性：1.支持tomcat6和tomcat72.能够保持stic

17、ky会话和none sticky会话3.能够支持tomcat失败转移4.能够支持Memcached失败转移5.实现session序列化6.可以实现session的异步存储7.Session修改更新Memcached8.JMX管理和监控云下有状态应用方案 - Terracotta客户端App ServerTerracoattTerracoattTerracoattTerracoattApp Server1.Terracotta 本身支持集群，避免单点故障(双机或者多机镜像)2. Terracotta的基础是分布式数据共享和线程协同3.不是通过对象序列化的方式传输，支持Field级别的变更同步4.

18、不需要修改程序5.支持目前主流的中间价agentagentWeb server区域Apache vs Nginx vs lighttpd 反向代理等功能1.作为老牌HttpServer，Apache Httpd在功能表现上令人满意，配置相对简单，功能丰富并且稳定，可以任意编译添加所需功能的模块。2.Nginx作为新兴的HttpServer，在性能表现上令人满意，功能相对丰富，作为功能相对简单的应用前台HttpServer是可以推荐的，而且HttpServer可以做到动态更改配置文件，不需要长时间中断服务。3.Lighttpd性能表现很好，但是在功能上有很多不稳定之处。Web server静态资

19、源分离静态资源（图片，js脚本，css等）使用单独的服务器处理请求http ServerApp server浏览器静态资源静态资源动态请求动态请求动态请示动态请示分布式文件作用 SaaS业务系统面临着海量小图片数据的存储问题，这些图片数据大小在几K几十K不等但数目非常庞大，处理这些海量数据小文件传统文件系统已经不能满足要求，系统在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。使用分布式存储技术来解决图片数据管理和容量扩展等方面的问题客户端App ServerNAS存储/磁盘阵列App Server分布式文件系统工作原理存储

20、节点，即Storage Cluster，完成文件管理的所有功能。包括存储、同步和提供存取接口；同时通过对meta data的管理实现了IO的并行和高效访问。 具有云存储虚拟、自治、高效特点的实验项目，支持多盘组、异构整合。Tracker，即跟踪器主要负责IO调度，通过负载均衡方式实现可靠、快速的资源存取。 Client可以是以Service的方式对云存储提供IO服务。MogileDFS VS FastDFS Case3 GIS系统地图栅格数据测试消息队列程序解耦消息可靠性到达异步通信提供效率企业级消息队列1.消息严格的排序；2.支持事务3.信息通过持久化的方式保证安全可靠代表产品：1.Apac

21、he ActiveMQ2.Jboss MQ3.IBM MQ4.Weblogic JMS适合场景：企业级应用中消息可靠传输互联网消息队列1.消息不需要严格的排序；2.不支持事务大多数情况可接受3.读写数据非常快4.横向扩展性好代表产品：Kestrel适合场景：1.互联网应用中消息动态Case4 Kestrel性能表现线程并发数存入10000条消息总时间（单位：秒）平均 TPS第一次第二次第三次平均 13.1446286813.3789056913.2551921773.2595755163067.88102.3287159322.2632132852.2974953192.2964748454354.5502.6794187122.643695