基于阿里的云P层的开发模式.pptxVIP

『时 间』 2014.01 基于阿里云P层的开发模式变化 CRM云技术架构－阿里P层可支持 2 客户原子服务 用户原子服务 SLB（软负载均衡器） WEB应用 ESB XX原子服务 资源原子服务 资源域 数据 访问 分布式缓存 批量加载 缓存更新 数据 访问 缓存 数据 访问 产品原子服务 产品域 批量加载 缓存更新 数据 访问 缓存 数据 访问 订单原子服务 订单域 数据 访问 缓存 数据 访问 公共 公共域 数据 访问 缓存 数据 访问 文件 访问 数据存储 后端服务 前端应用 数据 访问 组合服务1 组合服务2 组合服务N 分布式缓存 分布式缓存 分布式缓存 实时加载 WEB应用 WEB应用 WEB应用 …… 消息中间件 分布式文件系统 阿里P层的技术架构 3 TDDL TDDL 应用层云化-用阿里的TDDL、Tair 缓存＋关系数据库配合使用模式 批量加载 缓存更新 产品原子服务 产品原子服务 …… 数据查询 新数据保存 新数据保存 CRUD CRUD CRUD CRUD …… 客户资料认证应用 WEB应用 前端 应用 组合 服务 原子 服务 数据 存储 …… 原子服务层 组合服务层 应用层云化-用阿里的Notify异步 同步＋异步配合使用模式 CRUD CRUD …… WEB应用 WEB应用 …… 6 采集 DCC-PROXY OSS文件读写 OTS查重/账详单读写 MYSQL数据库读写 NOTIFY异步消息访问 TAIR内存缓存访问 APPNAME 应用集群 基于阿里的应用改造点－数据库层面 原数据库附加能力被禁用 存储过程、视图、自定义函数或过程、触发器、sequence等；聚合函数 数据的强一致性被丢弃了：去外键、加冗余 复杂sql被禁用 复杂SQL拆分为简单SQL应用多次调用 强一致性事务分布式环境下变成异步的了、并且是由应用来控制 Notify消息中间件 状态机 7 基于阿里的应用改造点－应用层面 原数据库的事现在由应用来干 数据库附加能力、事务、聚合、排序 大表join得拆开干 引入消息中间件notify的副作用应用得摆平 消息没有顺序了 消息发重复了也不知道 得增加很多技术类异常处理 需要剔重、异常需要进行补偿 8 阿里平台优缺点 优点 产品体系比较完整 用消息机制完成分布式事务是一种创新 互联网思维（技术角度）执行比较到位 能力不足堆机器 快速迭代 9 阿里平台优缺点 缺点 数据方面 强一致性被打破，而这恰是电信业务数据要保证的。数据一致性稽核。 数据库附加能力的减少，导致系统很难平移过来，应用大部分要重写（除上层服务不用改之外，底层的跟数据库打交道的都要改，至少60％）。存储过程、function等。 SQL：Join的限制、Like不支持、聚合函数等 数据汇总能力不强 引入冗余表，应用对冗余表的操作难度增加了 对数据的维护难度加大了 10 阿里平台优缺点 缺点 应用层面 分布式事务得应用控制，工作量加大了。 各种异常的补偿机制得考虑周全。 出现问题后，查找原因变得很复杂、很麻烦 消息中间件的重复、无顺序投递问题得应用解决 业务远比阿里、淘宝复杂，是否能顺利支撑未深入验证过 对单笔业务时间有较苛刻要求的业务，在云上遇到阻碍 每个产品都有一些不适应 11 产品平台－ESB产品 12 能力 阿里产品（HSF/Dubblo） 我们（ESB） 服务注册与发布 采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，使用zookeeper注册中心进行服务的自动注册与发布。通过管理控制台对服务进行治理。 通过esbAdmin页面注册服务，并将注册服务内容保存到数据库中。启动时esbWS进行服务自动发布。 协议支持 Webservice、Hessian、dubbo、rmi、http、thrift；不同服务不同协议；同一服务多协议暴露 Webservice、rest 负载均衡 软件负载均衡：采用基本于配置中心订阅推送，客户端软负载，容灾、失效恢复，路由等规则支持。 软负载、硬件负载均支持 路由 通过控制台配置。路由规则： 接口路由， 方法路由，参数路由。选址算法：随机，权重。 通过硬编码实现 异步调用 并行发起多个请求，但只使用一个线程：基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。 通过硬编码实现 事件通知 在调用之前，调用之后，出现异常时，会触发oninvoke, onreturn, onthrow三个事件，可以配置当事件发生时，通知哪个类的哪个方法。 不支持 产品平台－分布式数据库能力 13 能力 TDDL 思特奇-分布式数据库 架构 1.采用组件形式和应用集成 2.支持spring和i