服务中心的两种实现方式：服务名字系统与服务总线系统

系统数量不多时，系统间调用一般直接记录在各系统内部的配置文件里，但系统一多，这种做法就会出问题：比如有10个系统依赖A系统的X接口，A系统实现了功能更好的新接口Y，要让这10个系统全部切到Y接口，就要挨个改这10个系统几十上百台机器的配置再重启，效率极低；再比如A系统总共20台机器，其中5台故障了，如果其他系统是通过域名访问A系统，域名缓存失效前依然可能访问到这5台坏机器；如果是通过IP直接访问，那A系统每增删一台机器，其他所有依赖它的系统的所有机器配置都要同步跟着改，协调成本非常高。服务中心正是为了解决这种跨系统依赖的”配置”和”调度”问题，常见有两种实现方式。服务名字系统（Service Name System）本质上和DNS（Domain Name System）思路一致——DNS把域名解析成IP地址（因为人记不住太多数字IP），服务名字系统则把服务名称解析成”host+port+接口名称”，但和DNS一样，真正发起请求的还是请求方自己，服务名字系统只负责”告诉你去哪找”，不负责”帮你去调”。服务总线系统（Service Bus System）则更进一步，类似计算机主板的总线概念——由总线系统统一完成调用，服务请求方完全不需要直接和服务提供方交互，请求方只需要跟总线打交道，具体转发到哪台服务器由总线系统负责。两者的核心差异在于：”谁来真正发起对目标服务的调用”：服务名字系统只提供地址解析，调用动作还是由请求方自己完成；服务总线系统则把调用这个动作也接管了，请求方彻底不用感知目标服务具体在哪。

结构图：

flowchart TB
  A["服务中心：解决跨系统依赖的配置与调度问题"]
  A --> B["服务名字系统<br/>类比DNS：域名/服务名→host+port+接口名"]
  B --> B1["只负责地址解析<br/>真正发起调用的还是请求方自己"]
  A --> C["服务总线系统<br/>类比计算机总线"]
  C --> C1["由总线统一完成调用<br/>请求方无需直接和服务提供方交互"]
  B1 --> D["核心差异：谁真正发起调用<br/>名字系统=解析后自己调<br/>总线系统=总线代为调用"]
  C1 --> D