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

导语

在过往的服务型的架构下, 我们都会采用如 Mule, Camel...等等, 来进行服务间的合约变换 (contract transformation), 服务编排 (service orchestration), 以及服务与第三方软件间的整合。 而在微服务的架构下, 我们是否应该继续采用如 Mule, Camel...等等 ?

前言

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

所以, 在微服务的架構中, 架构师规划 Integration Hub; 如: Mule,Camel, ESB…等等, 以使微服務間可进行 , 合约变换 (contract transformation), 服务编排 (service orchestration), 并使微服务可整合第三方软件 (integration with third-party apps) 应该是个合理且正确的架构方案。

[图一: api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建 endpoint proxy 与 load balancer]

本文

但是, 在微服务的架构中, 规划所谓的 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. 设计方法:

合约变换 (contract transformation):

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

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

  1. 由另一个微服务 Y 专注将合约变换 (contract transformation) 做到最好。当整个产品中, 多数的微服务都需合约变换 (contract transformation) 时, 便需采用此方案。
    1. 在既有微服务 X 新增一新的 endpoint, 处理合约变换 (contract transformation) 。当采用此方案时, 需注意: 原微服务 X 是否会因为新增此合约变换 (contract transformation), 而变的过于复杂。

[图二: 由另一个微服务 Y 专注将合约变换 (contract transformation) 做到最好]

[图三: 在既有微服务 X 新增一新的 endpoint, 处理合约变换 (contract transformation) ]

服务编排 (service orchestration):

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

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

[图四: 服务编舞 (Service Choreography) : 由微服务自身决定需调用那个微服务, 而不需经由某一个指挥者, 来指挥接下来应调用那一个微服务]

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

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

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

[图五: Microservice Gateway]

结论

"轻装上阵" 一直是微服务架构下的一个核心的设计原则。

我们遵循著 "轻装上阵" 的设计原则, 针对在微服务架构下, 如何设计:

  1. 合约变换 (contract transformation)
  2. 服务编排 (serviceorchestration)
  3. 整合第三方软件 (integration with third-partyapps)

提出设计上的思路与作法。

期望大家在微服务的架构下, 当在设计合约变换 (contract transformation), 服务编排 (serviceorchestration) 与整合第三方软件 (integration with third-partyapps) 时, 能参考本文的作法, 以使自身的微服务可 "輕裝上陣"; 永保微服务的可扩展性。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

正确估算而非过度配置公共云资源

一般来说,企业用户都希望为使用云做好准备,也就是他们不必为没有使用过的资源支付费用。本文所介绍的这些小贴士可以有助于用户正确估算他们的云实例并避免云资源的过度配...

3295
来自专栏IT大咖说

分布式数据库企业级功能技术解密与最佳实践

编辑IT大咖说 阅读字数: 2739用时: 10分钟 本文内容来源于彭旸在OSC源创会上海站上的主题演讲,IT大咖说为与开源中国合作的视频知识分享平台。 ? 内...

3295
来自专栏鹅厂网事

用有限的带宽承载无限的需求:浅谈腾讯网络容量管理

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

2325
来自专栏SDNLAB

【连载-1】数据中心网络虚拟化技术 概要

随着云计算和大数据等新兴应用的快速发展,“数据中心即计算机”(data center as a computer)的技术发展趋势逐渐明朗。数据中心作为一台计算机...

3548
来自专栏SDNLAB

浅谈对5G核心网演进方向的几点展望

最近读到一篇关于5G核心网的论文《Revolutionary Direction for 5G Mobile Core Network Architecture...

3758
来自专栏原创1

百度智能运维的技术演进之路

随着大数据、人工智能、云计算技术的日渐成熟和飞速发展,传统的运维技术和解决方案已经不能满足需求,智能运维已成为运维的热点领域。同时,为了满足大流量、用户高质量体...

810
来自专栏SDNLAB

SDxCentral 2015年NFV报告

1 报告概述 《2015年网络功能虚拟化(NFV)报告》将为读者提供关于NFV市场的发展趋势,以及目前取得进展等方面的观点。我们已经开始看到,在运营商,甚至在企...

2963
来自专栏SDNLAB

数据中心网络虚拟化技术 概要

随着云计算和大数据等新兴应用的快速发展,“数据中心即计算机”(data center as a computer)的技术发展趋势逐渐明朗。数据中心作为一台计算机...

39112
来自专栏Spark学习技巧

浅谈数据分库分表之道

为什么讨论分库分表 在服务器后端技术人员的成长路线上,分片(Sharding)思想的理解和把握是绕不过去的门槛,而数据库分库分表可能是讲述拆分思想最好的教材,大...

2245
来自专栏云计算D1net

云计算:节能之路

有人把云计算技术视为个人电脑、互联网之后的第三次革新浪潮,认为它即将甚至已经从根本上改变整个信息产业的格局,改变人类使用计算机的习惯和方式,因此云计算技术得到了...

3336

扫码关注云+社区