谈拆库后的应用开发模式

该篇文章接上篇，即基于数据不多点复杂下，基于SID共享数据服务模式下的应用开发。



在这里以采购订单的创建和查询场景为例进行说明，为了简化模型，具体说明如下：

SID库：存储供应商信息，物料信息，数据字典信息，人员组织信息，SID库为纯读库。
采购模块私有库：存储采购订单头，采购订单行信息。

基于以上简单的数据存储模型，那么具体的采购订单创建流程说明如下：

a.进入创建界面后的初始化，直接取Session信息，当然Session信息应该在一登录掉SID库人员，权限初始化
b.订单头选择供应商-直接查询SID库供应商查询服务，获取供应商ID，名称和关键熟悉信息。
c.采购订单类型，付款方式等：直接查询SID库，在第一次查询后该部分数据直接进行缓存，不再重复调用
d.录入订单明细的时候，选择物料调用SID库物料信息查询服务，取回物料ID和相关属性信息。
e.订单保存时候，直接调用ADB库自己的保存方法，和SID库不再有关系。

基于确定的一张采购订单的订单查看界面说明如下

a.从本地ADB库获取到订单头和订单明细信息。
b.根据订单头中的供应商ID信息，查询SID库供应商查询服务，获取供应商名称和其它属性。
c.根据订单头中订单类型，付款方式的ID信息查询数据字典服务，获取显示值信息，或者直接从缓存获取
d.对于订单明细查看，注意一般是分页查询操作，具体如下
    d.1 对当前页显示的订单明细条目的物料ID信息进行组合，形成字符串
    d.2 根据组合字符串，调用物料信息查询服务，获取所有的相关物料的属性信息集合
    d.3 逻辑层进一步组合，将返回的详细物料属性和订单明细属性组合现实到订单明细表格

可以看到在SID库不通过数据复制到本地，调用服务方式仍然是比较容易实现的。在这种模式下，传统实现中在一个大库中简单的关联查询结果集操作，将转换为应用逻辑层多次调用后的组装。这个带来了一定在应用开发中的工作量，但是总体问题并不大。只要不出现在分库后出现的业务模块操作需要跨库的CUD操作，即不会带来分布式事务的场景和问题。

关于分布式事务的处理

基于上面的业务，考虑一个最简单的分布式事务场景，即在最终订单生效的时候，一方面是更新订单的生效状态，一方面是需要朝配送模块触发生成一张配送单，在这里涉及到CUD的跨库操作。对于这种场景，个人建议是能够用BASE模式解决的尽量用BASE模式解决。具体如下：

a.更加订单最终生效状态，同时发送生成配送单消息（可以是本地的临时队列表以避免分布式事务），消息发送基于消息中间件模式，只需发送到MQ即可。
b.消息中间件对接收到的消息进行处理和分发，如果失败的话进行重试。
c.如果多次失败，则需要进行手工处理或手工对订单进行回滚。在这里关键是思考除非出现技术故障，否则不可能出现配送单无法发送成功和生成出来的可能。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密