服务注册中心

　　创建服务的目的是为了供需要使用该服务实现的功能的使用者调用。调用服务需要知道其位置，即服务端点地址。在最简单的情况下，端点地址可以硬编码到服务使用者的实现中。（Java™ 和 .NET® 环境中都采用这种方式来基于服务的 Web 服务描述语言（Web Services Description Language，WSDL）生成 Web 服务使用者。因此，发现很多当前系统使用硬编码端点地址应该不会令人感到意外。）此方法将服务使用者实现与服务位置紧密耦合（地址耦合）。

　　图 4. 使用者直接调用服务

 
　　为了在这样紧密耦合的实现中（如图 4 中所示）包含服务地址变更，需要对服务使用者实现进行修改。这很容易出错，而且随着服务数量的增加，扩展性也不好。如果应用于多环境（开发、测试、质量保证、生产）的情况，只会让问题变得更为复杂。

　　通过将端点地址外部化到配置文件中，可在一定程度上改进此实现。此方法更为灵活，因为它将端点地址从使用者的代码中删除，将其外部化到配置文件中。这样，服务使用者能够在不必更改服务使用者代码的情况下包含地址更改。不过，这个选项也会在使用者和服务数量增加（配置文件也会随之增加）的情况下遇到可扩展性问题。

　　通过使用专门动态地将服务查询解析为端点地址和调用策略的组件（即服务注册中心），可提供此问题最为灵活和最易于维护的解决方案。在这种情况下，服务注册中心包含关于服务部署的所有信息、其位置以及每个位置与调用关联的策略。

　　Steve Vinoski 在其 IEEE Internet Computing 文章“The social side of services”中指出，服务注册中心的可用性会随着服务数量的增加而提高 (Vinoski)。他写道：

　　解决这些棘手麻烦的通常的技术方法是：

　　为了使服务作为整体进行操作，它们需要彼此相互了解。
　　为了让服务彼此相互了解，必须将其通过硬性方式连接起来，或者能够动态地找到彼此。
　　硬编码将很困难，因为这意味着紧密耦合，而且稍后使用其他服务实现进行替换时存在潜在困难。
　　那么，为了促进动态发现，服务需要有一个能宣传自己并了解其他服务的地方。
　　这当然就是注册中心了！
　　服务注册中心的概念最初是由 Web 服务体系结构组引入的，该团队将统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）注册中心定义为服务使用者和提供者间的“匹配器”。当时确定的 UDDI 的责任是基于使用者所需的功能提供服务提供者动态选择。其角色与黄页类似。尽管多个供应商和标准组织大量推广，但将 UDDI 用于进行服务匹配的用途从来没有实现。今天 UDDI 的主要用途仅限于存储 WSDL 文件，供在使用者的设计阶段使用。

　　服务注册中心一个更为实际的用法是，在运行时基于服务使用者所请求的服务名和策略查找服务。在此情况下，服务定义在使用者开发期间可用，注册中心的使用仅限于服务端点地址和动态绑定的运行时解析。此方法的体系结构如图 5 中所示。

　　图 5. 基本服务注册中心体系结构

 
　　图 5 中所示的体系结构与 Java Naming and Directory Interface (JNDI) 实现类似，而后者用于 Enterprise JavaBeans (EJB) 组件的动态绑定。服务端点地址的后期绑定降低了位置耦合。此解决方案消除了在服务使用者实现中硬编码服务端点地址或将其存储到配置文件的需求。此外，注册中心还允许对服务端点地址及关联的调用策略进行集中管理。

　　典型的服务注册中心实现支持以下两个可能的端点地址解析与路由模型之一：

　　图 6. 使用服务注册中心直接路由

 
　　直接路由。在此模型（如图 6 中所示）中，查询注册中心所需的信息驻留在使用者中。此信息包括一组受支持和需要的策略。注册中心找到匹配的服务后，使用者将决定使用哪个服务并将请求直接路由到此服务。

　　图 7. 使用服务注册中心基于中间层进行路由

 
　　基于中间层进行路由.此模型（如图 7 中所示）依赖中间层处理路由。服务使用者并不必直接与服务进行交互。相反，所有服务请求都定向到中间层，中间层借助使用者特定的信息查询注册中心，决定使用哪个服务并动态地将所有请求路由到该服务。此模型与企业应用程序集成（Enterprise Application Integration，EAI）代理类似，后者会接收消息，并基于内部注册中心将其路由到相应的目的地。很多企业服务总线（Enterprise Service Bus，ESB）实现提供对基于上下文的路由中间层模型的支持。

　　存储库还是注册中心？

　　正如我们看到的，服务存储库和服务注册中心在整个企业 SOA 实现中都占有一席之地。服务存储库是企业 SOA 治理的基础，支持对所有服务相关的信息进行集中管理，包括设计、实现和使用构件。服务注册中心是服务位置虚拟化的基础，允许对所有企业服务的位置和调用策略进行集中控制。服务存储库与注册中心的主要区别在于：

　　存储库包括服务的所有设计和开发构件，设计工具在设计和构建时可能会需要这些构件。相反，注册中心包含运行时绑定所需的此信息的子集。
　　服务存储库经过了优化，能存储大量资产和支持大量用户进行临时查询来查找这些资产。在这种情况下，主要设计需求是灵活的分类和查询支持以及存储库本身的可伸缩性及用户友好界面。另一方面，服务注册中心针对服务端点地址的运行时查询进行了优化。主要设计需求是查找性能和高可用性。
　　对存储库的访问在企业边界内进行。相反，经常需要从企业内部和外部访问注册中心。

　　因此，我们最后看到的不是在服务存储库和注册中心之间进行选择，成功的 SOA 实现中需要同时使用这两者。我们需要决定的是在哪些场合使用哪个的问题。务必要对这两个概念加以区分，因为它们各自有不同的用途。