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

1、时 间 2014.012客户原子服务用户原子服务SLB（软负载均衡器）WEB应用ESBXX原子服务资源原子服务资源域数据访问分布式缓存批量加载缓存更新数据访问缓存数据访问产品原子服务产品域批量加载缓存更新数据访问缓存数据访问订单原子服务订单域数据访问缓存数据访问公共公共域数据访问缓存数据访问文件访问数据存储后端服务前端应用数据访问组合服务1组合服务2组合服务N客户域客户域用户域用户域分布式缓存分布式缓存分布式缓存实时加载WEB应用WEB应用WEB应用消息中间件分布式文件系统3TDDLTDDL 缓存关系数据库配合使用模式批量加载缓存更新公共表产品域产品表订单域订单表资源域号码主表号码维度表用户域

2、用户主表用户维度表客户域客户主表客户维度表TAIR分布式缓存产品原子服务产品原子服务数据查询新数据保存新数据保存订单原子服务订单原子服务CRUDCRUD客户原子服务TDDL客户原子服务用户原子服务TDDL用户原子服务客户资料认证服务CRUDCRUD客户资料认证应用WEB应用前端应用组合服务原子服务数据存储组装服务原子服务层组合服务层 同步异步配合使用模式资源域号码主表号码维度表用户域用户主表用户维度表客户域客户主表客户维度表客户原子服务TDDL客户原子服务用户原子服务TDDL用户原子服务组装服务CRUDCRUDWEB应用Notify异步消息mqMq等TDDL资源原子服务X组装服务TAIR分布式

3、缓存WEB应用组装服务6采集DCC-PROXYOTS集群查重数据OSS集群原始话单标准话单NOTIFY集群话单消息余额变更消息账单变更消息开停机消息费用变更消息SLB集群计费消息OTS集群历史详单数据历史账单数据详单入库账单变更余额变更预处理批价累帐信用控制会话管理/批价扣费周期费计算月结优惠批量销账缴费充值详帐单查询MYSQL集群累积量集群账本余额集群实时账单集群会话信息集群TAIR集群会话信息集群用户资料集群MYSQL集群在线账单集群出账余额集群出账账单集群在线详单集群NOTIFY消息集群用户资料集群实时优惠实时账单变更DRC资料同步OSS文件读写OTS查重/账详单读写MYSQL数据库读写

4、NOTIFY异步消息访问TAIR内存缓存访问APPNAME应用集群 原数据库附加能力被禁用 存储过程、视图、自定义函数或过程、触发器、sequence等；聚合函数 数据的强一致性被丢弃了：去外键、加冗余 复杂sql被禁用 复杂SQL拆分为简单SQL应用多次调用 强一致性事务分布式环境下变成异步的了、并且是由应用来控制 Notify消息中间件 状态机7 原数据库的事现在由应用来干 数据库附加能力、事务、聚合、排序 大表join得拆开干 引入消息中间件notify的副作用应用得摆平 消息没有顺序了 消息发重复了也不知道 得增加很多技术类异常处理 需要剔重、异常需要进行补偿8 优点 产品体系比较完整

5、 用消息机制完成分布式事务是一种创新 互联网思维（技术角度）执行比较到位 能力不足堆机器 快速迭代9 缺点 数据方面 强一致性被打破，而这恰是电信业务数据要保证的。数据一致性稽核。 数据库附加能力的减少，导致系统很难平移过来，应用大部分要重写（除上层服务不用改之外，底层的跟数据库打交道的都要改，至少60）。存储过程、function等。 SQL：Join的限制、Like不支持、聚合函数等 数据汇总能力不强 引入冗余表，应用对冗余表的操作难度增加了 对数据的维护难度加大了10 缺点 应用层面 分布式事务得应用控制，工作量加大了。 各种异常的补偿机制得考虑周全。 出现问题后，查找原因变得很复杂、很

6、麻烦 消息中间件的重复、无顺序投递问题得应用解决 业务远比阿里、淘宝复杂，是否能顺利支撑未深入验证过 对单笔业务时间有较苛刻要求的业务，在云上遇到阻碍 每个产品都有一些不适应1112能力能力阿里产品（阿里产品（HSF/Dubblo）我们（我们（ESB）服务注册服务注册与发布与发布采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，使用zookeeper注册中心进行服务的自动注册与发布。通过管理控制台对服务进行治理。通过esbAdmin页面注册服务，并将注册服务内容保存到数据库中。启动时esbWS进行服务自动发布。协议支持协议支持We

7、bservice、Hessian、dubbo、rmi、http、thrift；不同服务不同协议；同一服务多协议暴露Webservice、rest负载均衡负载均衡软件负载均衡：采用基本于配置中心订阅推送，客户端软负载，容灾、失效恢复，路由等规则支持。软负载、硬件负载均支持路由路由通过控制台配置。路由规则： 接口路由， 方法路由，参数路由。选址算法：随机，权重。通过硬编码实现异步调用异步调用并行发起多个请求，但只使用一个线程：基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。通过硬编码实现事件通知事件通知在调用之前，调用之后，出现异常时，会触发

8、oninvoke, onreturn, onthrow三个事件，可以配置当事件发生时，通知哪个类的哪个方法。不支持13能力能力TDDLTDDL思特奇思特奇- -分布式数据库分布式数据库 架构架构1.采用组件形式和应用集成2.支持spring和ibatise两种框架1,采用代理中间件方式，需要一定的内存空间转存临时数据2。支持所有mysql协议连接和应用无关功功能能读写分离读写分离先进行数据源选择，再进行读写分离和负载均衡先进行读写分离判断，在进行具体数据源的选择垂直水平切分垂直水平切分垂直只能通过应用自己选择不同的数据源，水平不能动态变更垂直水平能够动态变更生效存储过程存储过程不支持支持存储过

9、程、function等负载均衡负载均衡支持按照权重发送，但有故障时需要程序重新建立连接支持，按照在线节点进行负载均衡，不支持权重配置事务处理事务处理不支持支持，XA分布式事务嵌套查询路由嵌套查询路由不支持支持DQL查询查询支持支持结果集合并结果集合并不支持，每次只向一个节点发送请求。支持结果集合并。多节点发送多节点发送不支持，每次只向一个节点发送请求。支持，能够进行数据冗余处理开发复杂度开发复杂度难，程序需要将切分规则写到程序中，很多数据源要先定义好一般，用户不用关系具体的业务规则，可以在开发完毕后配置切分规则配置管理配置管理支持，主要对数据源管理支持，有自己的管理界面，能够灵活对接点进行配置

10、监控管理监控管理不支持支持，能够查看各个节点的运行情况扩展性扩展性不支持，需要重新调整代码实现能够灵活扩展，增加节点高可用性高可用性不支持，用户在异常时需要重新建立连接然后再进行切库操作，可以设置尝试次数支持，能够通过心跳检测规避离线节点。容灾机制容灾机制支持配置中心管理规则，直接和应用集成部署支持通过配置中心管理规则，支持代理HA部署，主节点出现故障可以切换到从节点点14能力能力阿里产品（阿里产品（Notify/MetaQ）思特奇（消息中间件）思特奇（消息中间件）分布式事务支持支持消息顺序Notify不支持；metaQ支持支持消息模型Notify push；metaQ pullpush主题分

11、区支持支持消息存储Notify mysql/file;metaQ myql/file分布式mysql数据库流量控制支持支持最终一致（check）notify支持；metaQ3.0支持支持主备双写notify支持；metaQ3.0支持支持集群化（云）生产者、消费者、broker均集群生产者,消费者,broker均集群非阻塞通讯（NIO） 支持支持15能力能力阿里产品（阿里产品（Tair）思特奇（分布式缓存）思特奇（分布式缓存）扩展性支持，自我管理不支持在线增减节点集群支持，自我管理支持，外加代理方式持久化两种：内存，本地持久化两种：内存，分布式文件系统持久化读写性能高高可靠性高高容错支持支持，定时快照缓存类型Key/value，bytesKey/value，数据结构丰富，string,list