微服务架构下的系统集成

2024-04-14 12:38
文章标签 服务 架构 系统集成

本文主要是介绍微服务架构下的系统集成,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

微服务架构相比单体架构而言的优点,可以列举出很多:服务个体更小,更内聚,业务职责更清晰,可复用性更强,可以独立部署发布等等;从软件开发的角度,灵活性和效率都会有很大的提升……

然而,微服务架构本质上是分布式系统架构,各个服务需要配合协同来完成产品的需求,业务数据的分散使得服务之间需要通过集成来完成协同工作,那么问题来了,集成要采用什么方式?要以什么样的原则进行?如何设计才能尽量保证不同服务之间数据的一致性?

混乱的实现

微服务架构下推荐使用REST作为服务间同步通信的方式,对于非实时需求,可以基于事件来实现异步协作。这个原则非常简单,也非常容易实现,然而仅遵循这个原则却很难让我们沿着微服务的道路走下去。一些号称微服务架构的系统,最初服务拆分并无太大问题,但随着逻辑的不断扩展,跨服务数据交换场景的增加,这个简单的原则就很难指引日常的决策,甚至引发了一些新的问题,举几个例子:

  • 服务循环依赖

在一些场景下服务A依赖服务B,会调用服务B的API,而在另外一些场景下,服务B也需要服务A的数据,也会通过调用服务A的API来实现。单从实现层面来看,按需获取数据,实现很方便,可以完成业务要达成的效果;但从长远来看,两个服务的耦合越来越紧,未来新增需求的实现成本会越来越高,成为技术债

  • 第三方系统集成实现到业务服务中

在一些业务场景下,当前产品需要的业务数据需要从几个第三方系统获取并进行整合甚至经过一些计算后才能使用,之前的一些项目在初期实现时,数据从第三方系统获取后,经过处理直接写入业务数据库,就把集成的代码直接写到业务服务中,看起来并没有太大的问题,只要代码上做好隔离就好了。但实际上,后期发生了一些棘手的问题让我们不得不作出改变:

  1. 一些定时触发的集成任务,每次只会在一个服务实例上运行,在运行期间可能会有大量的数据读取、计算、更新、插入等操作,会短时大量占用当前服务实例的资源,严重的情况下当前服务实例甚至无法正常对外提供服务
  2. 相似的集成以同样的方式集成到业务服务中,比如不同品牌的产品库存会从多个第三方系统获取,业务服务变的臃肿
  3. 集成方的一些变化直接影响到业务服务,比如API的升级,这种改变必须要重新升级部署业务服务才能完成
  • 集成接口不幂等

无论在第三方系统集成和内部服务的调用过程中,接口不幂等都会造成数据不一致的问题。最典型的场景是服务A调用服务B的接口更新或写入数据,服务B处理成功,但由于网络原因,服务A没有收到服务B的响应,服务A重试调用接口,此时,服务B由于接口不幂等返回异常的响应,导致业务流程无法继续下去

理想是丰满的,现实是骨感的,大多数的项目开始于满怀激情的整洁架构的梦想,而开发工作并不像想象的那么顺利,伴随着项目人员更替、交付压力大、人员能力不足等等,架构开始逐渐走向大家不期望的方向,技术债台高筑,攻城狮们疲于奔命的追赶进度的同时,只能望债台兴叹。

集成的原则

当问题发生时,架构师们都能第一时间站出来说这个设计太烂了,怎么能做成这样;事后诸葛是我们积累经验的重要手段,从高筑的技术债台,从疲于救火的线上问题,从接了新需求却找不到合理方案……我们一直在总结经验,为了避免再次摔倒在同一个地方,有哪些架构设计原则可以先行呢?

单向依赖

微服务拆分之初都定义了各个服务的上下游关系,我们可以定义上下游服务的依赖关系如下:

  • 下游服务可以直接依赖上游服务,下游服务可以通过上游服务提供的API同步对上游服务的数据进行读写
  • 上游服务不依赖下游服务,上游服务数据状态变化如果会对下游服务产生影响,可以通过发布领域事件,由下游系统监听事件作出对应的操作
服务间仅冗余引用信息

微服务的各个领域实体之间存在着各式各样的关系,当领域实体A依赖领域实体B的信息时,通常需要在领域实体A中保留一部分领域实体B的副本信息,那这份副本信息中该包含哪些信息呢?

举个例子,领域实体A是订单,领域实体B是客户,客户端每次查询订单信息时,都要求同时查出客户的姓名、性别和手机号码,将这3个关键信息冗余在订单的服务中就可以轻松满足需求了,一切听起来是那么的美好。

然而,这3个关键信息如果是可以变化的,那么问题就来了,如果领域实体B中的信息更新了,领域实体A中的信息要不要更新,如果不更新会造成数据不一致,如果更新无端增加了复杂度,而很有可能因此而产生循环依赖。

因此,在无法确定数据变化的准确情况时,在副本中只保留引用信息最保险,需要完整信息时可以通过引用查询相关信息。

为第三方系统构建外观服务

面对第三方系统集成,在系统集成过程中要考虑的更周全,一般情况下,我们无法控制第三方系统,一旦集成出现问题,需要沟通解决方案,排期开发,联调测试等等,修复周期很长。

另一个问题是第三方系统通常采用的技术栈或集成方式可能和我们的系统完全不同。比如它可能是个非常老旧的系统,提供的接口是基于XML的SOAP;再比如它可能无法提供API,只能通过导出文件到某个SFTP或发送邮件的方式进行集成……

为了让第三方系统集成产生尽量小的影响,我们倾向于构建外观服务来隐藏第三方系统实现的细节,通过外观服务对第三方系统的功能进行包装,提供和当前系统更加一致的集成方式。我们可以把外观服务和第三方系统看做是一个整体,那么第三方系统的集成对于当前系统内的服务来说,服务间的集成就可以和内部服务一样处理。而对于第三方系统集成相关的细节内容被隔离在外观服务中,第三方系统集成的变化,只需要修改外观服务就可以了。

集成接口实现要考虑幂等性

这个原则非常简单,但实现过程中非常容易被忽略,如果不在设计好的测试用例中,测试过程中也很难发现问题;多数情况下是到了线上,用户使用的真实场景才会发现问题,这时已经产生了业务影响。

因此在涉及集成的接口中,要特别关注,业务上是否要求接口的幂等性,接口不幂等的情况下业务是否能够正常的流转。

契约测试

服务提供的接口通常不只有一个消费者,不同消费者关心的信息往往可能也不一样,随着服务数量的增加,在没有契约测试的情况下,很有可能发生因为一个需求修改了当前服务接口的实现,而影响其他已有功能。而往往这个问题直到全面回归的时候才能完全发现,甚至可能发生因改动范围很小,回归不够,在上线前也难以发现。

契约测试可以很好的解决这个问题,一方面测试前置,尽早提供反馈,另一方面也起到了架构守护的作用。

小结

系统集成是分布式系统中一定会谈及的问题,而且是个大问题,因为它直接影响到当前系统的架构,一个微不足道的改动很可能就破坏了整个系统架构的原则,久而久之原则便形同虚设。

微服务架构也不例外,在缺少架构约束的情况下,只图一时之快的实现往往会葬送了微服务的优势,一个个微小的不合理改动会逐渐将整个架构大厦摧毁,所谓千里之堤,溃于蚁穴就是这个道理。

因此,在微服务架构设计之初,我们就要在团队内建立一些原则,明确系统间集成需要遵守的一些规范,并且在实践过程中定期review,必要时可以采用一些架构守护的辅助工具,来保护架构的健康度。

文/Thoughtworks麻广广
原文链接:
https://insights.thoughtworks.cn/microservices-system-integration/
更多精彩洞见,请关注微信公众号:Thoughtworks洞见

这篇关于微服务架构下的系统集成的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/903012

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

【区块链 + 人才服务】区块链集成开发平台 | FISCO BCOS应用案例

随着区块链技术的快速发展,越来越多的企业开始将其应用于实际业务中。然而,区块链技术的专业性使得其集成开发成为一项挑战。针对此,广东中创智慧科技有限公司基于国产开源联盟链 FISCO BCOS 推出了区块链集成开发平台。该平台基于区块链技术,提供一套全面的区块链开发工具和开发环境,支持开发者快速开发和部署区块链应用。此外,该平台还可以提供一套全面的区块链开发教程和文档,帮助开发者快速上手区块链开发。

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

基于SpringBoot的宠物服务系统+uniapp小程序+LW参考示例

系列文章目录 1.基于SSM的洗衣房管理系统+原生微信小程序+LW参考示例 2.基于SpringBoot的宠物摄影网站管理系统+LW参考示例 3.基于SpringBoot+Vue的企业人事管理系统+LW参考示例 4.基于SSM的高校实验室管理系统+LW参考示例 5.基于SpringBoot的二手数码回收系统+原生微信小程序+LW参考示例 6.基于SSM的民宿预订管理系统+LW参考示例 7.基于

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

【系统架构设计师】黑板架构详解

黑板架构(Blackboard Architecture)是一种软件架构模式,它模仿了多个专家系统协作解决问题的场景。在这种架构中,“黑板”作为一个中央知识库,存储了问题的当前状态以及所有的解决方案和部分解决方案。黑板架构特别适合于解决那些没有确定算法、需要多个知识源(或称为“专家”)共同作用才能解决的复杂问题。 一、黑板架构的组成 黑板架构主要由以下几个部分组成: 黑板(Blackboa

Golang支持平滑升级的HTTP服务

前段时间用Golang在做一个HTTP的接口,因编译型语言的特性,修改了代码需要重新编译可执行文件,关闭正在运行的老程序,并启动新程序。对于访问量较大的面向用户的产品,关闭、重启的过程中势必会出现无法访问的情况,从而影响用户体验。 使用Golang的系统包开发HTTP服务,是无法支持平滑升级(优雅重启)的,本文将探讨如何解决该问题。 一、平滑升级(优雅重启)的一般思路 一般情况下,要实现平滑