Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

20140326联动优势数据访问层DAL架构和实践7(刘胜)工行交流

993 visualizaciones

Publicado el

20140326数据访问层dal架构和实践7(刘胜)工行交流.49p.out

Publicado en: Diseño
  • Sé el primero en comentar

20140326联动优势数据访问层DAL架构和实践7(刘胜)工行交流

  1. 1. 数据访问层DAL架构和实践(7)技术交流 技术规划中心软件组& 工行软件开发中心北京研发部 Version 7.1.20140425 刘胜liusheng@umpay.com 联动优势B办公区 北京市西城区安德路甲104号证通商务楼F5层(100120)
  2. 2. 2 0*历史版本  关于DAL的历史版本  20091224数据访问层DAL概念和实践1(刘胜).ppt 【概念/设计/原型】  20100330数据访问层DAL概念和实践2(刘胜).ppt 【实现/统一/远景】  20100902数据访问层DAL架构和实践3(刘胜).ppt 【接口/本地/模板】  专利201010506543.2 数据访问方法及装置  20120613数据访问层DAL架构和实践4(刘胜)新的特性.pptx  20130626数据访问层DAL架构和实践5(刘胜)数据分片.pptx  20131030数据访问层DAL架构和实践6(殷舒)SQL解析.ppt  20140116技术开发小组沟通会6(刘胜)论Jdbc4dal可行性和用户信息收集.pptx  20140326数据访问层DAL架构和实践7(刘胜)技术交流.pptx  最近培训材料  20120613数据访问层DAL架构和实践4新的特性(刘胜).pptx  20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx  20121208联动优势2012年度述职报告(刘胜)1206正式版.pptx  20130325理解REST设计模式和反模式(刘胜)草案.pptx  20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx  20130604代码质量和单元测试(刘胜).pptx  20130604联动优势企业架构介绍(刘胜).pptx
  3. 3. 3 1 数据库集群访问中间层技术需求 1. 需求分析(数据库集群访问中间层)  需求理念和原则  原始需求  需求分析  需求细节 2. 现有DAL中间层技术介绍 3. 技术可行性分析(Jdbc4udal方案)
  4. 4. 4 1.0*需求原则:FQC原则引入(图) 分布式系统CAP定律 (Eric A. Brewer 2000) ——————————— Consistency 一致性 Availability 可用性 Partition tolerance 分布性 需求分析的FQC原则 (刘胜2014) ———————————— Functional Features 功能需求 Quality 质量需求 Cost reduction 成本需求 Pick Two ! Cost reduction
  5. 5. 5 1.0*需求原则:FQC原则解释(图)  分布系统CAP定律(2000 Brewer's theorem)  分布式系统最多只能满足CAP三项中的两项。 FQC != Final Quality Control  需求分析FQC原则(2014 刘胜)  Functional Features  Quality 特性需求:功能性 质量需求:非功能性  健壮性,高可用性,可读性、易维护、易扩展、…  Cost reduction  降低资金成本  降低硬件成本  降低人力成本  降低时间成本 Pick Two ! Partition tolerance Pick Two ! Cost reduction 质量决定后期成本(隐式成本) 成本决定前期成本(显式成本) TCO 在某些场景,不同成本可以转化,但转化损耗较高! 例如?——1)一个妈妈怀胎十月生宝宝;2)…
  6. 6. 6 1.1*原始需求:描述  解决问题:  当传统Web应用面对高并发数据访问需求时,原底层单数据库设 计难以有效支撑上层应用的数据访问,因此需要对数据库采用读 写分离或分库/分表等手段实施多库拆分,以便整体提高应用的高 可用性。  设计思路:  参照上述策略对原单数据库完成水平扩展后,就上层应用访问而 言,势必出现如SQL动态解析、多库路由读写访问、跨库事务一 致性、跨库查询结果数据合并/排序等问题,所以考虑引入数据访 问层DAL(数据库驱动层之上,应用DAO层/ORM框架层之下)以 便透明解决上述难题。  合作方式:  请帮忙了解贵公司目前是否存在该架构?如存在是否已形成产品 可直接对外出售?如不存在是否有意根据我行需求以单独承包/合 作开发的方式对该架构进行落地研发?
  7. 7. 7 1.1*原始需求:分析  需求特性:  1,多库路由读写访问【DONE:有两种策略】  2,跨库查询结果数据合并/排序【DONE:避免大结果集】  3,SQL动态解析【TODO:Jdbc4udal方案】  4,跨库事务一致性【UNDO:分布式事务】  设计思路:  数据库驱动层之上【Not Only JDBC】  应用DAO层/ORM框架层之下【YES/NO】  “透明” 【NOT ALL】  客户端透明地使用“RDB数据库” 【DONE:RDB,NOSQL,Anything】  客户端透明地使用全部功能特性【~缺陷透明,CAP原理】  客户端透明地使用DAL中间层【限定JDBC+SQL】  客户端透明地访问分片数据【DONE】 Pick Two ! Partition tolerance
  8. 8. 8 1.2 需求分析:不同的读写场景(图)  全库读写混合  根据读写比分类  高可写:主主模式  高可读:主从模式,读写分离  实现方式(读写分离)  读写使用不同VIP,动态DNS  定制客户端API  通过DAL服务器  分库只读  实现方式(分片路由)  定制客户端API路由  使用DAL服务器路由  分库读写混合  实现方式(CAP原理)  降低A(系统可用性)  降低C(事务一致性) DAL 代理?
  9. 9. 10 1.2*需求分析:不同层次的方案(图) 数据访问对象(DAO) 读写混合操作只读操作只写操作 ORM框架(iBatis, Hibernate, …) 自定义JDBC Driver ( Udal-Jdbc) 自定义Udal-Client (本地| 远程) HTTP或 CM20 DaaS 中间层(Udal-Server) JDBC (MySql) RDS 中间层(Amoeba, Cobar, DRDS, Atlas, … ) 关系型数据库(MySql/DB2/Oracle/…) NoSQL Tuxedo等 自定义 DataSource (Tddl, Zdal) 业 务 层 中 间 层 数 据 层 JDBC (MySql/Db2/Oracle) 2 4 1 3 4
  10. 10. 11 1.2+需求分析:不同模式中间层(图) RDS 中国主流国际主流 (Relational Database Service) ————————————— MySql-Proxy@MySQL Atlas@Qihoo360 Amoeba,Cobar@Alibaba TDDL@Alibaba RDS & DRDS@Alibaba DDB@网易杭研院 DDBS@百度 云数据库@腾讯 RDS@Amazon AzureSQL@MS CloudSQL@Google DBaaS & DaaS (Database as a Service) ——————————— JPA@SUN S3@Amazon DynamoDB@Amazon SimpleDB@Amazon CloudDataStore@Google BigTable & Spanner@Google Azure(Tables/Blobs/Queues)@MS DAL@iMobile … UDAL@UMPAY
  11. 11. 13 1.2*需求分析:不同机房的方案(图) Zone #A Zone #B 1.跨机房负载均衡 DalServer#A1 DalServer#A2 MySql #A集群 负载均衡器#A (如LVS/HaProxy) DB2 #A集群 Oracle #A集群 DalServer#B1 DalServer#B2 MySql #B集群 DB2 #B集群 Oracle #B集群 服务查找器#A (如DNS) 负载均衡器#B (如LVS/HaProxy) 服务查找器#B (如DNS) 网络协议(HTTP、TCP等) 存储接口(JDBC等) MongoDB #A集群 … 业务线应用系统 双向复制 2.跨机房远程服务路由 3. 跨机房远程数据源 PS:工行需求。CRM迁移案例。
  12. 12. 14 1.3 需求细节1 多库路由读写访问  读写分离后的访问路由【无分片,都是全库】  应用端区分【读写库不同域名,动态DNS】  服务端区分【SQL解析】  数据分片后的访问路由  场景分类  单表分片【DONE】  多表分片字段一致【DONE】  多表分片字段相似【DONE,如日、月、年】  多表分片规则不一致【不支持】  实现方式  根据“SQLID”路由【DONE 推荐方式】  根据“表名+字段值”路由【TODO 暂不支持】
  13. 13. 15 1.3 需求细节2 跨库查询结果集合并/排序  合并  小数据集合并【支持】  大数据集合并【有限制】  排序  单一字段排序【支持】  多个字段排序【可扩展】  其他  分页【支持】  分组(Group by) 【需扩展】
  14. 14. 16 1.3 需求细节3 解析SQL语句  从使用者角度  是否必须知道数据的存储方式? 【RDB,NOSQL】  是否必须知道数据库的厂商和版本? 【不同JDBC驱动】  是否必须知道数据库的表结构? 【SQL】  是否必须经过ORM?  从开发者角度(JDBC)  已有驱动vs. 定制驱动vs. 抛弃JDBC?  从性能的角度(透明方式)  DAO 【函数名+参数】  iBatis 【拼装为SQL语句】  JDBC 【构造网络报文】  *DAL/Codec 【解析网络报文】  *DAL/SqlParser  DAL/SqlRouter  DAL/SqlExecutor  DAL/ResultMerge【合并和排序】 1 2 3 4 5
  15. 15. 17 这个世界上只有一种一致性算法,那就是 Paxos,其它的算法都是残次品(包括 2PC和3PC等)——Google Chubby作者 Mike Burrows 1.3*需求细节4 分布式事务…  解决方案:  Classic Paxos(1990/1998)和Fast Paxos(2005)  二阶段提交(2PC) 【可靠但太重,JTA+支持XAResource的Jdbc驱动】  三阶段提交(3PC) 【询问时并不锁定资源,除非所有人都同意后才锁】  重试机制【不可靠】  异常恢复补偿【应用端】  容错理论  CAP理论  NWR模型【Amazon Dynamo,W+R>N】  一致性模型【弱一致性、最终一致性、强一致性】  拜占庭将军问题:BFT(Byzantine-Fault-Tolerance)Approach  agreement-based【replica广播】  quorum-based 【client协调】无并发写冲突时更优
  16. 16. 18 1.3 需求细节5 多表关联(JOIN)  跨库多表关联/JOIN 【不支持】  同库多表关联/JOIN 【尽量支持】  单表分片  多表分片字段一致  多表分片字段相似【如:日、月、年】  多表分片规则不一致【不支持】
  17. 17. 19 2 现有DAL中间层技术介绍 1. 需求分析(数据库集群访问中间层) 2. 现有DAL中间层技术介绍  概念  需求:  背景:已有技术  现状:UDAL 3. 技术可行性分析(Jdbc4udal方案)
  18. 18. 20 2.0 概念:数据访问层DAL  数据访问层DAL  Data Access Layer(Layer=Services)  DAL是一系列服务的集合,是DAO的自然延伸,是 SOA的具体实现。  部署DAL的好处  简化客户端接口,规范数据访问操作  保持客户端接口,动态升级服务端实现  支持更多客户端:Java/C/PHP/…  共享数据库连接,减少总数据连接数  更细粒度访问控制  方便实施服务治理:权限/管理/监控/分析/优化/…  方便实施数据库的迁移/升级/重构/…  方便实施读写分离,支持高并发访问  方便实施数据分片,支持海量数据库  。。。
  19. 19. 21 2.0 概念:What and Why  概念:数据访问层DAL 【Layer=Services】  【维基百科】A Data Access Layer (DAL) is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, such as an entity-relational database. This data access layer is used in turn by other program modules to access and manipulate the data within the data store without having to deal with the complexities inherent in this access.  DAL是一系列服务的集合,是DAO在大型系统中的自然延伸,是SOA的具体实现。  好处:  简化客户端接口,规范数据操作【透明性分片】  保持客户端接口,动态升级服务端实现【SOA】  支持对巨量数据的访问【缓存;读写分离;分片(分库/分表)】  服务的治理【认证/管理/权限/监控/分析/优化/…】  功能需求:  访问代理【Proxy】  读写分离【RAIDb-1镜像,每个库都是全库。写库是单点】  数据分片【RAIDb-0分区,每个库都是子库。】  高可用性【支持Quorum-NWR模型——多个写库】  特性需求:  平台中立【DAL服务器,可部署在多种平台上】  语言中立【DAL客户端,支持Java、C/C++、PHP、Flex等多种语言。】  数据库中立【1)多种数据库类型;2)多个数据库版本?】  资源共享【1) 共享DataSource连接池; 2)共享Cache。】  访问日志【1)提供SqlLog可用于性能瓶颈分析;2)提供BackLog可用于数据恢复。】  访问控制【1)用户认证;2)连接管理;3)权限控制。】  读写分离【FullDB】  数据分片【分表,分库】  访问集群【负载均衡:HA-Proxy、JGroup】
  20. 20. 22 2.0 概念:高可用数据存储架构(问)  Share-Anything架构  案例:Oracle RAC共享缓存和存储  缺点:扩展能力有限(<10)  Share-Storage主备架构  案例:DB2双机主备方案  缺点:存储是单点  Share-Nothing分区架构  案例:DB2v9分区方案  缺点:管理节点是单点?  Share-Nothing主从架构(问:区别?)  案例:MySQL主从单向复制  缺点:写库是单点,也是瓶颈  Share-Nothing主主架构  案例:MySQL主从双向复制  缺点:未读写分离  Share-Nothing双主多从  优点:写库非单点,第一写库可停机  缺点:写库是瓶颈,第二写库不能停机 DAL 代理?
  21. 21. 23 2.1 需求:核心库减负(简)  问题1:核心数据库不堪重负(201106)  数据量大  用户表:tuser + tuserBank  交易表:transAll  七天翻滚表  数据冗余 要么分区,要么分片。 分区成本高,依赖厂商技术。 分片阻力大,应用端改动多。  数据表多个版本混存,每个用户记录两次,每条交易记录两次。【双写】  个别应用过度依赖于TransAll表,未做日表翻滚。【分片】  系统迁移不彻底,有残留数据。(用户管理系统:望京丰台) 【多查】  读写不均【读写分离】  淘宝读写比测算:10:1(来自iDataForum)  联动读写比估算:用户表(20:1),交易表(2:1)  连接池问题: 【连接共享】  应用太多太分散,容易使数据库连接总数超限,导致DB中断  问题2:针对复杂的数据库部署,应用开发困难  同时连多个数据库 对于简单分片, 也能凑活实现。  依次查多个数据库表:丰台-望京;七天翻滚表;在线-离线库
  22. 22. 24 2.1 需求:核心库减负(分片)  最终目的:替核心数据库减负,同时降低开发难度  数据冗余:根据读写操作,使用不同的库。【Full-DB】  横向拆分:根据应用拆分多个库。【ShardDB】  纵向拆分:根据数据拆分多个库和多个表。【ShardDB】  需求细分: 【 实际场景千变万化]  后端访问方式: 【暂不考虑NOSQL存储】  基于JDBC的访问【普通SQL/预编译SQL/存储过程】  数据分片策略:  按读写操作的类型【读写分离】  按分片数据库库名【相同库相同表,相同库不同表】  按分片数据库表名【不同库相同表,不同库不同表】  按单个分片字段的类型【整数ID值,字符串DT时间】  按单个分片字段值个数  没有分片字段值(全局) 【全局查询】  单个分片字段值(单条) 【单表查询】  两个分片字段值(范围) 【多表查询】 如何 以不变应万变  按多个分片字段值分片,通过计算产生单一分片关键字【如hash】 ?
  23. 23. 26 2.2 背景:已有中间层技术方案(C+x) 方案1:Mysql-Proxy@MySQL(官方) •特点:官方提供,可通过lua脚本扩展 •功能:负载平衡/读写分离/failover等,不支持大数据量的分库分表,性能较差。 •源码:http://dev.mysql.com/downloads/mysql-proxy/ •参考:https://github.com/drmingdrmer/mysql-proxy-xp/blob/master/lib/rw-splitting. lua •参考:http://bbs.chinaunix.net/thread-1341765-1-1.html 再提mysql-proxy读写 分离脚本(rw-splitting.lua)BUG问题 方案2:Atlas@Qihoo360(王超) •源码:https://github.com/Qihoo360/Atlas •特点:在mysql-proxy-0.8.2版基础上优化,增加若干新特性。 •功能:1.读写分离;2.从库负载均衡;3.IP过滤;4.自动分表;5.DBA可平滑上 下线DB;6.自动摘除宕机的DB; •优势: • 1.将主流程中所有Lua代码用C重写,Lua仅用于管理接口 • 2.重写网络模型、线程模型 • 3.实现了真正意义上的连接池 • 4.优化了锁机制,性能提高数十倍
  24. 24. 27 2.2*背景:已有中间层技术方案(Java) 方案3:Amoeba@盛大(陈思儒) • 源码:http://sourceforge.net/projects/amoeba/ • 文档:http://docs.hexnova.com/amoeba/ • 版本:Amoeba for MySQL/Aladdin/MongoDB • 缺点:不支持事务/存储过程/输出大数据量结果集/分库分表。目前 只做到分DB实例,每个节点需要保持库表结构一致。 方案4:Cobar@AliBaBa(贺贤懋) • 源码:http://code.alibabatech.com/wiki/display/cobar/Home • 缺点:基于amoeba0.34,开源版只支持mysql,不支持读写分离。 方案5:TDDL@Taobao • 源码:https://github.com/alibaba/tb_tddl • 特点:基于JDBC数据源,具主备/读写分离/动态数据库配置等功能。 • TGroupDataSource & TAtomDataSource • 缺点:复杂度相对较高,文档较少,只开源动态数据源,分表分库部 分还未开源,还需要依赖diamond,不推荐使用。 方案6: RDS@阿里云(皓庭/王骞) • DTCC#2013:阿里云分布式RDS平台(柳彦召) • DTCC#2014:淘宝数据库高性能透明分库分表探索(皓庭)DRDS
  25. 25. 28 2.2+背景:已有中间层技术方案(DDB) DDB@网易 王磊@网易杭研院
  26. 26. 29 2.2 背景:已有中间层技术方案(不开源) 方案7:S3@Amazon & SimpleDB@Amazon • 特点:非开源。(S3)基于标准REST和SOAP接口的超级SAN存储。 方案8:DAL@iMobile(许超前@百度) • 特点:非开源。针对PHP页面访问MySQL库。 • 参考: http://cio.it168.com/a2010/0421/876/000000876821.shtml • 优势: • 1) 不但具备了memcached和mysql proxy的优点,还避免了两者的缺点。 • 2) Dal作为一个中间件,应保持语言中立、数据库中立。 • 3) 让系统在数据访问层上具备分布式计算能力。 • 4) 不造ORM轮子,只是发明访问数据的接口。
  27. 27. 30 2.3*背景:解析中间层架构(Java) 1 2 3 4 5  模块组成  网络:JDBC协议解析(MySQL)  解析:{SqlParser | Cobar}  路由:基于{表名+字段值| SQLID}  执行:{SQL | PSQL | CALL}  结果集合并& 排序  访问方式  方案1:SQL/JDBC  使用MySql的JDBC驱动,使用ORM方式不变  方案2:SQLID/自定义协议(CM20|HTTP)  使用自定义通信协议,限制前端接口。
  28. 28. 31 2.4 现状:UDAL介绍  名称:联动优势数据访问层UDAL  结构  UDAL服务器【从产品到平台】  UDAL通用接口协议【HTTP | CM20】  UDAL客户端接口(for Java)  RmoteAPI 【可自定义】  LocalAPI 【~iBatis】  PoGenerator组件【~】  生成PO对象  生成SQL模板  生成SQL分页模板  BS3相关:IoC容器,Dalet扩展
  29. 29. 32 2.4 现状:UDAL演化路线(第5阶段)  第一阶段目标:访问代理  平台中立【DAL服务端,基于Java开发,可部署在多个平台上】  语言中立【DAL客户端,支持多种语言访问(JAVA/PHP/C/Ruby/…)】  厂商中立【支持多个DB厂商;支持多个DB版本;支持NOSQL存储;】  第二阶段目标:服务治理  资源共享【多种连接池,共享连接池;共享缓存(MCached/EhCached)】  权限控制【身份认证,连接管理,访问控制】  访问日志【业务日志,SqlLog,BackLog】  监控优化【性能瓶颈分析和优化】  第三阶段目标:读写分离  读写分离【主从结构,需要额外的DB复制技术】  访问集群【负载均衡:HaProxy】  第四阶段目标:非结构化存储【针对RO/CO/KV/DO的访问】  参考:三备份/NWR模型/多版本/… 【无需额外的复制,使用NWR模型】  支持:Mcache/MongoDB/…  支持:MCache高可用模式【永远可写,永远可读】  第五阶段目标:数据分片  多种执行方式:普通SQL,预编译SQL,存储过程。  多种分片策略:单列|多列,无值|单值|多值,多库&多表  多种扩展方式:Java类扩展,脚本语言扩展。
  30. 30. 33 2.4 现状:UDAL关键技术的选择(简)  1,服务组织风格【RESTful】  2,中间层编程语言【Java vs C/C++】  3,后端存储方式【NO-RDB】  4,前端访问接口【NO-JDBC,NO-SQL】  NO-SQL 【用sqlid/callid替代sql语句】  抛弃复杂的sql语句,解析更容易,执行更安全。  NO-JDBC 【可支持NOSQL存储】  抛弃复杂的jdbc,服务端更容易解析  抛弃复杂的jdbc,客户端更容易使用  还可支持更多的存储方式:1)NOSQL库;2)服务(如Tuxedo)  5,交互协议(传输协议+数据协议)  数据传输协议【HTTP/CM20/…】  序列化技术【java+gz/hessian2+gz/xml/json/…】  结果集表示【List<Map<String,Object>>】  6,负载均衡: 【避免单点】 NO=Not Only
  31. 31. 34 2.4 现状:UDAL软件产品(简) 1 应用逻辑层2 数据访问层(DAL) 1 应用系统 21 NIO网络 协议适配器 22 Dalet引 擎 211 消息头 解析器 212 消息体 解析器 221 资源 分发器 222 操作 映射器 23 Dalet容器 ● Dalet1 ● Dalet2 … http 11表现层 12逻辑层 13持久层 11表现层 12逻辑层 13持久层 http Method+URI 3 数据资源层 2 数据访问服务(1) 1应用系统 2 数据访问服务(2) 21 22 23 HTTP或CM20 JDBC Cache Hadoop Call DB2 MySQL Search APIs APIs 专利201010506543.2数据访问方法及装置
  32. 32. 35 2.4 现状:UDAL服务平台(简)  服务平台= LBL + DAL + IoC + API DAL Remote API 连接池管理序列化和压缩… HTTP 客户端序列化 BSL基础服务平台 Mina2框架 IoService 过 滤 器 链 DB2 BS3框架 —— IoC AOP JMX Log REST AUTH FSM XUMP … Oracle Mysql 过滤器 IoHandler DAL服务器 NIO协议解析器 http/cm20/um32/… 数据访问引擎 DalEngine Dalet扩展 —— Auth PSqlid MCache MCacheAW MCacheNWR … 序列化和压缩 java/hessian/json/…/gz DB连接池管理 c3p0/dbcp/bonecp/… 线程池 协议解析器 … DAL Local API DalEngine Dalets … DB连接池管理 中间件 —— Tuxedo CICS
  33. 33. 36 2.4 现状:UDAL全局地位(简) 负载均衡层 CDN 区域负载 (可选) F5/LVS +Nginx/ Haproxy Web前置集群综合前置FSL 异 步 订阅 同 步 服务层缓存层持久层 综合前置 FSL 通知和反馈SMS,Email,IM,… Memcached + Membase 二级缓存 应用切分 水平切分 垂直切分 读写分离 双主多从 F5/LVS +Nginx/ Haproxy 主备机制 JMS Camel 通过DAL访问 NOSQL DB Hadoop / HBase … NameNode2 复制 Master DB (行式)在线交易库 Master / Slave,分片,集群 DataNodes 同NameNode1 步 异 步 页面缓存 Squid Varnish OSCache 静态资源 合作机构 银行 移动 商户 分布式服务集群 应用服务:ASL 基础服务:BSL 数据访问:DAL 监控服务定时服务:TSL 集群 … 读 (列式)离线分析库 写 读… 复 制 Slave DB
  34. 34. 37 3 论Jdbc4udal方案的技术可行性 1. 需求分析(数据库集群访问中间层) 2. 现有DAL中间层技术介绍 3. 技术可行性分析(Jdbc4udal方案)  问题  分析  对比  结论(?)
  35. 35. 38 3.1*问题:使用UDAL并兼任现有开发模式  服务端问题:给核心数据库减负  数据库需要重构:纵向拆分|横向分片|版本升级|MyQql|…  应用端改动太多  需要一个中间层  引入UDAL服务层  客户端问题:   应用端改动太大 问:怎样使用UDAL并能兼任现有开发模式?
  36. 36. 39 3.2*分析:访问UDAL服务的几种方式  方案1:直接调用BS3中API接口  DalApi4Inf api = DalClientFactory.newRemoteApi (…);  方案2:自定义封装协议接口( CM20|HTTP)  例:Php4Dal  方案3:封装Jdbc4udal驱动  服务端:提供固定服务地址,解 析动态SQL来实现分片。  客户端:已有应用系统不用改动 ,可使用任意ORM框架。 (读+写)混合操作只读操作只写操作 iBatis DAO iBatis+X Jdbc4udal DAO DalApi 中间层1(Amazon,手机之家 , DalServer) 中间层2(Mysql-Proxy, Atlas,Amoeba,Cobar, TDDL) MySQL,DB2,Oracle,… NOSQL
  37. 37. 40 3.3*分析:方案Jdbc4udal目标 1、屏蔽数据库差异,换数据库时应用不需要修改。  DB2 改MySQL 【问题:sql编译顺序不一,需要重新优化】 2、屏蔽分表规则。order_0,1,2改成order_0,1,2,3,4,5,6时,应用不需要修改 多单表查询:解析表名、字段值(单值,值范围,Between,IN) 表关联:单表分片,多表分片一致,分片字段类似,多表分片规则不一致。  重点:不支持跨库JOIN 3、平滑迁移  限指客户端开发模式的迁移(jdbc->dal),方便回退。 4、节省数据库连接,不为每个应用分配独立DB连接,各应用公用DB连接。  支持 5、支持横向扩展 (1)服务端支持集群,能够配置任意数目服务器。 支持:多个DAL服务。 (2)支持数据库集群,可以实现读库和写库分离。 支持: 补充:
  38. 38. 3.3*分析:方案Jdbc4udal当前问题 1、如何实现实表向虚表的过渡,实表、虚表是由应用端传送一个标志来区分还 是由服务器端自行适配? 41  修改iBatis配置中的Table名。【存储过程方式?】  必须能从名字上区分(_V_前缀):虚表_V_Schema.Tablename 2、c3p0连接池在管理改动后的Connection是否存在问题?  Connection有效性校验。  Commit,Rollback,Close,Open 3、dal如何支持事务?  不支持!  同时提交多条SQL到服务端,由服务端按事务执行。 4、dal需要定制出execute、executeQuery、executeUpdate三类服务;  executeQuery = GET URI 【在写库读?——】  executeUpdate = PUT URI 【在读库写?——全部更新,插入】  多个DataSource(在线库!=写库)【通过URI?db=online区分】 5、dal对不同数据库特有函数的支持;  用sqlparser替代cobar解析SQL,需要验证测试(殷舒) 6、如何将dal返回的数据转换成jdbc的类型?  (冗余操作:Map转JDBC结果集,然后再次转Map或Bean)
  39. 39. 42 3.3*分析:方案Jdbc4udal的优缺点  方案3:封装Jdbc4udal驱动  技术可行性  服务端:提供固定服务地址,解析动态SQL来实现分片。  客户端:已有应用系统不用改动,可使用任意ORM框架。  技术风险点  层次增加:  Args -> SQL -> URI -> 解析SQL -> 解析表和字段  隐含陷阱:  特殊SQL  原有Cobar解析不支持,改sqlparser,需验证  大数据集 不支持该模式:用dalet直接生成文件后http下载。  多表JOIN   多表分片
  40. 40. 43 3.3*分析:解析SQL时的问题  可解析部分(MySql)  操作语句:insert/delete/update/select  条件判断:>,<,=, <>,in,between,join,exists  解析不成功:  函数  解析后误判  例1:解析正常,有变形。  输入:SELECT * FROM tbl0 WHERE 1=1 limit 10,5  输出:SELECT * FROM tbl0 WHERE 1 = 1 LIMIT 5 OFFSET 10  输入:SELECT fields INTO tbl2 FROM tbl0 WHERE 1=1  输出:SELECT fields FROM tbl0 WHERE 1 = 1  例2:解析异常(net.sf.jsqlparser.parser.ParseException)  输入:SELECT * FROM products WHERE id='3' FOR UPDATE  异常:ParseException: Encountered " "FOR" "for "" at line 1, column 23.  输入:SELECT * FROM products LOCK IN SHARE MODE  异常:ParseException: Encountered " "IN" "IN "" at line 1, column 29.
  41. 41. 44 3.3+分析:状态性  如何保持状态  DB中保持  前后端连接一致  DAL中保持  DAL服务器缓存  Client端保持  客户端缓存,批次提交。
  42. 42.  三种方案的差异 45 3.4*对比:方案对比1(刘胜) 方案JDBC UDAL Jdbc4udal 备注 状态有状态无状态去状态状态C/S/DB保持 登录方式独立登录过程无需预先登录独立登录过程 大结果集支持不支持去大结果集服务端生成文件 事务支持客户端事务服务端事务? 参数Sql/psql/call sqlid + args sql 类“存储过程” 分片无按sqlid 按表名+字段 客户端ORM RPC ORM/ibatis 动态sql 由Ibatis支持缺省参数方式由Ibatis支持 迁移环节APP代码改动多APP容易迁移 测试环节按APP测试按APP测试 中间环节少中多
  43. 43. 46 3.4*对比:方案对比2(殷舒) 对比项服务端配置SQL SQL解析 支持动态sql 支持sql语句场景 支持单库两分片表关联 网络流量大小 数据操作事前监控 数据操作事后监控 服务端配置分片规则需要需要 服务端配置sql 需要不需要
  44. 44. 47 3.5 结论(?) 1. 三种方案的差异
  45. 45. 48 8+问答1(任)现场问题及简要答复 对方问题: 1,关于jdbc4udal驱动,希望有产品或明确的开发计划。——答复:暂无计划。也担心 实现后效果不佳,无法达到预期的“透明”效果。如有强烈需求,也可先做一些探 索性预研。 2,希望支持分布式事务,有难度也想要做,可承担一定代价。——答复:本公司无此应 用场景。如有需要,可自定义dalet扩展,通过JTA实现。 3,关于跨地域/跨机房的场景。——答复:本公司无此应用场景。如有需要,也可从两个 层面来支持:1)服务层,可通过负载均衡器或服务查找模式,实现快速动态切换。 2)远程JDBC数据源:如果是镜像库模式,也可使用LVS负载均衡器、动态DNS等 方式,实现快速动态切换。【但是,数据复制的延时,由DB复制工具和网络状况决 定,与DAL层无直接关系。】 4,合作模式,希望能够采用合作开发的模式。——另行商定。 我方问题: 5,具体应用场景(高可读、高可写、读写混合、分库、强一致的分布式事务)——暂不 明确,可能都需要覆盖。稍后会整理一个详细的需求列表(包含应用场景),需我 司针对其需求做出明确的答复。
  46. 46. 49 8+问答2(秦)数据备份和灾备  1,贵公司在物理部署上是否支持同城多点和异地多点?我看您的ppt里提到 了丰台与望京,这是北京2个平等的中心吗?丰台、望京是根据什么策略引导 用户访问的(如访问分配比例、DNS域名动态解析引导等)? 异地多点有无相 同引导策略?  2,是否存在同城(丰台-望京)数据备份、容灾考虑,实际的容灾设计方案是 什么样子的,RTO,RPO是多少? 异地容灾有无相同策略? 答复见邮件“关于贵公司数据备份 ,灾备咨询”
  47. 47. 50 8+问答3(任)技术需求概述  第2 章应用数据访问需求  1.生产数据库服务器均采用PC Server,支持Oracle数据库。  2.需要支持数据部署在不同地域的数据中心,跨不同地域数据中心的读写情况,保障异地数据读写的执行效率。  3.基于JDBC规范,支持实现JDBC规范的数据源,数据访问对上层应用调用透明,开发整体采用Java语言。  4.支持主流ORM框架下的透明分布式数据访问开发,如:iBatis、Hibernate等。  5.支持带有权重的读写分离模式。  6.数据库读写库的动态切换。  7.支持读写次数、并发度控制。  8.数据库实例个数发生动态变更时,可以保障旧应用数据不发生迁移,新数据分布于新数据库中。  9.支持SQL解析,需要考虑Oracle中的语法。  10.数据库路由,数据库路由策略依照应用制定的策略完成;如是否可以跨库联表查询、能否跨库使用聚合函数、可以select ...for update等。  11.数据分页、查询结果数据合并和排序等。  12.集中式数据源信息管理和动态变更。  13.具备运行情况监控与分析功能。  第3 章数据备份及同步需求  1.数据库的本地、异地数据同步方案,数据同步需考虑不同表、不同规则的定制,需考虑数据在本异地同步下的延时。  2.提供数据在异地IDC的备份策略,发生灾难时数据的恢复策略。  3.数据库日常管理过程中,数据维护、迁移和管理的工具。  第4 章分布式事务控制需求  1.同一数据中心不同数据库间分布式事务控制方案。  2.异地数据中心不同数据库间分布式事务控制方案。 答复见文档『20140418联动优势数据访 问层DAL架构-技术需求概述(任)_答复( 刘胜).doc』  3.分布式事务控制对上层应用需要尽量避免影响考虑失败情况的应对支持等。
  48. 48. 51 9+参考索引  网址  http://coolshell.cn/articles/10910.html 分布式系统的事务处理(陈皓 )2014年1月20日发表  其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者 Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算 法都是残次品。  Slideshare.net  http://www.slideshare.net/guestf5121c/ss-2334825 手机之家的数 据访问层实践(许超前)  http://www.slideshare.net/xcq/ss-3629618 数据访问层开发实践  http://www.slideshare.net/nikeliu/20120613dal4 20120613数据 访问层DAL架构和实践4(刘胜)新的特性.pptx  http://www.slideshare.net/nikeliu/20130626dal51-h 20130626数 据访问层DAL架构和实践5(刘胜)数据分片.pptx
  49. 49. 52 Q9& 结A语:Q&A  现场问题——?  1,?  2,?  3,?  4,?  5,?  思考题——  1,?  2,?  3,?
  50. 50. 53 9 总结:相关培训  20081113大型分布式系统架构技术简介(刘胜)中级.pdf  20081211大型软件系统开发综述(刘胜)中级.pdf /.mm/.png  20090219网络信息安全和认证技术(刘胜)中级.pdf  20090625服务器框架的概念和实践(刘胜)20121204.ppt  20090625分布式认证和授权技术(刘胜)初级.ppt  20090914系统架构师2009大会归来(刘胜)暨头脑风暴.ppt  20091224数据访问层DAL概念和实践1(刘胜).ppt  20100326数据访问层DAL概念和实践2(刘胜).ppt  20100902数据访问层DAL架构和实践3(刘胜).ppt  20101217软件技术大会和JavaOne大会归来(刘胜).ppt  20110223高可用可扩展的负载均衡层(卢翔,刘胜).ppt  20110801应用监控系统架构实践(刘胜).ppt  20120613数据访问层DAL架构和实践4(刘胜).pptx  20121012联动优势技术大会(刘胜)三年技术规划v1.3.4.pptx  20121013联动技术框架能力发布-BS3&DAL(殷舒).pptx  20121218联动优势技术平台介绍(for漫道科技)v5.pptx  20130326号码集合的存储和访问方法兼谈专利申请(刘胜).pptx  20130521联动优势企业架构介绍(刘胜).pptx  20130325理解REST设计模式和反模式(刘胜)草案.pptx

×