微服务架构 (三): 在微服务的架构中, 也许不需要 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 条评论
登录 后参与评论

相关文章

来自专栏互联网研发闲思录

对于最近线上服务以及京东等大型互联网公司对java工程师要求的一些思考

        当下线上服务为了减少上线,经常搞成配置化,配置化对于版本以及持续集成本身是很大破坏,对于此,我个人持保留态度, 是反对过多东西进行配置化,其实配...

3298
来自专栏谢海林的专栏

容量管理系统设计方案

容量管理从本质来讲,主要需要解决的问题是系统“亚健康(有病,但还不影响生活和工作)”的情况下,我们能够及时知道,并做出对应策略,确保系统恢复到正常顺畅;本方案主...

1K0
来自专栏Rainbond开源「容器云平台」

Lagom:一个新的微服务框架

1483
来自专栏开源项目

用大白话聊聊分布式系统

一提起“分布式系统”,大家的第一感觉就是好高大上啊,深不可测,看各类大牛关于分布式系统的演讲或者书籍,也大多是一脸懵逼。本文期望用浅显易懂的大白话来就什么是分布...

3659
来自专栏Golang语言社区

【Go 语言社区】选择Go语言的12个理由

多核化和集群化是互联网时代的典型特征,那语言需要哪些特性来应对这些特征呢?多数语言在语法层面并不直接支持协程,而通过库的方式支持的协程的功能也并不完整,比如仅仅...

3338
来自专栏IT技术精选文摘

微服务简介

我们先来看看你为什么要考虑使用微服务。 构建单体应用 让我们假设你们要开始制定一个全新的出租车招标程序,旨在与Uber和Hailo进行竞争。经过一些初步会议和...

2195
来自专栏风火数据

大数据 Hadoop:一把杀鸡用的宰牛刀

Hadoop是个庞大的重型解决方案,它的设计目标本来就是大规模甚至超大规模的集群,面对的是上百甚至上千个节点,这样就会带来两个问题:

952
来自专栏腾讯移动品质中心TMQ的专栏

【UTP自动化测试平台系列之一】架构介绍与优化

导语 UTP自动化测试平台是TMQ的一个联合项目,目的是方便各项目测试人员更好地开展自动化测试建设工作,减少重复平台建设的成本,提高产品的自动化测试效率。 该...

2646
来自专栏EAWorld

应用容器云:接过Java EE的枪

主要大纲: 一、回顾Java EE的发展 二、揭露Java EE的根本性缺陷 三、从Java EE的角度看应用容器云 四、对未来的展望 老实说,今天的观点如果放...

3016
来自专栏SDNLAB

【双语频道】ONOS架构原理

The purpose of this ONOS talk is to convey the rationale behind our approach to ...

3119

扫码关注云+社区