服务发现
Microservices 先天就是个分布式系统，在架构上最重要的一环当属 服务发现 - service discovery 这技术了。
当一个应用系统被拆分成多个服务，且被大量部署时，还有什么比找到想要调用的服务在哪里，以及是否能正常提供服务还重要?
同样的有新服务被启动时，如何让其他服务知道我在哪?
微服务考验的就是你治理大量服务的能力，包含多种服务, 也包含多个 instances。
要做到这件事，service discovery 就是你要挑战的第一关。
service discovery原理
不论你用哪一套服务来提供 service discovery, 大致上都包含这三个部分:
- Register, 服务启动时的注册机制
- Query, 查询已注册服务的机制
- Healthy Check, 确认服务健康状态的机制
过程很简单，大致上就是服务启动时，自身就先去 registry 注册，并且定时上报 (或是定时被侦测) 服务是否正常运作。
由 service discovery 的机制统一负责维护一份正确 (可用) 的服务清单。
因此服务清单就能随时能接受查询，返回给调用者可用的服务。应用程序只管去 service discovery 查询就好。
service discovery实现方式
service discovery可以用ELB来实现，
这种方式，所有细节都被隔离在 load balancer 跟 service registry 之间，更新时只要统一部署 load balancer & service registry 就足够了。
但这样一来，服务的架构等于多了一层转送；延迟时间会增加；整个系统也多了一个故障点，整体系统的维运难度会提高；另外最关键的，load balancer 可能也会变成效能的瓶颈。想像一下，如果整套 application 存在 N 种不同的服务，彼此都会互相调用对方的服务，那么所有的流量都会集中在 load balancer 身上。
另外一种方式是以consul为代表，注册中心返回可用服务 endpoints列表，由client 自己决定要选择哪一个 endpoint。
这种方式的好处是客户端可以自己挑选最适当的endpoint，通过这种做法实现了点对点的网状通讯。
去中心化的通讯，可以避开单点 (API Gateway or Load Balancer) 造成的性能瓶颈，或单点故障造成可用性下降等问题。
然而这种模式下也存在缺点。调度的机制被控制在 client side, 当这些机制要更新时，难以在短时间内同步更新，要替换掉它，通常得重新编译，重新部署服务才行。
参考：https://columns.chicken-house.net/2017/12/31/microservice9-servicediscovery/