微服务架构 (三): 在微服务的架构中, 也许不需要 Integration Hub

2016.8.12, 深圳, Ken Fang 

在微服务的核心概念中, api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建 endpoint proxy 与 load balancer。

所以, 在微服务的架构中, 架构师规划 Integration Hub; 如: Mule,Camel, ESB…等等, 应该是个合理且正确的架构方案。

但是, 在微服务的架构中, 规划所谓的 Integration Hub, 往往却会为微服务的架构, 引入下列的问题:

1. 性能:

微服务架构最主要的特点便是: 能使产品的架构能够 “水平扩展”。所以, 架构师应将不论是微服务之间的调用或是来自微服务外部的使用者界面、系统或设备的调用, 都应当成是 “分布式远程调用”。

因此, 假如, 在已是 “分布式远程调用” 的微服务架构下, 再置入个 “远程调用” 的 Integration Hub, 则产品的整体性能将会受到某种程度负面的影响。

2. 复杂度:

微服务的分布式架构的复杂度是相当高的。所以, 架构师在微服务的架构下, 置入 Integration Hub 时, 则会使原先只会发生的微服务的分布式远程调用, 便会需先发生 Integration Hub 的远程调用, 然后, 才会发生微服务的分布式远程调用。毫无疑问的, 这将使当发生运维问题时; 如: 某笔交易的资料丢失时; 增加问题定位的难度与时间。因为, 整体架构的复杂度已因 Integration Hub 的置入, 而更往上提升。

3. 边界上下文 (Bounded Context) :

当架构师在微服务的架构中置入 Integration Hub 时, 则表示各微服务都可将自身部分的功能 (业务流) 上升至 Integration Hub 中做处理。如此的作法, 将使各微服务可能会在Integration Hub 中, 发生共享。 也就是说, 当各微服务的边界上下文 (Bounded Context) 不仅包含了各自的某一端到端的业务场景 (功能) 、数据 (数据库) 外, 更包含了Integration Hub 时, 将使得微服务的边界上下文 (Bounded Context) 的界定, 变得相当的棘手, 甚至不可行。也就是说, 各微服务的边界上下文 (Bounded Context) 将因包含了 Integration Hub, 而使得各微服务间会发生共享; 使得各微服务, 很难再维持完全自主性的运作。

4. 部署流水线 (Deployment Pipeline):

当各微服务都可将自身部分的功能 (业务流) 上升至 Integration Hub 中做处理时, 则表示当部署某一微服务时, 也需同时部署 Integration Hub; 而部署与配置 Integration Hub 往往需耗时整晚, 甚至是数天。

5. 开发与测试:

当架构师在微服务的架构中置入 Integration Hub 时, 则表示不论是开发或测试人员都必需花费时间去学习 Integration Hub; 如: Mule, Camel, ESB…等等。

6. 可靠性与坚固性:

当来自微服务外部的使用者界面、系统或设备的调用, 都需经过 Integration Hub 时, 则就意味著当 Integration Hub 无法运作时, 则将使得微服务都将无法被调用。

既然, Integration Hub 会为微服务的架构引入上述的问题, 则身为个架师, 在微服务的架构下, 针对合约变换 (contract transformation), 服务编排 (service orchestration), 整合第三方软件 (integration with third-party apps) 的设计原则、方法是什么?

I.   设计原则:

     不置入Integration Hub, 而完全以可独立自主的微服务, 个别处理合约变换 (contract transformation), 服务编排 (serviceorchestration), 整合第三方软件 (integration with third-partyapps) 。

II.  设计方法:

1.  合约变换 (contract transformation):

微服务 X 只能接受 XML。所以, 当外部的使用者界面、系统、设备或其他微服务传送 JSON 至微服务 X 时, 微服务 X 便需所谓的合约变换 (contract transformation); 将 JSON 转换为 XML 或将 XML 转换为 JSON。

合约变换 (contract transformation) 有两种作法:

                            i. 由另一个微服务Y专注将合约变换 (contract transformation) 做到最好。当整个产品中, 多数的微服务都需合约变换 (contract transformation) 时, 便需采用此方案。

                            ii. 在既有微服务X新增一新的 endpoint, 处理合约变换 (contract transformation) 。当采用此方案时, 需注意原微服务 X 是否会因为新增此合约变换 (contract transformation), 而变的过于复杂。

2.  服务编排 (service orchestration):

当微服务的架构中, 没置入IntegrationHub 时, 便没有一个指挥者会指挥著, 现在应调用微服务 A, 然后, 接下来应调用微服务 B… 等等。

微服务的特点便是每个微服务都有个明确的边界上下文 (Bounded Context), 而可自主的运作。所以, 在微服务的架构中, 可直接采用服务编舞 (Service Choreography) 的方式; 由微服务自身决定需调用那个微服务, 而不需经由某一个指挥者, 来指挥接下来应调用那一个微服务。

3. 整合第三方软件 (integration with third-party apps):

我想, 大家也许已经知道该怎么做了; 针对每一个对第三方软件的调用, 开发一个 Microservice Gateway。由 Microservice Gateway 调用第三方软件。也就是说, 第三方软件, 可藉由Microservice Gateway 所提供的单一共同的协议 (protocol); 如: REST; 进行分布式的调用。

这种架构上的作法, 也可应用在既有系统, 还没法转移到微服务的架构时; 可针对每一个对既有系统的调用, 先开发一个 Microservice Gateway。然后, 再逐步将既有系统的功能、场景转移到相对应的 Microservice Gateway 中。如此, 当既有系统的功能、场景转移到相对应的 Microservice Gateway 中后, 也不必再重新修改, 原先会调用 Microservice Gateway 的外部的使用者界面、系统、设备或是微服务。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

Docker为何未在生产环境中取得广泛成功?

Docker的发展势头一天比一天强劲,它显然在试图解决实际的问题。然而,对如今许多的生产环境用户来说,没有出现优点压倒缺点的局面。在开发、测试和持续性集成等环境...

35710
来自专栏企鹅号快讯

Kubernetes的前世今生和未来

有人认为自动化,云计算和人工智能是第四次工业革命。如果你开始感受到IT领域自动化率的飙升,特别是在应用程序部署和管理领域(我觉得还不是无缝的自插拔式),那么不用...

2296
来自专栏杨建荣的学习笔记

最近让我焦灼的四个问题(有解) (r7笔记第76天)

之前写了一篇 《最近让我焦灼的四个问题》,既是感慨,也是无奈,既是记录问题,也是鞭策自己,当然只是吐槽,抱怨是没有任何意义的,所以我更新第二篇,这些问题在近些天...

3606
来自专栏Zchannel

#Linux建站入门第二期#为建站挑选合适的VPS/独立服务器

上一期我们讲到,无法远程管理中国家宽环境下的linux系统(因为端口封锁的缘故),所以建站需要购买VPS,这里说的VPS是什么呢,我们来看看维基百科的解释

1582
来自专栏企鹅号快讯

新版微信主界面新增小程序入口,小程序真正的红利已来临

微信小程序最近的更新又有点勤快了啊,就在刚才,在我百无聊赖的刷朋友圈的时候,微信公众平台官方给我推荐了这么一条消息,如图: ? 说实话,对于微信小程序这样的消息...

1959
来自专栏PPV课数据科学社区

【学习】性能基准测试:KVM大战Xen

在上周,我们对 KVM 和 Xen 近几年里在性能上的改进进行了一些有趣的探讨后,我打算自己做一些这方面的小研究。我能找到的最新的资料,是来自2013年 Ph...

3313
来自专栏社区的朋友们

开源助力腾讯云容器服务

腾讯很多业务早已经跑在容器平台上,所以说腾讯内部对容器这块也积累了很多经验和教训,这次分享的主题,就是当我们把容器服务放在云上的时候,我们碰到的一些问题,以及我...

3010
来自专栏古时的风筝

Docker:Ubuntu下的安装

Docker是什么 Docker 是 Docker.Inc 公司开源的一个基于 LXC技术之上构建的Container容器引擎, 源代码托 管在 GitHub ...

3545
来自专栏Golang语言社区

创建一个杀手级 Go Cli 的 5 个关键点

CLI(命令行接口)是一种文本接口,其提供了一种快速、自动化的方式与应用程序打交道,并且还可以和其他命令行程序接口创建新的工作流。

1525
来自专栏陈云的专栏

Docker 学习笔记 ( 一 ) 简介以及构架剖析

之前一直忙于项目工作,一直没有好好去系统学习,完善自己的知识体系,以致于在腾讯两年知识体系都没有深度发展,还是停留在原来的领域,所以从 8 月份开始学习 doc...

1.1K2

扫码关注云+社区