进程外代理即将代理独立成服务，代理真实业务服务和数据库之间的请求。这样是比较复杂的，需要高可用的代理服务架构。但是这样对业务的侵入性低，且易于升级扩展。
问题 分布式事务问题什么是分布式事务？本地事务的定义就是一系列相关的数据库操作完成后要满足 ACID 四大特性，而分布式事务就是将同一进程的操作放到不同的微服务进程中，即不同微服务应用进程的数据库操作满足事务要求，或者对不同数据库的一系列操作需满足事务要求。
这里就有两个问题需要解决。一个是因为应用的分布式造成的，一个是因为数据库本身的分布式造成的。数据库本身的分布式事务问题一般由数据库自身解决，大多数分布式数据库都可以做到一定的数据一致性保证，如 HBase 保证的强一致性，Cassandra 保证的最终一致性。
应用数据的一致性事务方案我们也可以参考分布式数据库的实现原理来实现。业界也有很多分布式事务的解决思路，如：
XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
多表 Join 问题通过分析 Join sql，将 sql 拆分成独立的查询请求，然后分别执行，并将结果合并计算返回给调用者。这个地方会涉及到很多执行优化的问题。
数据统计问题当数据被分片到不同的数据库或不同的表中时，要对数据做一些全局的或涉及大量数据的统计时便会遇到一些问题。如求 Max，Min，Sum 等聚合问题。如果统计的数据有一定的业务规则，如只会按用户维度去统计，如统计某个用户的订单量，那么对订单表的分片，其实可以采用按用户 id 来分片，如此就可以解决这类统计问题。但是这种方案不通用。很多分片代理服务都需要将 sql 分片到不同的节点上去执行，然后再合并结果返回。
ID 问题使用分库分表之后，就无法使用 Mysql 的表自增作为 id，因为不同库和表的自增将出现冲突的 id。解决这个问题就需要引入分布式 id 生成技术（将在以后的文章中讲到）。