微服务架构咨询和培训服务

本站点由 Chris Richardson 编写和维护,他是经典技术著作《POJOS IN ACTION》一书的作者,也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者,eventuate.io 是他的最新创业项目,一个微服务应用和数据服务平台。

Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国,为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流,建立合作,请点击下方按钮跟他取得联系。

预约课程

微服务应用的示例代码

为了避免纸上谈兵,Chris 提供了一套与这些模式相关的示例代码。这组代码使用 eventuate 框架,实现了微服务架构下分布式数据的存取。请点击下方按钮访问。

访问代码


模式库

核心模式

服务拆分

部署模式

需要关注的边界问题

通讯模式

数据管理

安全模式

可测试性

可观测性

UI 模式


订阅微服务邮件列表

全新的微服务应用支撑平台,成功解决微服务架构下分布式数据管理的难题。

了解更多

加入 微服务架构的 Google 讨论组(需要翻墙)

模式: 客户端服务发现

背景

不同服务之间通常需要相互调用。在单体应用程序当中,服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下,服务在固定并且已知的位置(主机与端口)运行,从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而,现代化微服务应用程序中通常在虚拟化或者容器化环境中运行,在这样的环境中服务的实例数量和位置是动态变化的。

因此,要想实现客户端向动态变化的一组服务端实例发送请求,我们必须采用新的机制。

问题

服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置?

需求

  • 每一服务实例都会在特定位置(主机与端口)通过HTTP/REST或者Thrift等方式发布一个远程API。
  • 服务端实例的具体数量及位置会发生动态变化。
  • 虚拟机与容器通常会被分配动态IP地址。
  • 服务实例的数量会发生动态变化。例如,EC自动伸缩组会根据负载情况随时调整实例数量。

方案

在向某一服务发送请求时,客户端会通过查询 Service Registry,即服务注册表,以获取该服务实例的位置。该注册表中包含全部服务的位置。

以下示意图展现了这种模式的结构:

而这正是微服务基底框架的典型处理方式。

例子

Netflix OSS 正是客户端发现机制的典型代表:

结果

客户端发现机制拥有以下优势:

客户端发现机制亦存在着以下弊端:

  • 这一模式使客户端与服务注册表相耦合。
  • 需要为应用程序中使用的每种编程语言/框架建立客户端服务发现逻辑,例如Java/Scala以及JavaScript/Node JS。举例来说,Netflix Prana 就为非 JVM 客户端提供了一套基于HTTP代理的服务发现方案。

相关模式

致谢

为了避免重复翻译,本文根据中国普元公司宋潇文先生的译文整理修订,在此向宋潇文先生表示感谢!


Tweet
© 2017 Chris Richardson 版权所有 • 保留一切权利 • 本站由 Kong 提供支持.