在Monolithic模式中，各个组件间通常通过函数形式调用。但在微服务架构中，每个微服务通常有多个实例，每个实例具有不同的位置，而且实例会动态变化，比如在负载发生变化时服务会进行扩容或缩容，或者某个实例所在的VM/Container故障后发生迁移，都会导致服务实例地址的变化。因此使用微服务架构开发的应用，必须通过服务注册和发现技术解决此问题。
服务注册
服务要被使用，就需要对外提供服务的位置信息，这个位置信息通常是一个IP地址+端口。在服务只有单个实例并且地址不会动态变化的情况下，服务的位置在使用端可以通过配置文件甚至代码等方式固定死。但在位置信息会动态发生变化的情况下，服务实例就需要将这个地址注册到一个注册中心。
服务的所有实例在自己可以对外提供服务后，将位置注册到一个ServiceRegistry服务。这个服务具有固定的位置或域名，负责保存所有服务实例的位置信息。
在使用ServiceRegistry时，服务实例要在无法提供服务时取消注册。ServiceRegistry需要通过心跳等方式核查出无法提供服务的实例，并将实例自动取消注册。
服务注册有Self Registration和3rd Party Registration两种方式。Self Registration需要由每个服务实例自己实现服务的注册和取消注册的代码，3rd Party Registration则由第三方的Registrar完成服务的注册和取消注册。
ServiceRegistry通常会使用如etcd、zookeeper、consul等具备分布式一致性的key/value数据库存储服务的注册信息，并提供服务实例的变更通知。
Self Registration
优点
- 服务实例能够更好的掌握注册时机，仅在真正可提供服务时才注册到ServiceRegistry
缺点：
- 所有服务都需要实现注册和取消注册代码，实现复杂且与ServiceRegistry有耦合；
- 服务的实例很容易在不能提供服务时忘记取消注册；
3rd Party Registration
优点：
- 服务实例不需要负责服务的注册和取消注册，实现简单
- 第三方的服务注册机制通常会提供健康检查机制判断注册的服务实例是否可用
缺点：
- 第三方的软件通常也需要进行部署和管理，增加了复杂度
- 第三方的服务注册机制通常无法了解服务实例的实际状态
服务发现
客户端要使用服务必须通过服务发现技术获取服务的位置信息。服务发现包括Client-Side的服务发现和Server-Side的服务发现两种方式。
Client-Side Discovery
在Client-Side Discovery的设计中，服务实例的发现由Client进行，发现的方式可以是主动到ServiceRegistry查询，也可以由ServiceRegistry通知到Client。在使用Client-Side Discovery时，Client会发现服务的所有实例，并根据LB策略选择一个实例发起请求。
Server-Side Discovery
在Server-Side Discovery设计中，在Client和所有的服务实例间增加LoadBalance，Client只需要访问LoadBalance，由LoadBalance负责服务的发现和负载均衡。
方案对比
不论是Client-Side还是Server-Side的服务发现，执行发现的组件（Client/LoadBalance）通常都需要引入本地缓存，并通过核查保证与ServiceRegistry的一致性。引入缓存可以避免对ServiceRegistry的频繁交互，能够提升性能。
Client-Side Discovery相对于Server-Side Discovery有更少的跳数，性能更优。但所有类型的客户端都需要实现服务发现与LB算法，客户端的复杂度高，且与ServiceRegistry耦合。
Server-Side Discovery设计中，客户端只需要看到LoadBalance，复杂度低；如果是基于公有云提供服务，则公有云提供商通常会提供现成的服务端LoadBalance。但相对Client-Side Discovery增加了一跳，对性能有一定影响；同时LoadBalance的开发、部署、运维带来了额外的复杂度；
总结
在服务实例的位置会发生动态变化的微服务架构中，需要引入服务注册和发现技术。
服务注册和发现需要一个位置固定或提供了固定域名的ServiceRegistry服务，服务发布端通过Self-Registration或3rd Party Registration将所有的服务实例注册到ServiceRegistry，Client或LoadBalance则通过其获取服务实例的位置以执行负载均衡和发送服务请求。
ServiceRegistry和LoadBalance是系统中的关键服务，如果这两个服务出现了异常，通常会导致系统不可用，因此它们必须具备极高的可用性。
