SOA 作为一个软件系统，如果说技术上有个不变的规律那就是——“总在变”，变化也向架构师们提出了如何对 SOA 实施有效版本管理的要求。最近 Boris Lublinsky 分别为微软架构师杂志（《Microsoft Architect Journal》）和 IBM developerWorks 撰文，介绍他的相关经验。
业务环境的变化常常需要 IT 服务的实现相应作出变化，虽然通过很多新技术或者模式化的实施经验可以帮助我们提供高质量的服务，尽量少的对实现做出变化，但是 IT 技术自身的发展——操作系统、开发工具、开发语言也常常会引发实现上的变化。SOA 自身是个可以有效适应变化的机制，因为它依赖的是抽象的“服务”而非具体的“业务处理”，因此当业务需求变化的时候，一般采用的是变化服务下面的业务处理——修改或者重建，也正因为这个原因，SOA 环境对服务的依赖丝毫不亚于组件开发中的接口。况且 SOA 中很讲究服务的自治性，也就是每个服务独立的修改和维护。当矛盾集中在“自治”与“集成”的时候，SOA 也就到了要考虑版本管理的时候。Boris Lublinsky 在文中提到 3 个引发这一问题的主因：
- 服务接口的变化。
- 消息的变化，可以进一步细分为“小”变化（“可选”/“必选”的变化、引入新的全局元素等）和“大”变化（修改全局元素、修改枚举值等）。
- 实现的变化。虽然理论上这个不会导致服务接口的变化，但是处理上总有些“预处理”和“后续处理”之类的操作，调用的顺序没有变化，但是上下文处理的变化一样会导致最终结果的不同。例如：增加了参数检查后，某些之前成功的调用会变成失败；安全上之前没有数据源（Data Origianl）限制，之后加上了，这样也会导致不符合安全策略调用的失败。
对于上述三种情况，Boris Lublinsky 提出了以下两种解决措施。
- 单一服务方法终端地址（EndPoint Address）加版本参数：也就是在调用服务的的时候，同时告诉服务终端一个版本参数，根据这个参数由服务终端决定调用哪个版本的服务方法。
- 不同版本服务方法有自己的终端地址：该方式下不需要服务方法前面增加一个版本调度机制，客户应用使用和自己“搭对”的服务方法。
前者虽然在引入新版本的服务方式时对客户程序影响很小，但会带来封装的复杂性，而且随着“坛坛罐罐”的增加，为每个服务方法维护这样一个 if then else 很麻烦。一个改进的办法就是把它们全都集中到一个 Broker 或者 Mediator 上，把判断版本取舍的工作推给它，不过改进方法因为要增加中间环节，所以性能上有损失。
后者实现了 Side-by-Side Execution 的目标，降低了客户程序与服务方法间的耦合。当然，这要付出代价，需要服务注册库在寻址上更加灵活，可以让 SOA 的使用者借助它找到适合它的那个版本的服务方法。
除了应用层面的 SOA 版本问题外，更复杂的是 SOA 基础环境的版本问题，包括：传输机制的修改（例如：HTTP 调用变成了队列调用）和消息编码方式的变化等，Boris Lublinsky 给出的答案很简单——Adapter。相比较“没完没了”的业务服务而言，基础环境中更多的是“相对有限”的技术机制，因此 Adapter 的开发量（或集成工作量）在一个时期内是稳定的。
虽然国内 SOA 的应用在很多企业还是起步阶段，可一旦上了这条船，后续的运行维护工作会越来越繁重，更何况对很多企业而言对 SOA 的定位就是用来“梳理”整个企业关键业务系统间的协作。为了协调好 SOA 环境，现在是该绸缪 SOA 版本管理的时候了。
作者简介：王翔，全国海关信息中心高级架构师，从事海关主要广域分布式系统的设计和实施，多次参与各业务系统的优化。此外，作为信息安全工作组副组长，他还一直致力于应用密码技术和公钥基础设施保障海关业务的安全运行。此外，他还是《程序员》杂志的专栏作者。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论