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

在微服务的架构下, 产品或许会有上百个或上千个微服务。所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (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 变更后的测试与发布的复杂度与工作量。

本文作者:

方俊贤 (Ken Fang), 曾任职于 IJI, Rational, Telelogic, Borland◦ 有将近二十年在半导体, 电信产业与军事研究单位, 从事软件工程与精益敏捷开发相关咨询服务的经验。 主要专长是精益敏捷开发, 有价值的产品需求挖掘, 使用者行为场景分析, 动态注入框架设计, ROA, 既有软件架构优化, 探索式测试, 敏捷测试与持续集成。

本文转载自 方俊贤_Ken 的 CSDN 博客

原文链接:

  • http://blog.csdn.net/featuresoft/article/details/52243976
  • http://blog.csdn.net/featuresoft/article/details/52249677
时间: 2024-10-19 02:14:46

微服务架构设计 (六): 微服务间的共享的管理的相关文章

微服务架构如何实现网站服务垂直化拆分

3月10日,2017阿里云网站行业热点问题和解决方案线下研讨会在上海举行.阿里云产品专家银时为大家带来<微服务架构如何实现网站服务垂直化拆分>精彩演讲.主要从服务化的缘起.微服务架构的形成,以及在大规模的服务化过程中所面临的一些挑战以及解决方案,跟大家分享整个微服务.   以下内容根据现场分享和讲师PPT整理而成.   关于讲师:   倪超,阿里花名银时,阿里巴巴企业互联网架构平台产品专家.国家认证系统分析师.IT畅销书作者,著有<从Paxos到ZooKeeper>一书,2015年

Spring Cloud构建微服务架构(二)服务消费者

  Netflix Ribbon is an Inter Process Communication (IPC) cloud library. Ribbon primarily provides client-side load balancing algorithms. Apart from the client-side load balancing algorithms, Ribbon provides also other features: Service Discovery Inte

支撑百度搜索引擎99.995%可靠名字服务架构设计

内容来源:2016年12月16日,郑然在"GIAC 全球互联网架构大会"进行<支撑百度搜索引擎99.995%可靠名字服务架构设计>演讲分享.IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布. 阅读字数:2783 | 4分钟阅读 点击观看嘉宾演讲视频 搜索引擎的挑战 机器数量多,服务数量大:我们有数万台服务器,数十万个服务,分布在多个IDC. 服务变更多,变更数据大:每天几十万次变更,每周10P量级的文件更新,千余人并行开发上百个模块. 检索流量大,稳定性要高:每秒数

架构设计 - 自动化运维之架构设计六要点

运维自动化是我们所渴望获得的,但是我们在一味强调自动化能力时,却忽略了影响自动化落地的一个关键因素.那便是跟运维朝夕相处,让人又爱又恨的业务架构. 因为业务架构是决定运维效率和质量的关键因素之一,所以我想跟大家一起聊一下怎么样的架构设计是对运维友好的.结合这些年在腾讯遇到的业务架构和做运维规划时对业务非功能规范的思考,我们可以把面向运维的架构设计分成六大设计要点. 要点一:架构独立 任何架构的产生都是为了满足特定的业务诉求,如果我们在满足业务要求的同时,能够兼顾运维对架构管理的非功能性要求.那么

微服务架构设计(五):获取微服务数据, 生成报表

架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Context), 数据的时效性, 性能, 可靠性与开发的复杂度间作取舍. 从多个微服务取数据, 而生成报表的设计方案, 主要是参考: Enterprise Integration Patterns; Hohpe and Woolf. A. Database Pull Model (Shared DataIntegration Style): 直接至各微服务所拥有的数据库中获取数据, 并写

互联网保险O2O平台微服务架构设计

关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架 构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹 果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而 小公司发展到大公司的过程,一般也伴随着系统不断优化的过程,而不断优化往往不会重

微服务架构设计 (一): 核心概念

微服务设计是架构设计. 所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程.而应该是一个考量各方因素下的一个决策的过程. 所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念? I. 分布式 (Distributed): 微服务与微服务间分布式调用最主要的概念便是: protocol-aware heterogeneous interoperability; 各微服务可各自拥有自身的 platform (Java,C#, Scala-等等), 但, 各

微服务架构设计(四):提升微服务分布式远程调用的可靠性与性能

在分布式微服务的架构下, 架构师往往面临著可靠性与性能间的抉择. 当来自某个微服务外部 Client 的远程调用, 要求微服务处理一购买 100 张股票的订单时.假如: A.  架构师所设计的微服务外部 Client 远程调用的 Time Out 时间是 2000 ms. 但, 此次微服务外部 Client 远程调用.微服务成功处理这 100 张股票的订单并送回一确认成功的信息到微服务外部 Client 时, 共花费了 3000 ms.所以, 微服务外部 Client 会误认为, 先前所发送的请

学霸君基于Docker的微服务架构设计

以下内容根据演讲PPT以及现场分享整理而成. 今天主要分享的是我们在实践微服务架构或者容器架构过程中踩过的坑,对于致力在容器技术方面进行探索的同学会有很大帮助.本次将站在整体的角度,分享如何去运维整个线上系统,如何看待整个微服务的架构.微服务能带来什么帮助以及微服务又有哪些缺点,还有重要的一点就是微服务架构如何去落地实施.虽然阿里云这样的服务商为我们做了大量的工作,但是将微服务架构真正地落地实施还需要做很多的工作.而对于任何技术而言,都是存在优缺点的,微服务架构也不是救世的良药. 一.学霸君的发