Chris Richardson 的微服务架构网站
本站由 Kong 提供支持微服务架构咨询和培训服务
本站点由 Chris Richardson 编写和维护，他是经典技术著作《POJOS IN ACTION》一书的作者，也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者，eventuate.io 是他的最新创业项目，一个微服务应用和数据服务平台。
Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国，为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流，建立合作，请点击下方按钮跟他取得联系。
模式库
核心模式
服务拆分
部署模式
需要关注的边界问题
通讯模式
数据管理
安全模式
- 访问令牌new
可测试性
可观测性
UI 模式
- 服务器端页面碎片化元素构建new
- 客户端 UI 构建new
全新的微服务应用支撑平台，成功解决微服务架构下分布式数据管理的难题。
加入 微服务架构的 Google 讨论组（需要翻墙）
模式: 服务器端服务发现
背景
不同服务之间通常需要相互调用。在单体应用程序当中，服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下，服务在固定并且已知的位置（主机与端口）运行，从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而，现代化微服务应用程序中通常在虚拟化或者容器化环境中运行，在这样的环境中服务的实例数量和位置是动态变化的。
因此，要想实现客户端向动态变化的一组服务端实例发送请求，我们必须采用新的机制。
问题
服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置？
需求
- 每一服务实例都会在特定位置（主机与端口）通过HTTP/REST或者Thrift等方式发布一个远程API。
- 服务端实例的具体数量及位置会发生动态变化。
- 虚拟机与容器通常会被分配动态IP地址。
- 服务实例的数量会发生动态变化。例如，EC自动伸缩组会根据负载情况随时调整实例数量。
方案
在向某一服务发送请求时，客户端会通过在已知位置运行的路由器（或者是负载均衡器）发送请求。路由器会查询服务注册表，并向可用的服务实例转发该请求。服务注册表也可能背内建于路由器之中。
以下示意图展现了这种模式的结构：
例子
AWS Elastic Load Balancer（即AWS弹性负载均衡，简称ELB）便是一个服务器端服务发现模式的例子。客户端向该ELB发出HTTP（S）请求（或者开启TCP连接），而ELB则在一组EC2实例中对该流量进行负载均衡。ELB既能够对来自互联网的外部流量进行负载均衡，又能够被部署在VPC中，对内部流量进行负载均衡。ELB同样可作为服务注册表发挥作用。EC2实例可通过API调用或者借助自动伸缩分组机制注册至ELB。
一些集群解决方案如 Kubernetes 以及 Marathon，会在每台主机上运行一套代理，用来提供服务器端服务发现模式的路由机制。为了访问服务，客户端可以利用被分配至该服务的端口接入这个本地代理。该代理随后会将各请求转发给在集群某处运行的服务实例。
结果
服务器端发现机制拥有以下优势：
- 相较于客户端服务发现，其客户端代码由于无需实现发现功能而更为简单。而且客户端只需要向路由机制发送请求即可。
- 部分云环境提供此项功能，例如AWS Elastic Load Balancer。
但服务器端发现机制亦存在着以下弊端：
- 除非成为云环境的一部分，否则该路由机制必须作为另一系统组件进行安装与配置。为实现可用性和一定的接入能力，还需要为其配置一定数量的副本。
- 相较于客户端服务发现，服务器端发现机制需要更多的网络跳转。
相关模式
致谢
- 为了避免重复翻译，本文根据中国普元公司宋潇文先生的译文整理修订，在此向宋潇文先生表示感谢！