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

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