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

前言:

在微服务的架构下, 产品或许会有上百个或上千个微服务。所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (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:

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

结论:

一个相当基本却相当重要的思维: 当产品采用微服的架构时, 我们绝不能只是遵循著微服务的定义, 将产品微服务化。而是应该在团队开发的效率、产品的质量与微服务的边界上下文 (Bounded Context) 之间, 作一权衡、作一考量。

在管理微服务间的共享, 我们提供了四个架构方案; 期望大家能在权衡、考量: 团队开发的效率、产品的质量与微服务的边界上下文 (Bounded Context) 后, 能从中找到最 "适合" 自身产品的架构方案。

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

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

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构

一个java高级工程师的进阶之路

1723
来自专栏web前端教室

作为前端开发,需要具备怎样的能力,才能在北上广,拿到1万的薪资?

一万哈,不难达到: 1, 基本js语言没有问题,scope, closure 基本的css,position, vertical align, media qu...

18910
来自专栏北京马哥教育

Linux 下的两种分层存储方案

在存储设备中,使用分层技术,将冷热数据自动分层存放在具有不用读写性能的存储介质上,已经是很普遍的做法,比如 IBM 的 DS8K 中使用的 Easy Tier。...

2576
来自专栏吴伟祥

认识消息队列(一) 转

业务无关,一个具有普适性质的消息队列组件不需要考虑上层的业务模型,只做好消息的分发就可以了,上层业务的不同模块反而需要依赖消息队列所定义的规范进行通信。

321
来自专栏IT米粉

MQ(消息队列)常见的应用场景解析

提高系统性能首先考虑的是数据库的优化,之前一篇文章《数据库的使用你可能忽略了这些》中有提到过开发中,针对数据库需要注意的事项。但是数据库因为历史原因,横向扩展是...

1002
来自专栏北京马哥教育

服务好“最后一公里”,高效CDN架构经验

国内,随着互联网的高速发展,因为各大通信公司的政策,造成了南电信北联通互通有局限性,再加上大小且质量参差不齐的运营商,在这特殊的氛围的互联互通下号称“八线合一”...

3105
来自专栏吴生的专栏

消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局

消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它...

4207
来自专栏CSDN技术头条

【问底】许鹏:使用Spark+Cassandra打造高性能数据分析平台(一)

【导读】笔者(许鹏)看Spark源码的时间不长,记笔记的初衷只是为了不至于日后遗忘。在源码阅读的过程中秉持着一种非常简单的思维模式,就是努力去寻找一条贯穿全局的...

2368
来自专栏云计算D1net

WhatsApp的架构是如何应付高流量的

两年内的飞跃 天价应用当下的规模显然不能与两年前同日而语,这里总结了一些WhatsApp两年内发生的主要变化: 1. 从任何维度上都可以看到WhatsA...

3157
来自专栏嵌入式程序猿

探索ARM Cortex-M7核心:为明日物联网做准备

Cortex-M处理器系列的最新成员是Cortex-M7。这款新的核心具备可用于支持新型嵌入式技术需求的功能,它设计用于需要较高处理性能、实时响应能力和能效的应...

3666

扫码关注云+社区