从单体架构向微服务架构转型问题.docx

《从单体架构向微服务架构转型问题.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不可能同时满足.3）当然，也不是没有解决方案，但redis作为一个缓存数据库，并没有做的这么笈杂。现代分布式数据库中，使用mu1.tiraft架构.最大限度的解决了这个问题-maker是变化的，根据应用的不问不断的变化，I可时读永远从变化的muster上写入和读取。（4）redis也是有事物的，但只保证了一致性和隔离性，没有原子性，一致性上面说过了。因为redk本质上是单线程的，个个的去执行命令。这种顺序执行，隔离性是有保证的.答2：言选纠正卜.你对微服务架构的理解，在微服务架构F,要求每个原子服务的数据库、级存都是相互独立的，原因是当服务所依赖的数据库或者级存有问题只影响它本身的