微服务改造过程中那些必须重视的问题

news2025/7/19 11:34:44

“微服务”近几年尤其火热,各大厂都在进行微服务化改造和微服务建设,想享受微服务化带来的好处以便对自己的系统进行改造。分布式实验室特约记者李鹏采访了广州轻阅科技系统架构师陈珙,就微服务与SOA的区别与联系、企业引入微服务会带来的问题以及解决方案和陈珙自己的工作经验进行了交流。

李鹏:谈到微服务都不可避免的会提到SOA,请问微服务与SOA有区别与联系?分别适用于什么场景?

陈珙:果然一谈到微服务,SOA也绝对不会避而不谈。首先,对于这个问题我也曾经思考与总结过的,我的看法跟大多数人百度、Google到的那种看法并不一样,下面我将从两者的发展史、两者的出发点与核心思想进行阐述。

SOA与微服务的关系,我从多个方面的资料梳理后,总结出有这样两种看法:

  • 微服务是SOA的最佳实践 (出自维基百科)—— 微服务是SOA的演进版,粒度更细,基础设施去中心化。

  • 微服务拒绝SOA的标签 (出 Martin Fowler 的《Microservices》原文)——微服务与SOA,是两个完全不同的架构风格,只不过刚好长得像。

首先是发展史,这里我整理了微服务发展的小历史。

时间

事件

2005年

Peter教授在Web Servces Edge大会提出了“Micro-Web-Services”

2007年

JuvalLöwy在他的著作与演讲建议用服务构建系统,并意识到细粒度因此扩展了WCF。

2011年

一个软件架构工作组在威尼斯附近举行的软件架构师研讨会上使用了”Microservice”来代表这种架构模式

2012年

Jame Lewis针对微服务概念在某大会发表了演讲

2014年

Jame Lewis和Martin Fowler合写了关于微服务的一篇学术性文章

从上文我们可以总结出三个核心关键点:

  1. 微服务的起源最早追溯到2005年;

  2. 微服务不是由 Martin Fowler 他本人创造的;

  3. 那篇举世闻名2014年写的《Microservices》原文是由 Jame Lewis 和 Martin Fowler 他们两人共同合作编写的。

虽然说微服务架构并非 Martin Fowler 所创造的,但是称《Microservices》这篇文章是推动微服务的崛起的缘由,一点都不为过,而 Jame Lewis 和 Martin Fowler 两位对微服务的盛行起到了非常关键的作用。

我相信不少同行讨论微服务都会拿维基百科的定义作为标准(维基百科仍然写着微服务是SOA的一种变种),不得不承认,微服务当时的出现就是作为一种轻量化的解决方案,用来解决SOA的一些诟病的,但是随着微服务的这些年的发展与蜕变,渐渐的脱离了SOA的标签,成为了一种独立的架构风格。

因此在2014年 Jame Lewis 和 Martin Fowler 合作编写的《Microservices》其中一段写着微服务倡导者拒绝SOA的标签。因此我认为维基百科的定义已经过时了。

接着说两者的出发点与核心思想,我认为,要看清楚它们关系的本质,就得从两者各自的处理场景目的出发。

首先从微服务角度出发,因为单体应用的大而全的高耦合与臃肿,随着业务的发展迭代的时间越久,就会有各种各样的问题,因此通过把应用拆成了多个“小”的服务,这里使用到了化繁为简、分而治之的核心思想,解决原有单体的“痛点”和“难点”。

接着从SOA的角度出发,在当时那个年代,希望把各种异构的系统给整合起来,这些异构的系统,有可能是从其他地方买的,也有可能是研发的,也有可能是找外包做的,因缘由存在各种不确定性,所以希望通过一个“聪明的”ESB解决所有的“愚蠢的”问题,也是因此ESB的高复杂度,导致当年SOA那会只是炒得火热,却无法普遍落实。

总地来说,微服务以拆与约定作为出发点,而SOA是以整合与配置作为出发点,所以我个人认为从它们的出发点与目的的角度出发,直接决定了它们在本质上是完全不同的架构。 所以我更加倾向于《Microservices》原文提到的看法,微服务的倡导者拒绝SOA这个标签的。

以上就是我对SOA与微服务的关系的一些见解。

李鹏:团队引入微服务技术会不会带来新问题?比如会带来什么新问题?应该怎么解决?

陈珙:引入微服务的话,从我的经验来看还是会带来不少的问题,我自己还是总结了一番,用一句话概括:两文化与一思维。 自动化文化、可观测性文化和分布式系统思维。

首先是自动化文化,有些人觉得疑惑,自动化这种能给团队省时省力、减少重复工作量、增加幸福度的技术难道还有人或者团队会抗拒的?是的,还真的有。

我曾经就接触过几个团队的Leader,他们的团队都是推行自动化失败了。 失败的原因就在于成员不配合,成员拒绝配合的理由是:这么多框框条条很麻烦麻烦、没有自己亲手去做总觉得机器不靠谱。

作为已经使用过自动化的其他同行来看,这样的思想完全觉得不可思议,但是我却可以理解,大家回忆下自己是否曾经对没使用过的框架与技术引入到生产同样会产生“恐惧”、“担心”,是的,从某角度来看这是“谨慎”,但是过于谨慎了。

重新回到话题,从上面可知,统一团队的目标一致性是有必要的,从另外的角度来看,自动化还需要团队、项目的流程的标准化、统一与约定,任何的技术都无法脱离了业务与团队而去讨论应该如何去实施。

作为技术领导者推行优良的方案,是我们的职责之一。如果团队成员无法配合,导致推行受阻,我们一共有三种应对策略:激励、考核和逐步试行。如果有条件的公司可以设置奖金激励,如果有绩效考核的,可以将自动化的实施纳入考核目标,如果这俩都没有,那就选取团队里愿意改变的同事牵头试行,假如使用过后都说好,那么会更有说服力。

其次是可观测性文化,如果说自动化是给团队带来稳定性,减轻工作量的,那么可观测性就是提高团队对系统运作的信息量。 建立可观测性的这项工作,虽然无法直接给系统带来健壮性,但能够使我们通过这些信息充分地了解到系统正在运作的情况,以至于最大程度地做出最合适的定位、判断与决策。

在单体应用的场景下,我们也是需要可观测性的,但是单体的架构相对简单,项目调试也更加便捷,无论是从复杂度还是规模的角度来看,单体跟微服务相比都要低不少,也因此单体对可观测性的需要,相比于微服务显得没那么重要。

而我们只要进行了微服务实施后,因为应用被拆分成了细粒度,从而导致了架构从量变引起质变,这个时候可观测性的作用在微服务场景下被“无限放大”,也因此我们利用“可观测性”,给与我们提供应用与服务器的监控、快速跟踪与问题定位的功能。

可观测性的三个要素日志、跟踪、指标。 我们在工作中只有灵活结合这三者,才能提高我们对系统运行情况的信息量,信息量越高思考的越是更加全面,才能尽可能地减少“不知道问题出在哪”的状况,所以当我们不清楚具体发生问题的原因时,建议你侧重做一件事:就是尽可能想办法,提高我们对问题与系统的信息量。

在这里额外提醒一句,自动化与可观测性并不是必须跟微服务架构绑定,无论在哪里的业务,怎样的系统,在条件允许的情况,越早把这两者完善,那么长期收益则越高。

最后就是分布式系统的问题,这个问题又分为三个,幂等性、数据的一致性的读与写。

幂等性, 其定义是 相同的参数在同一个方法里,无论执行一次还是多次都会响应相同的结果。

对于查询和删除的场景都有天然的幂等性,那么我们考虑幂等性的处理,更多是关注于新增数据与更新数据。

新增数据缺乏幂等性,则会因为网络抖动导致请求重试或者是客户端重复点击,而引发的数据写入重复,其解决方案也相对简单,只要从客户端生成主键传给后端API就可以解决,在这里得注意一点,只有请求成功或者主动刷新才会重新生成主键。

更新数据缺乏幂等性,主要会造成两种情况,数值错误自增和ABA问题。首先,数值错误自增,可以结合事务凭据与新增幂等性的方式解决。

而ABA问题,解决方案相对简单,可以在更新操作时带上版本号判断进行解决。

ABA问题: 对某条记录先更新了A数据,紧接着又更新了B数据,理应是B是最新的,但是因为其他客观原因使接口Retry或者别的问题,导致A数据再次请求覆盖了B。

幂等性处理方案

场景

问题

方案

新建数据

重复创建

由调用端预生成订单号,唯一键约束

更新数据

ABA覆盖问题

添加版本号判断

金额自增

使用流水凭据

数据一致性读,其实说白了就是做数据关联,从我过往用的解决方案来看共有三种,应用层的接口聚合数据、把更新频率低的字段冗余存储、把数据库同步到一台服务器进行SQL联表处理,每种方式各有优缺点,我结合切身体会和过往经验,以表格方式整理呈现出来,你可以根据业务场景自行选择解决方案。

数据关联方案

方案名称

方案描述

优点

缺点

应用层数据聚合

分别调用查询API,在业务逻辑层组装,适用于简单的关联。

实现简单

该方案只能适合简单的查询过滤,以主表为驱动的关联

冗余设计(反范式)

在目标表添加冗余字段,适用于记录递增的,不适用于冗余字段更新频繁,实现起来简单,有扩展性问题

实现简单,以应用层数据聚合方案有更多的过滤条件

冗余的字段如果更新存在同步问题,该方案适用于更新频繁少的递增日志类数据

数据库从库集成

通过主从同步把相关表同步到一台服务器做跨库查询,适用于复杂查询、报表类的,有技术复杂度,从长远收益来看能应对多种场景

通过强大的SQL解决复杂的报表类查询

拥有技术复杂度,需要数据库主从处理

写的数据一致性,其实就是分布式事务,主流的方案有 TCC 、 本地消息表(基于消息可靠的最终一致性) 、 异步请求/回调。 其他的多数是基于以上几种方法的变种,例如RocketMQ的消息事务,就是TCC+本地消息表的变种。

分布式事务方案,用文字描述起来相对比较吃力,因此我通过流程图代替文字描述展示给大家。下方表格是我对这三种方案的优缺点与使用场景的总结。

分布式事务方案

名称

场景

优点

缺点

异步请求/回调

跨网络环境、同网络环境

实现简单

强业务

TCC

跨网络环境、同网络环境

有现成的框架、实现简单

强业务

基于消息可靠的最终一致性

同网络环境

有现成的框架、通用性强

中间件依赖

以上就是我所经历微服务的引入后所需要解决的一些问题与方案。

李鹏:工作这么长时间,你在微服务改造过程中有没有遇到特别大的困难,都是怎么解决的?

陈珙:这个问题勾起了我的痛并快乐着的回忆。俗话说得好,万事开头难,因此第一次做微服务的实施经历给我带来了非常深刻的印象。

第一次做微服务是2019年,受老领导的邀约加入了新公司并以微服务架构风格来从零开始搭建新系统。这也是我工作多年以来,第一次以技术负责人的身份,从零开始组建自己的团队,同时从零开始开发系统,而且还是得用当时对我来说“陌生的”微服务架构。

我面临的第一个难题就是我的运维能力。 如大家所了解的运维就是微服务架构的地基,如果运维能力有限那么微服务搭建的规模与完整度自然也会受到影响。在当时来说,我以往工作经验,接触运维还是比较少的,因此在实施微服务的同时不得不进行恶补运维的知识,像容器化、Linux基础、网络知识、自动化等等。

因此,当时我买书与课程应该属于我这么多年以来的最疯狂的一次,每天早上在地铁上学习,下班后回家也会带着问题找资料,现在回想起来也非常的充实。

第二个难题就是.Net的技术生态。 .Net并没有一套像Java一样比较成熟的、默认的方案,因此在.Net微服务的技术选型上花了不少的时间与精力,主要的问题体现在到各种框架与中间件之间的集成,很多时候还要自己看源码改扩展。

从现在看过往,真正允许我们.Net选择的框架与中间件并不是很多,因为很多中间件是不提供.Net SDK的。而且在当时来说,在技术社区里也没多少人会分享自己.Net微服务实战的心得,因此对于我们不得不摸着石头过河,无论觉得行还是不行都得尝试一遍,最终总结出适合自己的技术选型。

事后,我也希望后来人避免踩坑,在博客园写了个《.Net微服务实战》系列,在给自己做总结的同时也分享给有需要的同行。

第三个难题则是微服务的划分。 大家可能都知微服务拆分的其中一种方式是按照业务边界,DDD的战略思想与事件风暴被我引入到了工作当中,不得不说DDD战略的化繁为简与微服务的分而治之这两种思想是非常契合的。

但并不是说这种方式在任何时候都完全适用,因为我们整个团队都是新组建的,业务对我们来说都是全新的,因此不存在领域专家这一个说法。在整个工作当中会存在很多不明确的业务,一般这个时候我们是不做任何服务的拆分处理的,只有随着我们对业务的熟悉度越来越了解,才慢慢地再去重新识别业务边界从而进行拆分。

虽然说微服务减轻了开发人员的开发负担,但是对于架构师来说是一件非常考验综合能力的事情。

李鹏:请给新手提一些建议,微服务改造应该怎么上手?改造过程中需要注意什么?

陈珙:在上个问题,我拿了自己当时作为新手时实施的经历,大家也可以参考下。那么接下来我会总结一下,从多个方面出发进行分享。

从硬技能角度出发。 大多数微服务设计者是从开发过来的,因此开发技能无需过多担忧,但是运维技能肯定对于他们来说是偏弱的,还是那句话运维是架构的地基,所以运维的基础能力得优先提高。

这里得注意一下,并不是说需要大家的运维技能一下子成为专家级的,这样也不现实,但是起码得够用,能和专业运维岗无缝沟通,因为作为团队的技术领导者,很多时候得领先团队做技术调研、技术选型与评估,而拥有这些基本的能力,能让自己更加顺利的衔接好团队并完成工作。

从软能力角度出发。 如我上面所说的,微服务非常考验架构师的综合能力,那么沟通与管理也包含在内。微服务的实施是需要整个团队配合的,每个人都有自己擅长的专业与领域,因此团队之间的能力是互补的。

从康威定律可以了解到,团队里成员之间的比例与技能是跟系统架构相匹配的,那么架构师作为团队的衔接点、承上启下的角色,更加应该有良好的沟通协助方式与大局意识。

想要一个人承担所有的角色搭建整套微服务架构,我认为是不现实的,特别是对有一定规模的老系统进行改造,里面会有数不尽的“坑”,脱离了业务进行架构设计无疑是“耍流氓”,技术服务于架构,架构服务于业务,业务服务于商业,这是一条不变的真理。 软件工程是一项多人协作的工作,每个岗位都有他存在的价值与意义,这里没有个人“英雄主义”。

从实施的流程出发。 微服务里用了不少中间件,例如:API网关、服务注册中心、负载均衡器等等,在不是特别必要的情况下,可以稍微延后这些中间件的搭建,我们可以先把重心放到可观测性与自动化的搭建上。

自动化与可观测性在微服务架构中有着无法代替的重要性。 因为在微服务架构中由于服务的拆分慢慢的从量变引起了质变,原本在单体架构中显得不重要的流程与问题会逐渐的被放大。当然了,自动化与可观测性并不是说得准备要微服务才应该着手准备,无论在哪种系统来说,能越尽早完善自动化与可观测性,那么收益就会越大,只有系统稳定了,不会每天被那些繁琐的维护工作占用过多的时间,我们才可以有时间与机会做更加有意义的事情。

从新旧系统改造出发。 新的系统使用微服务的难点主要在于第一次搭建微服务的“陌生感”,当你形成一套可复用模式后,后续第二次、第三次就如同“堆积木”。

旧系统的改造一般来说会比新系统的复杂点,主要的原因是旧系统是有稳定业务的,因此我们在对旧系统的服务拆分时更多的考虑的是,哪些业务模块相对耦合性低,可以优先独立出来,拿旧系统试错还是有一定的风险与成本,因此我们尽可能减少影响面,适当的还要考虑功能的兼容性与发布的可逆性。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/9098.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Vue2:官方路由 Vue-Router 3.x

前端路由 前端路由:根据不同的url地址,页面上展示不同的内容(根据url地址的不同分发到不同的组件。) SPA 介绍 spa 是 single page application 简写,意思是单页面应用程序。Vue 适合开发 spa 类型的项目。 优点&…

Django 所带的用户auth_user的坑点,authenticate()校验一直为None,校验与创建所遇到的问题整理与解决

整理一下django中用户模块自定义model后登录的一些问题: 网上的报错解决不是万能方案,主要还是要自主分析原因,有的是有用但是导包之类的也要看清楚因为自己修改了所以有所变得,不自定义的话又不太好用。 在项目初期决定使用auth…

鸡卵白蛋白偶联脂多糖(OVA-LPS),麻黄多糖修饰卵白蛋白(PB-OVA)

产品名称:鸡卵白蛋白偶联脂多糖 英文名称:OVA-LPS 用途:科研 状态:固体/粉末/溶液 产品规格:1g/5g/10g 保存:冷藏 储藏条件:-20℃ 储存时间:1年 脂多糖(Lipopolysacchar…

第四站:数组

目录 一、一维数组的创建和初始化 1.数组的创建 (1)基本定义,创建方式 (2)经典的错误标准的零分 2.数组的初始化 3.一维数组的使用 4.一维数组在内存中的存储 二、二维数组的创建和初始化 1.二维数组的创建 2…

SpringBoot SpringBoot 开发实用篇 2 配置高级 2.2 松散绑定

SpringBoot 【黑马程序员SpringBoot2全套视频教程,springboot零基础到项目实战(spring boot2完整版)】 SpringBoot 开发实用篇 文章目录SpringBootSpringBoot 开发实用篇2 配置高级2.2 松散绑定2.2.1 问题引入2.2.2 松散绑定2.2.3 小结2 配…

MySQL学习笔记:模型2

序言 《MySQL45讲》 为什么表数据删除一半,表文件大小不变? 表数据既可以存在共享表空间里,也可以是单独的文件。这个行为是由参数 innodb_file_per_table 控制的: 这个参数设置为 OFF 表示的是,表的数据放在系统共…

错字修改 | 布署1个中文文文本拼蟹纠错模型

内容一览:中文文本错误的种类之一为拼写错误,本篇文章为利用 BART 预训练方法实现中文文本纠错功能的模型部署教程。 关键词:BART 中文拼写纠错 NLP 本文首发自微信公众号:HyperAI超神经 中文文本错误3大障碍:拼写、语…

Chapter9.1:线性系统的状态空间分析与综合(上)

此系列属于胡寿松《自动控制原理题海与考研指导》(第三版)习题精选,仅包含部分经典习题,需要完整版习题答案请自行查找,本系列属于知识点巩固部分,搭配如下几个系列进行学习,可用于期末考试和考研复习。 自动控制原理(…

第六节.常用Linux命令—chmod修改目录权限,组管理,用户管理

第六节.常用Linux命令—chmod修改目录权限,组管理,用户管理 1. chmod:可以修改用户/文件/目录的权限 1).命令格式: chmod(代表增加权限)/-(代表减少权限) r(可读权限)w(可写权限)x(可执行权限) 文件名/目录名 2.组管理: 1).终端…

年产5000吨饼干食品加工厂的工艺设计

目 录 摘 要 I Abstract II 第1章 绪论 1 1.1概述 1 1.2饼干的特点 1 1.2.1适宜大规模生产 1 1.2.2容易消化吸收 1 1.2.3食用方便 1 1.2.4营养价值高 2 1.3设计依据 2 1.4 设计范围 2 1.4.1 一般部分 2 1.4.2 重点部分 2 1.4.3 图纸 3 1.5设计指导思想 3 1.5.1 指导思想 3 1.5.…

org.activiti.validation.validator

org.activiti.validation.validator目录概述需求:设计思路实现思路分析1.ActivitiEventListenerValidator3.AssociationValidator4.validateAtLeastOneExecutable5.DataObjectValidator拓展实现参考资料和推荐阅读Survive by day and develop by night. talk for im…

【信号和槽】

前言 信号和槽是QT界面框架的一个核心特性,其重要性和MFC的消息映射机制一样。只要用QT开发项目,就一定会用到,所以必须100%熟练掌握,烂熟于心。 0x0 需要理解的概念 信号:特定情况下被发射的事件。鼠标单击按钮&…

基于复合粒子群优化的模糊神经预测控制的研究(Matlab代码实现)

🍒🍒🍒欢迎关注🌈🌈🌈 📝个人主页:我爱Matlab 👍点赞➕评论➕收藏 养成习惯(一键三连)🌻🌻🌻 🍌希…

boot+mp搭建版本踩坑记录

最近项目搭建中遇到的一些问题,涉及到 mp 版本 swagger集成等 文章目录前言一、引入mp启动报错1 相关配置2 报错 如下3 解决方案二、引入swagger1 引入的pom2 报错如下:3 解决方案三. 项目启动自动打开swagger页面总结前言 由于使用高版本springboot 导致集成遇到的一些问题 一…

Spring Boot+Netty+Websocket实现后台向前端推送信息

Netty 是一个利用 Java 的高级网络的能力&#xff0c;隐藏其背后的复杂性而提供一个易于使用的API的客户端/服务器框架。 可能在此之前你没有接触过&#xff0c;不过不要担心&#xff0c;下面我们通过一个消息推送的例子来看一下netty是怎么使用的。 1.添加Maven依赖 <!--…

动态代理静态代理

一、使用背景 将目标类包裹起来&#xff0c;对目标类增加一个前置操作和一个后置操作&#xff0c;比如添加日志&#xff0c;在调用目标类前、调用目标后添加日志。 感觉静态代理与动态代理的核心思想&#xff0c;都是根据目标类&#xff0c;拿到目标实现的接口&#xff0c;和…

【软考】-- 操作系统(上)

目录&#xff1a;操作系统&#xff08;上&#xff09;第一节 操作系统概述&#x1f384;一、操作系统基本概念1️⃣操作系统的五大部分&#xff1a;&#x1f38b;二、操作系统的分类1️⃣批处理操作系统&#xff1a;2️⃣分时操作系统&#xff1a;3️⃣实时操作系统&#xff1a…

STC51单片机28——跑马灯

//使用P1口流水点亮8位LED #include<reg51.h> //包含单片机寄存器的头文件 /**************************************** 函数功能&#xff1a;延时一段时间 *****************************************/ void delay(void) { unsigned char i,j; for(i…

Jetpack Compose 重写TopAppBar 实现标题多行折叠

没有效果图一律当水贴处理 效果动图 前言 想用composes实现类似CSDN的文章详细页面的标题栏 上滑隐藏标题后标题栏显示标题 compose.material3下的TopAppBar不能嵌套滚动 MediumTopAppBar 便使用了MediumTopAppBar一开始用着没什么问题&#xff0c;但是标题字数多了&…

一天完成react面试准备

什么是 React的refs&#xff1f;为什么它们很重要 refs允许你直接访问DOM元素或组件实例。为了使用它们&#xff0c;可以向组件添加个ref属性。 如果该属性的值是一个回调函数&#xff0c;它将接受底层的DOM元素或组件的已挂载实例作为其第一个参数。可以在组件中存储它。 ex…