《从单体架构向微服务架构转型问题.docx》由会员分享,可在线阅读,更多相关《从单体架构向微服务架构转型问题.docx(13页珍藏版)》请在三一办公上搜索。
1、使用微服务架构方案能解决企业面临的很多挑战,而且目前微服务架构的框架都比较成熟,例如Springc1.oud或者dubbo在各大互联网平台都有成功案例,但看似简单的框架在实际开发过程中会面临很多问题。本文整理了企业从单体架构向微服务架构转型的中的设计难点何题.问题一:企业从单体架构往微服务架构转型怎么启动?这是大家比较关注的问题,企业打算转型微服务,但是真正的实施后发现又很难。其实微服务架构转型不仅仅是门技术活,更主要的的是组织结构和技术转型的结合,其中组织机构转型是起步的首耍条件,包括统一思路和充分培训。(1)思想统一当准备要实施微服务的时候首要条件就是获得高层的认可,因为涉及到组织结构的调
2、整以及后续人力资源的增补,比如在单体应用中其组织机构包括开发部、测试部、运维部,DBA部,每个部门各司其职由高必统一指挥,看似很非常合理的组织结构,但是在项目或者迭代实际过程中会花费大量的时间去跨部门沟通,形成了孤岛式功能团队。总仇克下所示,所以如果没有高层参与那么组织架构就不会调整。(2)充分培训微服务开发关注点:微服务架构的开发人员具备“精”、“气、“神,的特质.否则在后续发展阶段一定会出现各种难题.“精”是指熟悉业务,熟悉选型的开发框架,“气”是指大家的思想认知一致,能锅在一个频道上对话,“神”是指需要了解其理论知识,明白为什么需要这样而不是那样。微服务在开发设计过程中需要关注以下点:一
3、份瓦准代码多份部署(dep1.oy):程序部署需要做到和环境无关,不然要改动任何一行代码,如图2-3图2-3测试环犍显式声明依赖关系:通过依赖清单,确切地声明所有依赖项(例如MAVEN依赖),新进开发者简化了环境配更流程“做产品”而不是“做项R在环境中存储配置:所要求的代码和配理严格分离,配践可以完全不一样,但是代码必须是样的,配置和代码无关去中心化”地治理技术把后端服务当作资源:后端眼务是指程序运行所需要的通过网络调用的各种服务如数据库,MQ.缓存等。例如在不进行任何代码改动的情况下,聘MySQ1.数据库换成第三方服务严格分离构建和运行:构建阶段是指将代码仓库转化为可执行包的过程,发布阶段会
4、将构建的结果和当前部署所需配置相结合,并能够立刻在运行环境中投入使用,如回滚,运行阶段是指针对选定的发布版本,在执行环境中启动一系列应用程序进程无状态进程运行应用:运行环境中,应用程序通常是以个和多个进程运行的,任何需耍持久化的数据都要存储在后端服务内,比如数据库。问题二:微眼务中所谓的服务到底如何拆分,服务拆分到什么粒度算好的服务?在该服务拆分之前首先给服务做个定义:服务是分布式架构下的基础单元,包含了一组特定的功能,微服务拆分的方式没有明确标准,可谓说是T人口指每个人对于服务拆分理解程度和拆分尺度都不一样,有的团队按每个接口一个服务。一般来说我们在拆分的时候会结合理论知识和拆分原则来综合考
5、虑:1)微服务拆分的理论指导团队规模大小一般来说5-7个人一个小组比较合适,因为沟通效率和团队可扩屣性都能得到保障。如果一个团队人数过少的话,本来应该是多人开发的服务最后由1-2人来开发,会导致本来设计好的服务拆分逻辑最后却都合并在个工程上做开发/,失去了做服务的意义。项目交付周期尽可能缩短项目交付周期短,把频繁需求变更的功能尽量独立成单独的服务,保证快速的迭代,还能满足快速上线的需求,缩短了项目交付周期,同时还能做到随时I可滚,风险变小,从而提高系统稳定性.变更影响范围一个业务迭代功能点,尽量不要分布到多个微服务中,尽量将关联的实体对象存十个微服务,避免分布式事务,比如把20%经常变动的部分
6、进行抽离,80%不经常变动的单独部署和管理“吞吐量大小频繁访问,吞吐量大的服务,尽量独立微服务,方便扩容,能够有效地提高资源利用率。2)服务拆分原则i内聚低耦合高内聚低耦K是软件工程中的概念,在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。但是在微服务拆分中同样适用,服务拆分的个准则是高内聚低耦合。从功能粒度来看,高内聚即每个服务尽可能只完成一件事(最大限度的聚合);低耦合即减少外部服务依赖,尽量避免服务再调用服务。从数据库角度来看每个服务单独使用独立的数据库,外部如果需要使用数据必须通过接口调用。以业务模型切入有了岛内聚低耦合的前提,那么可以通过业务线来做拆分,比如用户、商品、订
7、堆、评论都拆分为独立的服务。把相关的业务都聚合在同一个服务中,这样也避免了瞪库所带来数据致性的问题。有可能以业务模型切入的方式初期阶段会比较粗,但是可以通过后续的迭代频率和吞吐量大小的指标再来衡疥是否需要继续拆分。问题三:分布式事务怎么解决?旦完成服务拆分,就会涉及到分布式事务,在谈数据致性要求的时候有2个非常重要的理论即CAP定理和Base理论:CAP定理:C表示一致性,也就是所有用户看到的数据是一样的,A表示可用性,是指总能找到一个可用的数据副本,P表示分区容错性,能够容忍网络中断等故障。BASE理论:BA指的是基本业务可用性,支持分区失败,当分布式系统出现故障的时候,允许损失一部分可用性
8、,例如在电商大促的时候,对一些非核心旋路的功能进行降级处理来提高系统的可用性,S表示柔性状态,允许系统存在中间状态,这个中间状态不会影响系统整体可用性。比如,数据库读写分离,写库同步到读库(主库同步到从库)会有一个延时,E表示最终一致性,数据最终是一致的,例如主从同步虽然有短暂的数据不一致情况,但是最终数据还是一致的。在实际中可以通过本地事务和发送MQ消息这种柔性事务方式来解决分布式事物所面临的问题,既能保隙服务的稳定性又能保幽调用效率的高效性,针对MQ可以使用Apachc的RockctMQ所提供的事物消息和本地事物表结合。问题四:微服务框架选型?在选择微服务架构框架的时候,都在讨论目前主流的
9、微服务框架Dubbo以及SpringC1.oud.Dubbo出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司,只需要通过spring配置的方式即可完成服务化,对于应用无入侵。设计的目的还是服务于自身的业务为主。SpringCIoud是大名鼎鼎的Spring家族的产品,专注于企业级开源框架的研发。SpringCIoud自从发展到现在,仍然在不断的高速发展,几乎考虑服务治理的方方面面,开发起来非常的便利和简单。这2种开发框架各巨头互联网公司都有深度使用,所以选择任何一套框架都不会成为技术的瓶颈,关键还是看团队熟悉哪种框架,选择最擅长的,而不是去跟风。问题五:微服务架构下
10、网关的必要性以及在网关下做限流、熔断、降级等操作在谈到网美的时候,首先需要确认下目前微服务的业务线有几条,如果只有单一的业务线,那么有没有网关意义不大。其实网关可以理解为一个反向路由,它屏蔽内部细节,为调用者提供统一入口,接收所有调用者请求,通过路由机制转发到服务实例,同时网关也是“过流器”集合,可以实现一系列与业务无关的模切面功能,如安全认证、限流熔断、日志监控。网关工作原理协议转换:将不同的协议转换成“通用协议”,然后再将通用协议转化成本地系统能够识别的协议,例如把http协议统一转换为dubb。协议。链式处理:消息从第个插件流入,从最后个插件流H1.每个步骤的插件对经过的消息进行处理,整
11、个过程形成r一个链条.优势在丁它将处理请求和处理步骤分开,每个处理的插件,只关心这个插件上需要做的处理操作,处理步骤和逻辑顺序由“锭,来完成。异步请求:所有的请求都会通过AP1.网关访问应用服务,无论业务量如何变化,网关的吞吐量要保持稳定状态.假如把网关的请求看成一次K)操作的话,处理请求的线程,从接受请求开始直到服务端返回响应,都是阻塞状态。操作系统所能承载的线程数是有限的,如果多个线程都处在这种状态,会导致系统缓慢。异步请求是指每个请求访问网关的时候,会被包装成个事件,CPU内核会维持一个监听器,不断轮询请求事件,请求的线程不用一直等待数据的返回。它在请求完毕以后,就直接返回了。网关限流、
12、降级网关的熔断、降级是针对接口而言,可以选择hystrix或齐Sentine1.来做服务包括,一般来说需要具%以下设置:设置错误率:可以设置每个服务钳误率到达制定能围后开始熔断或降级:具备人工干预:可以人工手动干预,主动触发降级服务:设置时间窗口:可配置化来设置熔断或者降级触发的统计时间窗口:具番主动告警:当接口熔断之后,需要主动触发短信告知当前熔断的接口信息;问题六:超时时间如何设置?微服务中存在次接口调用涉及到多个依赖服务,每个依赖服务的耗时乂不一样,所以设置怎么样的超时时间非常有讲究,首先必须要有一刀切的态度,即每个接口的响应时间不能超过阀值(比如I秒或者2秒),一方面提升用户体验,另外
13、一方面也是增加系统的稳定性。如果调用链路比较深的,则需要把加必要链路通过发送MQ消息的方式解耦,其次通过并行调用的方式来降低系统的响应时间.总的来说超时时间一般不会超过1秒,如何优化到一秒,需要从系统的全局考虑,而不是只关注某一个点.问题七:熔断设计需要考虑哪些点?在进行服务化拆分之后,系统中原有的本地调用就会变成远程调用,这样就引入/更多的复杂性.比如说服务A依赖服务B这个过程中可能公出现网络抖动、网络异常,服务B变得不可用或者响应慢时,也会影响到A的服务性能,甚至可能会使得服务A占满整个线程池,导致这个应用上其它的服务也受影响,从而引发更严重的雪崩效应。需要针对如下几项做了个性化配置:错误
14、率:可以设置每个服务错误率到达制定范围后开始熔断或降级:人工干预:可以人工手动干预,主动触发降级服务:时间窗口:可配置化来设置熔断或者降级触发的统计时间窗口;主动告警:当接口熔断之后,需要主动触发短信告知当前熔断的接口信息;目前市场上可选择的产品例如:HywriX或者SemineI做服务熔断和降级.这里推荐下Sentine1.,不管是Dubbo还是SpringCIoud只要使用官方给定的依赖即可快速接入。问题八:微服务架构的业务系统众多,那么数据的致性怎么保障,数据的隔离机制如何实现等等?当前做服务架构的业务系统越来越多,无论是做缓存场景,还是内存数据库场景,rcdis的使用非常普遍,但是每套
15、业务系统都部署一套rcdis集群,相当浪费资源,而且,考虑到同城和异地的信息系统建设,费用也相当之高,是否有机制可以类似中台一样,建立一个统一的redis平台,提供各种场景的服务?那么数据的一致性怎么保障,数据的隔离机制如何实现,性能如何评估等等?答I:(1)首先统的redis中心是很“技术因为你要个强大的技术人员或团队:(2)为了保证一致性,rcdisdustcr读取数据是从master上读取数据的,这样可以保证数据的一致性,当然,性能也就差了:redis主从模式,写master节点,异步同步SIaVe节点,读从SIave上读取数据,读性的提高了,但致性难以保证。这也就是门德尔不可能三角中的
16、CAP原则中,保证P的同时,CA不可能同时满足.no1.iih_queue.png在模块化单体中引入消息传递的H的是什么?这样设计系统可以使模块之间松耦合和独立。在项目成熟后,你在开始时增加的史杂性是合理的。将模块提取到微服务中我们决定从单体系统迁移到微服务。因为我们以模块化的方式构建了系统,所以迁移的关键在于将一个模块提取到一个新的进程中。你应该在服务前面引人个反向代理,来路由进入的流量。这将隐藏微服务系统的实现细节,不让客户端应用程序知道。新的微服务需要连接到消息总线,但我们不需要在代码中做任何改变。使用消息传递在模块之间进行通信简化了迁移过程。这可能让你想起事件聊动架构。如果你使用方法调
17、用来实现模块间通信,你必须将这种实现替换为通过网络的HTTP调用.因为你现在正在构建一个分布式系统,之前的方法调用实现将无法工作。你还需要考虑认证,容错等问题extraciing_m(x1.u1.es.pnQ从单体系晓中提取模块会用新微服务的功能替换I日系统的所有功能。这个迂移到微服务的过程遵循了榕树模式。总结思考从单底应构迁移到微服务的最大障碍是糊合。耦合是变更的阻止者。因此,这是你需要解决的第一件事。你需要在数据库层面和代码中的组件间解决耦合。以模块化的方式构建系统可以从开始就避免这些问题。这就是为什么模块化单体是一个很好的方法。你可以在系统中识别有界上下文,并将它们用作单体中的边界。在单
18、体中正询划分边界要容易得多。迁移到微服务就是将模块提取到独立服务的过程。当然,你仍然需要考虑安全性和容错性,因为现在你有r一个分布式系统.当谈论抽缭的架构时,可能难以理解,但在讨论概念性解决方案时却是很成要的。从单体架构升级到微服务架构的心得体会和建议企业面临的微服务升级困境在做服务盛行之前,很多企业应用都是基于单体架构的研发。但随着技术的不断发展,如今很多企业可能都面临着如何将自己的总体企业应用进行微服务升级改造的问题。怎么拆?要想成功的将一个单体应用完美的拆分成微服务是一个巨大的工程,如何拆分过细,会造成系统的维护成本过高,从而导致失败。拆分注意事项:根据业务之间的陕系是强关联还是弱关联?
19、比如电商模块和活动模块,彼此之间是一个相对独立的业务,就可以初步进行粗略拆分。然后电商模块和活动模块之间的调用从原来的本地方法调用到进程与进程之间的调用远程调用方式有:.种:I.我们可以通过SpringcioudOpcnFcign聚合API实现,如果是初创公司,人员不是很充足建议使用这种。值得注意的是,SpringcioudOopenFeign是可以单独使用的,并非必须使用Eureka或Zookeeper注册中心那种聚琐方式。相对而言,如果使用最衡化方式,那么使用NginX作为网关和负载均衡是比较合适的。另外,不建议使用OkHuPOiCnt或者ReStTCmPk1.tC来实现微服务与微服务之间
20、的远程调用,因为如果你这么做,会需要额外处理很多不必要的东西,比如数据的序列化和反序列化,异常的处理等等。2 .也可以通过使用基于rpc协议的gRpc或者SPringC1.oUdA1.ibaba,适合有一个比较完整的团队来做。3 .也可以通过消息中间件,对于些实时性不是很强的,可以延迟处理的,可以考虑使用这种方式,实时性强的建议前两种。拆分注意事项二:面向接口,一部分一部分的拆,而不是一下子把项F1.全部重写。去些企业直接把所有项目全都重写,改造微服务,这种成本说实话超级大,实际上很不现实,这么玩一定会玩死的。因为来自BRD(业务需求)和PRD(产品功能需求)需求一直在不断进行更新迭代,同时对
21、两套系统进行开发迭代,成本太高。所以种好的方式是将项目的代码使用设计模式进行梳理,比如面向接口编程,一个接口多个实现类,一个是基于本地实现,一个基于远程调用,这样做的一个好处就是可以慢慢的换血,对系统的影响最小,一旦远程调用方式发生紧急问题,只需要切换本地实现类即可,当远程调用实现类的实现方式成功稳定运行后,就可以慢慢去掉本地方法的实现。123拆分注意事项三:使用持续集成我们知道一旦将企业的单体应用拆分成多个应用之后,如果还手动部署的话,那么耗时耗力,效率低下。因此最好尝试使用JenkinS或其他方式实现自动化构建部署,这样我们才有最大的精力专注了业务.当然持续集成也大体有三种方式,一种是持续
22、集成构建jar包的方式,如果是初创公司,人员配备比较少,那么建议最好首选使用第一种持续构建jar的方式。因为这种方式迁移成本最低.另外一种是容器化成docker镜像。如果人员规模比较大,专人专职,分工明确,可以考虑使用,当然如果使用这种方式,班佳时间是引入K8S进行容器编排。只是这种相对来说,对于很多企业来说,成本比较大,需要有专人对K8S和容器编排方面有比较深的了解.还有一种是基于云托管这种相对于部署和编排全部交给云处理,精力可以放到业务上,公司不差钱可以号虑这种方式。1.2.4拆分注意事项四:日志处理由于传统的单体应用拆分成微服务后,日志将会变得混乱起来,每个微服务假如都有dcv.tcst
23、.uat.prod环境,那么系统谢用一旦出现异常,想要排查,如果涉及的微服务不多还好,如果微服务很多,那么就简直是个灾难。解决这种方式的一种比较好的解决方案是集成E1.K/EFK.关于E1.K的大名,相信大家耳熟能详,肯定知道E就是EIcastiscarch1.1.就是1.OgStaSh.K就是Kibana.其中,1.ogStaSh用于采集收集日志,ES用于对数据进行处理,建立例排索引.构建交询AP1.K则作为可视化界面管理。但是实际上,如果真实开发过,你一定会/解到只使用E1.K是远远不够的“为什么?因为1.ogstash这个日志收集框架虽然功能强大,但是也很耗费服务器资源,所以种好的优化方
24、式是采用HIebea1.来采集日志。因为FiIeBea1.是一个轻量级的日志采集框架,耗费服务器资源最小,可用于快速采集日志使用。之后再通过1.ogstash进行日志初步处理,处理完成后交给ES.最后ES牛.成索引后,交给Kibana进行处理。当然根据实际业务的不同可能有不I可的组合,也可能会中间会引入APaChCKafka,ApachcPuIsar等。125拆分注意事项五:生成文档旦将单体应用拆分多个微服务之后,各个微服务之间的所有AP1.应该都集成Swagger,自动生成调用文档.这是因为,虽然我们有了EuCEFK的日志收集工作,但是对于微服务的测试仍旧一个难题。比如测试个业务流程,可能涉
25、及到多个微服务,写代码去挨着测试简直是一个灾难.所以,最好集成SWaggCr,比如一个业务流程,微服务A需要调用微服务B,微服务B需要谓用微服务C.微服务C调用微服务D.AB,C-D都没问题,B-C节点有问题,那么如果想测试B-C节点,那么你如果手动测试,可能需要构造很多参数,非常麻烦“1.2.6拆分注AW事项六:安全模块使用SPringSCCUri1.y+过浦器我们知道,如果使用了SWaggCr.不对微服务做权限检盼是很危险的。如果SWagger和App或后台的AP1.都使用过灌器,自定义权限验证,是相对比较麻烦的.因此,从开发最简单化方式来说,一种比较衡便的方式是SPringSBUri1.y基于Session的权限校效作为Swag即文档的权限拦截,而对于App或后台管理系统采用自定义过滤罂的方式来做个统一鉴权中心。每个微服务之间调用不需耍自己重写一遍鉴权逻辑,而是通过远程调用方式实现。当然,如果企业人员充足,技术开发时间充足,也可以将SWagger文档鉴权也弄到自定义权限验证系统里面也行。
链接地址:https://www.31ppt.com/p-7324501.html