共计 1491 个字符，预计需要花费 4 分钟才能阅读完成。
当我们在谈去 ioe 时候，一定会带来的一个问题就是单节点本身的计算或存储能力不足而导致的数据水平或垂直切分，那在 数据切分 后如何解决这些问题就成为一个好的 daas 层能否真正发挥作用的重点。
对于分布式事务的问题，前面已经谈了很多，对于一个 daas 下针对逻辑库（一个逻辑库下面存在多个物理库节点）是可以通过标准的 xa 两阶段提交协议来实现分布式事务的，但是本身不仅仅是可靠性的问题，更加关键的是性能问题，特别是在高并发下的性能问题。因此在应用实现的过程中还是需要尽量避免使用分布式事务，仅仅在需要使用分布式事务的少数特殊场景通过显性声明的方式使用分布式事务。对于能够采用事务最终一致性 base 的场景，尽量是结合消息中间件的能力，采用最终一致性的方式；对于不能接受最终一致性的场景尽量采用事务补偿的方式来弥补事务失败造成的影响。
在数据拆分有原有的一个单库多表关联查询操作，往往会转变为一个跨库的 join 查询操作，而现在的针对 mysql 的 daas 方案很难真正的支撑到这种类型的操作，即使能够支持估计也很难真正达到一个高性能。在我们原来的设想中这些问题都简单的转化为应用层去解决，这务必是增加了一个应用层开发的复杂度和难度。而针对这种情况最好的方法是构建一个统一的领域服务层来解决，即最终的上层或顶层是关注的领域服务能力，虽然跨库的问题在 daas 层很难解决，但是在领域服务层却比较容易定制开发相应的服务来解决。
举例来说，一个采购订单查询，采购订单头和明细信息在一个逻辑库，而对于物料和供应商主数据在另外一个物理库，但是对于应用来说关注的是一个完整的采购订单信息。因此完全是可以在领域服务层提供一个采购订单查询的服务，在服务内部进行多次的 daas 层服务调用和组装来完成内部的复杂性。这也是我们常说的，但进行数据库拆分后，务必需要引入更加强壮的领域服务层的原因。
在数据拆分后还有一个比较难以解决的问题，即是对于业务系统的大量查询分析和统计功能的处理，由于我们的数据库进行了切分，导致这些功能已经类似于传统 bi 里面的 olap 层的功能特性。对于这种业务场景和需求，往往并没有完全的实时性需求，我们能够满足准实时性就可以了。因此对于这类功能推荐的方法仍然是需要将当前的各个分库里面的数据整合到 newsql 数据库里面进行处理（hive，infobright，impala)等，这些数据库需要满足的特性就是 mpp share nothing 架构特性，在这种架构下可以看到对于海量数据的分析和统计可以保证业务需要的准实时性要求，唯一需要考虑的是当前很多的 newsql 数据库都是一个读库，很难进行 cud 等各种操作，因此转化后需要解决的问题就是对于业务库中的增量数据如何实时的更新到 newsql 数据库里面，注意是增量更新而不是类似当前很多方案里面的全库重新导入和生成，这也是在解决查询统计功能的一个难点。
对于 mysql 的读写分离集群我们看到，随着 slave 节点的增加，为了保证 master 和 slave 节点之间的一致性，将会出现明细的延迟，也直接影响到应用 cud 操作的性能。对于这个问题，当前可以考虑的亚博电竞官方网址的解决方案就是要拆分为两级的读写分离集群，对于第一级的读节点保证高一致性和性能，对于第二级允许有较大的延迟，仅仅用于查询分析等。
在最近的一年过程中，我们对基于 mysql 的 daas 层产品逐步的改进和完善，包括分布式事务，ddl 操作，函数和存储过程支持，多租户和资源隔离，子查询，底层多种数据库适配和支持等做了大量的改进和性能测试。已经基本形成一个可以在实际业务中应用的产品，同时该产品也开始应用到我们自研的 esb 服务总线中。