本站点由 Chris Richardson 编写和维护,他是经典技术著作《POJOS IN ACTION》一书的作者,也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者,eventuate.io 是他的最新创业项目,一个微服务应用和数据服务平台。
Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国,为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流,建立合作,请点击下方按钮跟他取得联系。
核心模式
服务拆分
部署模式
需要关注的边界问题
通讯模式
数据管理
安全模式
可测试性
可观测性
UI 模式
全新的微服务应用支撑平台,成功解决微服务架构下分布式数据管理的难题。
加入 微服务架构的 Google 讨论组(需要翻墙)
不同服务之间通常需要相互调用。在单体应用程序当中,服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下,服务在固定并且已知的位置(主机与端口)运行,从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而,现代化微服务应用程序中通常在虚拟化或者容器化环境中运行,在这样的环境中服务的实例数量和位置是动态变化的。
因此,要想实现客户端向动态变化的一组服务端实例发送请求,我们必须采用新的机制。
服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置?
在向某一服务发送请求时,客户端会通过查询 Service Registry,即服务注册表,以获取该服务实例的位置。该注册表中包含全部服务的位置。
以下示意图展现了这种模式的结构:
而这正是微服务基底框架的典型处理方式。
Netflix OSS 正是客户端发现机制的典型代表:
客户端发现机制拥有以下优势:
客户端发现机制亦存在着以下弊端:
为了避免重复翻译,本文根据中国普元公司宋潇文先生的译文整理修订,在此向宋潇文先生表示感谢!