本发明提供了一种简单快速的微服务化方法，主要涉及微服务化和单体应用的微服务化改造，可以帮助非微服务的单体项目快速平稳地微服务化。
背景技术：
传统代码的框架将所有功能(例如对于一个电商系统的商品展示、商品下单、商品支付等业务)都打包在一个war包里，基本没有外部依赖，部署在一个j2ee容器(tomcat，jboss，weblogic)里，包含了do/dao，service，ui等所有逻辑。这种单块架构实现的软件系统随着业务规模的扩大，技术选型越来越困难，维护成本陡然增加，可扩展性和持续交付能力也变得更差，任何一个模块的失效都可能导致系统的整体崩溃，任何一个模块负载过重，都可能影响系统的整体稳定性。
为了解决这一系列弊端，微服务架构被提出。微服务不需要像普通服务那样成为一种独立的功能或者资源，他需要与业务能力相匹配，按照可重用的维度划分，将一组相关的功能组织在一起给消费者提供服务，每一个服务都以独立的进程运行，不同服务之间通过轻量的协议进行通信。微服务带来的优势有：
(1)规模小：微服务架构中，服务的规模较小，通常而言如果一个服务过大，就应当被拆解成两个或多个服务，这使得业务开发专注于保证单一服务的能力，这给服务的可维护性和可扩展性带来了好处。
(2)有界限：相关的功能会被整合到一个单独的业务单元中，以一个服务的形式实现。
(3)独立性：每个微服务独立运行，互不干扰。服务间仅能通过它们公开的接口进行通信。
(4)扩展性：基于微服务的系统可以持续跟进多变的业务环境，支持任何形式的修改。
(5)模块性：基于微服务的系统由独立的组件组成，各个组件共同为整个系统的行为提供支持，而不是由单个组件提供全部的功能。
(6)演进性：基于微服务的系统能够持续不断的演进，添加新的功能，保持可维护性。
虽然微服务带来了巨大的好处，但是由传统的的单体架构过渡到微服务架构绝非易事。首先我们需要对业务有非常清晰的了解，能够按照业务的维度将相关的一组功能划分到一起，然后要学习微服务框架并按照微服务架构的要求按照业务的划分维度完全重组代码，这个过程伴随着巨大的投入，而如何减少投入实现微服务化成为亟待解决的问题。
技术实现要素：
本发明的目的在于针对现有技术的不足，提供一种单体应用微服务化的方法。
本发明的目的是通过以下技术方案实现的，一种单体应用微服务化的方法，包括以下步骤：
(1)调用分析：通过分析打包文件的字节码，获取应用代码中类之间的方法调用关系，从而分析出应用中的调用链，生成以球表示类节点，箭头表示调用关系的调用图；
(2)模块拆分：对于步骤(1)生成的调用图，将所有的入度为0的节点作为入口，然后依次以入口为起点进行有向图的广度优先遍历找到所有的下层节点，并将该起点与此次遍历结果一起作为一个将要拆分出去的微服务模块，按照此规则将一个完整的项目分为多个微服务模块；如果同一个节点被不同的微服务模块共用则做出标识；
(3)框架适配：让微服务模块适配不同的微服务框架，每个微服务模块单独进行开发和部署，实现单体应用的微服务化。
进一步地，在模块拆分阶段后，进入人工修正阶段：用户根据调用图再结合自己对业务的理解对模块拆分的结果做出适当的修正，如果某个微服务模块拆分的过于分散，可以选择将相同和相近业务的几个微服务模块合并到一起，生成一个微服务模块；如果某个微服务模块过于庞大，则对该微服务模块进行二次拆分，生成多个微服务模块，保证每个微服务模块负责一个单一的业务。
进一步地，调用分析阶段中，利用类加载器的动态加载和开源的javassist类库获取应用代码中类之间的方法调用关系，从而分析出应用中的调用链。
进一步地，调用分析阶段是通过代码的调用逻辑来做分析的，完全不涉及系统业务。
进一步地，模块拆分阶段中，给拆分的每一个微服务模块设置不同的颜色，通过调用图可以直观看出将要拆分为多少个模块以及每个模块包含哪些内容。
进一步地，如果要将一个传统的spring开发的单体应用利用springcloud实现微服务化，将单体应用拆分为多个微服务模块后，将每个微服务模块转换为基于springboot框架的子模块，避免人工二次开发的巨大成本。
经过上述四个步骤，一个单体应用就可以被拆分多个独立的微服务模块，每个模块都可以单独的进行开发和部署，单体应用也实现了快速的微服务化。本发明可减少单体架构到微服务架构转化过程中的投入，降低开发的学习成本，帮助项目平稳过渡到微服务架构。
附图说明
图1是为调用分析阶段生成的调用图示意图，其中每一个球代表项目中的一个类节点，箭头代表不同类节点之间的调用逻辑，虚线框表示其中所有的内容都在同一个应用中；
图2是模块拆分后的示意图，其中每一个球代表项目中的一个类节点，箭头代表不同类节点之间的调用逻辑，三个虚线框表示原单体应用被拆分为三个微服务模块；
图3是人工修正后的拆分结果，其中每一个球代表项目中的一个类节点，箭头代表不同类节点之间的调用逻辑，两个虚线框表示原单体应用被拆分为两个微服务模块。
具体实施方式
本实施例提供的一种单体应用微服务化的方法，主要包括调用分析，模块拆分，人工修正，框架适配四个步骤：
调用分析：本发明方法在调用分析阶段通过分析提供的打包文件的字节码，利用类加载器的动态加载和开源的javassist类库获取应用代码中类之间的方法调用关系，从而分析出应用中的调用链，生成以球表示类节点，箭头表示调用关系的调用图。调用分析阶段是通过代码的调用逻辑来做分析的，完全不涉及系统业务。
模块拆分：对于调用分析阶段生成的调用图，将所有的入度为0的节点作为入口，然后依次以入口为起点进行有向图的广度优先遍历找到所有的下层节点，并将该起点与此次遍历结果一起作为一个将要拆分出去的微服务模块，按照此规则将一个完整的项目分为多个微服务模块，给每一个微服务模块设置不同的颜色，如果同一个节点被不同的微服务模块共用，则做出特殊的标识。
人工修正：在模块拆分步骤中，通过入口的广度优先遍历将整个项目划分为多个微服务模块，并给不同的模块设置不同的颜色，这时候的调用图就可以直观看出将要拆分为多少个模块以及每个模块包含哪些内容；人工修正阶段，用户可以根据调用图再结合自己对业务的理解对模块拆分显示的拆分结果做出适当的修正，如果某个微服务模块拆分的过于分散，可以选择将相同和相近业务的几个微服务模块合并到一起，生成一个微服务模块；如果某个微服务模块过于庞大，则对该微服务模块进行二次拆分，生成多个微服务模块。
框架适配：经过上面三个步骤后，就已经确定了单体项目微服务化的拆分结果，框架适配可以让微服务模块适配不同的微服务框架；比如要将一个传统的spring开发的单体应用利用springcloud实现微服务化，传统的微服务化方法需要我们学习springboot框架并在此基础上实现二次开发，而本发明方法在经过调用分析，模块拆分，人工修正三个步骤拆分为多个微服务模块后，可以将每个微服务模块转换为基于springboot框架的子模块，避免了人工二次开发的巨大成本。
经过上述四个步骤，一个单体应用就可以被拆分多个独立的微服务模块，每个模块都可以单独的进行开发和部署，单体应用也实现了快速的微服务化。本发明可减少单体架构到微服务架构转化过程中的投入，降低开发的学习成本，帮助项目平稳过渡到微服务架构。
以下结合附图和一个具体实例进一步说明本发明：
如图1所示，表示一个调用分析阶段产生的调用图，虚线框表示一个传统的单体应用，在该调用图中有9个节点分别对应单体应用中的九个类对象，有向箭头表示类之间的调用关系。
如图2所示，在模块拆分阶段，我们会以入度为0的节点作为广度优先遍历的入口。由此可知n1，n3，n7都是我们拆分微服务模块的入口，由这三个节点进行遍历可以得到三个微服务模块，分别为n1、n2和n3、n4、n5、n6以及n7、n6、n8、n9，其中节点n6表示一个被多个微服务模块共用的节点，如果不对拆分结果进行人工修正，则默认这个单体应用会被拆分如图2所示的三个微服务模块，节点6会被拆分开分别加入后两个微服务模块。
如图3所示，如果在模块拆分阶段生成的结果与实际的业务有所出入，可以在人工修正阶段对模块拆分阶段分析出的拆分方案进行修正。如在图2中的n3、n4、n5、n6以及n7、n6、n8、n9这两个微服务模块，如果在实际的业务场景中是表示的是同一个或者相近的业务，希望我们将这两个微服务模块放在一起作为一个微服务模块，我们可以选择这两个模块合并，则我们调用图的拆分结果就是n1,n2和n3、n4、n5、n6、n7、n8、n9这两个模块，如图3所示。如果一个微服务模块被拆分的太大，我们也可以在人工修正阶段根据人工的指定将该微服务进行二次拆分，保证每个微服务模块负责一个单一的业务。
在框架适配阶段，首先进行的就是我们代替应用的类对象的拆分，以图3为例将单体应用拆分为两个模块，拆分完成后根据我们需要适配的框架需要对拆分的类进行原框架到目标框架的一个转换。如基于spring开发的一个单体应用，在人工修正后拆分了默认是多个基于spring框架的微服务模块。如果我们需要适配到springboot框架，我们需要解析原spring框架的配置以及类文件中使用的spring的特性，转换为springboot框架的语法规格和配置要求，然后生成框架代码并将适配后的类文件和配置文件加入目标框架代码，则得到多个基于目标框架的微服务模块，至此也完成了一个单体应用微服务化的所有工作。
以上所述仅为本发明创造的较佳实施例而已，并不用以限制本发明创造，凡在本发明创造的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明创造的保护范围之内。