为什么要 讨论 SOA 呢 ？
请参考我写的另一篇文章 《论 微服务 和 Entity Framework 对 数据 的 割裂》 https://www.cnblogs.com/KSongKing/p/10124126.html
我们来 看看 SOA 的 架构图 ：
可以看到， 在 BL 上 套一层 Remote Facade（远程外观）， 就成为了 Service（服务），
实质就是， BL = Service = 业务， 服务 只是 将 业务 发布 出来， 使得 其它 应用程序 可以访问 。
大家可以 对比 看看 ， 微服务 和 SOA ， 有什么 不同 呢 ？
服务 间 的 事务（Transaction）， 是一个 经典 的 问题 。
也是 一个 首要 的 问题 。
比如， 一个业务 里 更新了 本身的 数据库， 又 调用了 A 服务， B 服务，
如果 A 服务 成功， B 服务 失败， 则 A 服务 应该“回滚”（Rollback），
解决的 办法 是， 每个服务应该 提供一个 对应的 “取消”（Cancel）服务， 比如 A() 服务 应该对应有一个 ACancel() 服务，
B() 服务 应该对应有一个 BCancel() 服务，
这样， 在 业务失败 时， 可以调用 ACancel() 服务 来 “撤销” A() 服务 造成 的 更改 。
为什么要说 “撤销”， 而不说 “回滚” 呢 ？
回滚 意味着 数据 恢复到 更新前 的 状态 ， 在 服务 的 层面， 这通常很难做到 。
在 服务 的 层面， 按 业务 的 意义 进行 “撤销” 会 更合适 。
比如 ， 我 申请 了 一张表单， 可以 撤回表单； 下了一个 订单， 可以 撤销订单 ； 支付了 一笔钱， 可以 退款 ； 等等 。
可以按照这样的 规范 来 命名 ： A() 服务 对应 的 撤销方法 是 ACancel() 服务， 即通过 “Cancel” 后缀 来 表明 。
但 ACancel() 方法 的 业务意义 是 什么， 比如 是 撤回表单， 还是 删除表单， 或是 取消订单， 或是 删除订单， 或是 退款，
这个 应由 服务 的 API 文档 明确 的 说明 。
确立了 “撤销”（Cancel） 实现 事务 的 架构 后，
就可以 开始 研究 具体 的 解决方案 。
可以有 2 个 解决方案，
1 程序解决
2 人工解决
我们先说说 人工解决，
通过 界面 将 “撤销”服务（如 ACancel()） 提供出来， 在 业务失败 的 时候， 通知 客服人员 手动 撤销 已执行 的 服务 。
通知方式 比如 发 Mail ， 短信 等 。
再说说 程序解决， 程序解决 就是 在程序中 控制， 如果 业务失败 则 撤销 已执行 的 服务（如 调用 ACancel()） 。
最简单 的 程序解决 就是 在 业务失败 的时候， 调用 撤销服务（如 ACancel()）， 如果 在 撤销 过程中 也发生错误， 则 通知 客服 转入 人工处理 。
通知方式 比如 发 Mail ， 短信 等 。
进一步， 自动化程度高的 ， 严格的 撤销机制 则 需要 实现一个 类似 数据库 的 事务机制， 或者说 事务控制器 。
需要将 事务 状态 记录为 事务日志 ， 持久化在 文件 或者 数据库 中， 只到 整个 事务 完成， 则 事务日志 中的 事务状态 才会 变成 成功 。
事务完成 包含 成功 和 失败且撤回成功 。
要做到 这些 技术比较复杂， 也会对 性能 带来 影响 。 也会让 开发 和 维护 变得 更复杂 。
这种机制 的 好处 是 自动化程度高， 精确， 适用于 严格精确 的 场合， 如 金融 。
当然， 自动化 ，严格 这不是 绝对 的， 有时候 也需要 人工介入， 但 概率 比较 小 。
大家可能会说， 金融行业 用 这种 架构 不是 用的 很 嗨 吗 ？ 为什么说 这种 架构 会 让 开发 和 维护 变得 复杂呢 ？
能不能 在 一般 的 业务系统 互联网应用 商业应用 中 也使用 这种 架构（机制） 呢 ？
金融业中用这种架构的， 应该是 支付（交易） 的 基础架构， 这部分 很少 会 “变， 动” ，
其次， 这部分 基础架构 要 “变， 动” 的话， 通常 需要 “专业的技术人员” 才能实施 。
这和 一般的 业务系统 互联网应用 商业应用 的 要求 是 不一样的 。
对于 小型团队 小型项目， 中型团队 中型项目， 人工为主 的 方式 基本上应该够了 。
对于 SaaS， 客服的部分可以交给 各级服务商 来做， 这样， 人力也不是问题 。