后端架构中业务层容错设计的数据完整性问题

　　互联网应用业务需求迭代更新速度快，业务层代码经常性变动，导致代码质量变差，另外应用版本发布周期也短，因此除了完整的测试体系之外，在后端架构业务逻辑层中，容错设计对鲁棒性和问题的快速修复都至关重要。B/S应用也好，C/S应用也好，处理好这个问题高可用及快速发布都有保证。
　　业务逻辑层实现较多使用的高级语言例如Java，Python，PHP，ECMAScript系列，都会在发生错误的时候抛出各种异常，然后程序就会在出错点终止，通常可以通过这些语言提供的异常捕获机制处理出错，确保进程继续运行，接受新的业务调用请求，C/C++在这个问题上有点悲剧。
　　在一个业务调用执行过程中，一段顺序执行的逻辑代码，一般来说各行都可能存在着对全局数据的操作，例如数据库写操作，或者进程内全局变量更新操作，如果这段代码执行到一半出错而抛出异常终止（经常可能发生的事），但由于业务进程容错，进程会继续运行不会受到影响，只是这段代码原来设计改变的数据可能只修改了部分，另外出错点后面的数据没有修改到，于是产生了业务数据完整性的问题，这不是关系型数据库的数据引用完整性问题，你没法完全通过设计良好的完整引用来排除，因此这种问题是经常存在的。
　　通常来说，对于这种问题，我们可以这样解决，通过对逻辑代码修复，同时分析对生产数据的影响，然后同步进行修复；另外一种方法是在该段代码开始执行时就启用数据库事务，出错时直接rollback，如果你使用的是关系型数据库的话，比较大杀器。
　　分析这两种方法，第一种方法来说加重了修复的工作量和时间，要求也比较高，另外取决于应用的设计，对一个线上应用来说该问题也可能已经照成了难以预料的连带错误；第二种办法解决得比较彻底，但是启用事务会大大影响数据库服务器的并发效率，另外目前流行的NoSQL数据库对事务的支持比较糟糕。
　　那么如何更好的解决容错设计下的数据完整性这种问题呢？
　　我的想法是可以参照关系型数据库的事务机制在业务逻辑层实现自己的写调用延迟，分离逻辑代码和数据写调用（数据读调用无需关心）。
这样的架构下，业务代码出错不会影响到全局数据，执行成功则最后将写调用提交执行，如果执行失败则可以删除写调用记录，相当于事务rollback，该业务的调用对外部来说跟没发生过一样；通过适当的封装，在编写业务代码时也无太大的区别，不会带来代码上的习惯转变问题。
该实现带来的好处是调用抛出异常终止时无需再关心数据完整性的修复问题，只需要修复相应的业务代码即可，当然这只是针对本地的调用，对于存在于本地业务逻辑中的RPC则显式两阶段提交是不可避免的，不在考虑范围。
　　我已经在自己的服务端架构中实现了该想法。将继续测试。