题目
在微服务系统中，当服务达到一定数量时，通常需要引入【注册中心】组件，以方便服务发现。
大家有没有思考过，注册中心存在的最根本的原因是什么呢？注册中心在企业中的最佳实践是怎样的？注册中心的服务发现有两大模式，分别是：【客户端发现模式】和【服务端发现模式】，这两者之间有怎样的区别呢？
下面关于【注册中心】的描述中，说法正确的有哪几项？
A. 注册中心存在的本质原因是为了降低【服务提供方】和【服务消费方】之间的耦合性，避免两者循环依赖的问题；
B. 在大中型微服务系统中，【注册中心】通常需要和 “服务管理平台” 配合完成 服务的注册和订阅，而【注册中心】专注于 “服务节点的注册” 和 “服务节点的发现”；
C.【客户端发现模式】的注册中心相对直接，因为客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡；Consul Template 是客户端发现模式的典型范例；
D.【服务端发现模式】的注册中心最大的优点是客户端无需关注服务发现的细节，减少了编程语言框架需要完成的服务发现逻辑；这种模式对部署环境的依赖较强，Netflix Eureka 是服务端发现模式的典型范例。
解析
一、先讨论注册中心存在的本质原因
举例，服务消费方 X 远程调用服务提供方 Y，如下图所示。我们说，服务 X 依赖于服务 Y；也就是说，服务 X 知道服务 Y 的存在性， 而服务 Y 不知道服务 X 的存在性。当服务 Y 集群扩容一个节点或缩容一个节点时，服务 Y 就需要把这种情况同步告之服务 X，也就是说，服务 Y 需要知道服务 X 的存在性。
言外之意，从服务调用上来说，服务 X 依赖于服务 Y，但是从服务管理上来说，服务 Y 又需要依赖于服务 X。此时，服务消费方和服务提供方之间形成了一种循环依赖的局面。怎么解决这个问题呢？这就是【注册中心】这个组件存在的根本原因了，如下图所示。
为了避免服务提供方 Y 对服务消费方 X 的依赖，服务 Y 只需把自己注册到【注册中心】即可，然后哪个服务对 Y 感兴趣，自己去【注册中心】发现和获取就好了，服务 Y 不用关注。因此：注册中心存在的本质原因是为了降低【服务提供方】和【服务消费方】之间的耦合性，避免两者之间循环依赖的问题。
二、再说注册中心在企业应用的一种最佳实践。
如下图所示，【服务管理平台】用于对服务集群信息（比如：服务名称、服务负责人、服务归属部门、服务吞吐量等）和服务订阅信息进行管理，侧重于对服务集群的管理；【注册中心】用于对服务节点的注册、健康检查、提供节点查询和变更通知等，侧重于对服务节点的管理。
基本的服务流程如下：
-
服务负责人在对外发布服务时，需要首先在【服务管理平台】上对服务进行注册；
-
服务消费方服务的负责人，如果要调用其他服务，需要在【服务管理平台】上发起调用申请，即 “订阅服务”申请；该申请被审批通过后，方可生效，毕竟如果是高吞吐的调用，是需要服务提供方集群进行扩容的；
-
服务提供方服务集群中的每一个节点，在启动的时候，将自己注册到【注册中心】；并且每一个节点在宕机或假死时，注册中心都可以通过 “健康检查” 及时获取到；
-
服务消费方服务集群中的每一个节点，在启动的时候或启动之后，都可以到【注册中心】获取到已经订阅的服务提供方集群中还活跃的服务节点列表；如果服务提供方集群节点列表有任何变化，【注册中心】都可以及时将 “变更信息” 通知到服务消费方集群中的每一个节点；
-
最后，服务消费方集群中的每一个节点，向服务提供方集群中的每一个节点发起 【RPC】调用。
三、我们再讨论注册中心服务发现的两大模式：【客户端发现模式】和【服务端发现模式】。
【客户端发现模式】更为常见，如下图所示。服务提供方向注册中心进行注册，每一个服务消费方节点从注册中心获取服务提供方服务集群的节点列表，并且对请求实现负载均衡。
【客户端发现模式】的注册中心相对直接一些，因为客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡；这种模式的缺点就是客户端与服务注册绑定，要针对服务端用到的每个编程语言和框架，实现客户端的服务发现逻辑；Netflix Eureka 是客户端发现模式的典型范例。
【服务端发现模式】如下图所示，客户端直接将请求打在 服务端的 “负载均衡” 组件上，“负载均衡” 组件查询【注册中心】获取服务提供方节点列表，然后将请求转发到其中一个节点上。
【服务端发现模式】最大的优点就是客户端无需关注服务发现的细节，只需要简单地直接向负载均衡器发送请求即可，这减少了编程语言框架需要完成的服务发现逻辑；不过，这种模式需要部署环境提供这样的 “负载均衡”组件方可，对部署环境的依赖较强；Consul Template 是服务端发现模式的典型范例。（关于Consul Template 我们会在后续进行详细分析！）
参考答案
AB
