服务版本治理

　　提供服务后不久，这些服务的用户就开始需要进行一些相应的更改。需要对问题进行修复，需要添加新功能，需要重新设计接口，还需要删除不需要的功能。服务反映业务的情况，因此，随着业务发生变化，服务也需要进行相应的更改。

　　不过，对于服务的现有用户，需要采用巧妙的方式进行更改，以便不会干扰他们的成功操作。同时，现有用户对稳定性的需求不能对用户希望使用其他功能的需求造成障碍。

　　服务版本治理可满足这些相互矛盾的目标。版本治理允许满足服务现有功能的用户继续以不变的方式使用服务，并同时允许对服务进行改进，以满足具有新需求的用户。当前服务接口和行为将保留为一个版本，而同时会将较新的服务作为另一个版本引入。版本兼容性允许使用者调用不同但兼容的服务版本。

　　版本治理可帮助解决这些问题，但同时也带来了一些新问题，例如需要进行迁移工作。

　　服务迁移

　　即使使用版本治理，使用者也不能期望永远提供和支持某个服务(或更准确地说，希望使用的一个服务版本)。服务提供者最终一定会停止提供此服务。版本兼容性可以帮助延迟这个“最后审判日”，但却不能消除这个问题。版本治理并不会使服务开发生命周期过时，而会允许生命周期扩展到多个连续的代。

　　当使用者开始使用服务时，将会创建对该服务的依赖关系，必须对此依赖关系进行管理。管理技术可用于有计划地周期性迁移到服务的较新版本。此方法还允许使用者利用添加到服务的新功能。

　　不过，即使在采用了最佳治理的企业中，服务提供者也不能仅依赖于使用者迁移。由于各种原因(遗留代码、人力、预算、优先级)，一些使用者可能无法及时地进行迁移。这是否意味着提供者必须永远支持相应的服务版本?提供者是否可以在所有使用者已进行了迁移后直接禁用相应的服务版本?

　　这两个极端都不甚合意。一个不错的折衷办法是为每个服务版本采用有计划的弃用和退役计划，如服务部署生命周期中所述。

　　服务注册中心

　　服务提供者如何提供和宣传其服务?服务使用者如何查找其希望调用的服务?这些都在服务注册中心的职责范围内。服务注册中心将担当可用服务清单的角色，并提供调用服务的地址。

　　服务注册中心还可以帮助进行服务版本的协调工作。使用者和提供者可以指定它们需要或提供的版本，注册中心将随后确保仅列举出使用者所需版本的提供者。注册中心可以管理版本兼容性，跟踪版本间的兼容性并列举出使用者所需的版本或兼容版本的提供者。注册中心还可以支持服务状态，如测试状态和(如前面提到的)已弃用状态，且仅向希望使用服务的使用者提供具有这些状态的服务。

　　当用户开始使用服务时，将在此服务上创建一个依赖关系。每个使用者清楚地知道其所依赖的服务，但在企业全局范围内，这些依赖关系可能很难检测，更谈不上管理了。注册中心不仅列出服务和提供者，还可以跟踪使用者和服务间的依赖关系。这个跟踪功能可以帮助回答一个很古老的问题：谁在使用此服务?可识别依赖关系的注册中心能向使用者通知提供者方面的更改情况，如某个服务变成了已弃用状态。

　　IBM 的 WebSphere Service Registry and Repository 是一款用于实现服务注册中心的产品。它担当服务定义的存储库以及这些服务的提供者的注册中心角色。它提供了一个中心目录，供开发人员查找可重用服务，并且在运行时使用，以便服务使用者和企业服务总线 (ESB) 查找服务提供者及调用服务的地址。

　　服务消息模型

　　在服务调用中，使用者和提供者必须就消息格式达成一致。当独立开发团队分开设计两个部分时，他们很容易陷入难于就公共消息格式达成一致的困境。再加上数十个使用典型服务的应用程序和使用数十个服务的典型应用程序，您就不难理解直接协商消息格式如何会变成需要全力投入来完成的任务。

　　用于避免消息格式混乱的一种常见方法是使用规范数据模型。规范数据模型是一组公共数据格式，独立于任何应用程序，由所有应用程序共享。这样，应用程序就不必就消息格式达成一致，可以直接同意使用现有规范数据格式。规范数据模型处理消息中的数据格式，因此仍然需要对消息格式的其他部分达成一致(如 Header 字段、消息有效负载包含什么数据以及数据如何安排)，但规范数据模型可极大地促进协议的达成。