谈谈 SOA

为什么要 讨论 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，   客服的部分可以交给 各级服务商 来做，  这样， 人力也不是问题 。