微服务架构 (六): 微服务间的共享的管理

2016.8.18, 深圳, Ken Fang

在微服务的架构下, 产品或许会有上百个或上千个微服务。所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (Library) 时, 则当此共享的库, 即使只是针对某个微服务做些很少量的修改, 也可能会对其他上百个或上千个微服务, 造成不可预期的影响。

但在实际的项目中, 产品中的微服务又无法避免的会对某些库 (Library) 产生依赖; 共享某些库 (Library)。

所以, 架构师必需要知道要如何管理微服务间的共享?

微服务会形成共享的原因, 主要是来自于:

1.       微服务共同继承于某个抽象的接口。

2.       微服务同时依赖于某个共享的库 (Library)。

架构师可采用以下的四种方案, 管理微服务间的共享:

A.      Compile Binding: 将多个微服务会共享的代码, 置入在一共享的项目中。在编译的时候, 共享的代码便与特定的微服务的代码编译在一起。此种方案, 从开发的角度, 其好处是显而易见的: 不需重启运维中的微服务, 而是在编译, 单元测试的时候, 特定的微服务便可立即知道, 在共享项目中的任何的修改或变更, 对微服务自身的影响为何? 然而, Compile Binding 却存在著个严重的问题: 当共享的项目与数十个、上百个微服务是 Compile Binding 时, 则有的微服务可编译, 可测试通过, 可发布、有的微服务却发生了无法编译, 或测试不通过、有的微服务则发生了无法发布....; 真的是一场灾难。更糟糕的是, 当灾难发生时, 各个微服务也没法对所共享的项目, 有任何的选择权或控制权; 各个微服务无法选择自身所要的共享项目的版本。

B.      JAR File/ Shared Library: 各微服务间共享著编译, 构建后的包 (Shared Library) ; 如: JAR包。

此方案最大的好处便是: 各个微服务间对其所共享的 Shared Library 拥有所谓的选择权; 也就是说, 某个微服务可选择 1.0 版的 JAR, 另一个微服务则可以选择 1.5 版的 JAR。当然, 缺点是: 当有数十个、上百个, 甚至是上千个微服务共享某个发生变更的 Shared Library 时, 则这些为数众多的微服务便得一一的重新启动后, 才能执行测试, 才能得知 Shared Library 的改变, 对各个微服务的影响。Share Library 应尽量的能细分到某一特殊功能的粒度; 如: 某一庞大的 Backend.jar 应细分为 Persistence.jar, SQL.jar, Security.jar。某一大而全的 Utility.jar 亦应细分为Calculator.jar, MaxTime.jar。这样的细分粒度, 将有利于能更精确的分析出, Shared Library 在每个版本中到底变更些了什么? 各微服务针对这些变更, 所应采取的相对应的措施为何?

C.      Replication:将各微服务都会用到模块 (代码) , Copy-Paste 到各个微服务中。

此方案虽然违背了DRY (Do not RepeatYourself.), 但却使得每个微服务维持了自身的边界上下文 (Bounded Context), 而使得产品中的数百个或甚至数千个微服务间的依赖降低; 产品中的数百个或甚至数千个微服务间的依赖越少, 各微服务便得以更高效的方式进行开发、测试、发布。

当然, 架构师必需要确保: Copy-Paste 到各个微服务中的模块 (代码) 的质量是稳定的与变更的频率是不高的。因为, 任何一个质量上的缺陷或任意的变更, 将会造成数百个或甚至数千个微服务维护的工作量。  

D.      Service Consolidation: 当某个SharedLibrary; 如: 某个.jar; 被多个微服务所共用时, 则当此 Shared Library 有变更时, 多个共用此 Shared Library 的微服务, 将必需再次的被测试, 再次的被发布。架构师此时应重新的思考: 这些共用 Shared Library 的微服务, 那些或全部可与 Shared Library 合并为一单一的微服务; 合并后, 将可减化 Shared Library 变更后的测试与发布的复杂度与工作量。

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术杂文

微服务:真正的架构模式

微服务的相关知识和它的神秘令我着迷。概念上的微服务就像是现代最有趣的流行架构之一。它足够功能强大,有着广泛的使用方法;也足够模糊,难以统一而论。

1133
来自专栏斑斓

设计匠艺 | 小即是美之二

小的益处还有一点,它可以使得我们在架构决策或技术选型时,可以变得更加从容。 譬如说,因为某些原因我们需要将整个企业系统从WebLogic上迁移到JBoss上,无...

3055
来自专栏SAP最佳业务实践

SAP最佳业务实践:联产品的生产(235)-3库存物料的采购和生产启动

一、库存物料的采购无 QM 的采购 (130) 在实际业务案例中,通常从外部供应商处采购原材料,这可以包含在标准采购流程之中。 既可以将库存直接过帐到存储地点,...

3386
来自专栏美团技术团队

流量运营数据产品最佳实践——美团旅行流量罗盘

背景 互联网进入“下半场”后,美团点评作为全球最大的生活服务平台,拥有海量的活跃用户,这对技术来说,是一个巨大的宝藏。此时,我们需要一个利器,来最大程度发挥这份...

34210
来自专栏SDNLAB

开源5G网络编排器框架:Open Baton

伴随移动互联网用户数的快速增长,迅速崛起的软件定义网络技术,为下一代网络基础设施的革命化变革铺平道路。然而,数量与规模不断增长的用户连续提出的需求,使上层服务提...

3355
来自专栏大数据和云计算技术

Apache Eagle:实时安全监控方案

Eagle是eBay开源的一个分布式实时安全监控方案。通过离线训练模型集合实时流引擎监控,能立即监测出对敏感数据的访问或恶意的操作,并立即采取应对的措施。下图是...

3419
来自专栏京东技术

京东评价晒单系统的组件化设计

1533
来自专栏方俊贤的专栏

微服务架构: 微服务间的共享的管理(六)

在实际的项目中, 产品中的微服务又无法避免的会对某些库 (Library) 产生依赖; 共享某些库 (Library)。所以, 架构师必需要知道要如何管理微服务...

5020
来自专栏ThoughtWorks

Web App性能优化之亮剑|洞见

自计算机诞生以来,系统性能问题亘古未变,从指令级优化到集成系统的优化,可谓愈来愈复杂。每种类型的性能问题即便出现的场景不尽相同,但依然有一些性能优化模式,久经沙...

3266
来自专栏张善友的专栏

开放源代码与.NET应用程序平台的性能测试

您的企业或组织采用哪一种应用程序平台架构?不论哪一种,应用程序平台基本上至少都包含了服务器操作系统、Web服务器软件、数据库服务器软件、程序开发语言,有些平台还...

1929

扫码关注云+社区