[发明专利]基于API相似度的微服务识别方法

说明书

本发明公开了一种基于API相似度的微服务识别方法。本发明提出的方法首先考虑了微服务架构的特性，然后考虑了微服务的定义：每一个专注于某一个业务功能的业务微服务的作用就是通过标准化接口为外部提供相关的业务服务，即一个微服务就是对一个资源的紧密相关的操作的集合。而每一个API表示的就是对一个后端资源的一种动作。它通过URI标识和寻址后端资源，使用HTTP协议动词表示对后端资源的操作方式。所以本发明针对这两者之间的联系提出了基于API相似度提出了一个微服务识别方法，通过构建以API为顶点、相似度为权重的无向加权图，并使用基于图论的聚类算法来识别推荐的候选微服务。

技术领域

本发明属于将基于单体式架构构建开发的应用程序迁移至微服务架构的微服务识别技术领域。在对基于单体式架构的应用程序进行架构迁移时，必须基于微服务架构的特性对原系统进行业务划分和代码重构，本发明从业务资源的角度着手，利用微服务的单一职责和符合REST风格的API具备语义化这两个特性，提出了一种基于API相似度的微服务识别方法。

背景技术

软件在当今的系统和业务运营中无处不在，在企业中，随着业务的快速发展，其业务需求也更加多样化、复杂化，软件系统不可避免的变得笨重复杂。而随着市场竞争的加剧，市场对软件企业的开发周期，成本、开发质量等方面的要求也日益增高。众所周知，软件的质量、开发工作与其架构体系有非常紧密的联系，高级的软件架构可以很好地保证软件的可扩展性、高可用性和高性能等非功能性需求。而采用传统软件开发模式开发出来的单体式应用在这些方面却有着巨大的局限性，它会随着项目业务的不断增加，复杂度越来越高，项目中的代码也越来越不可控，开发人员也难以理解项目中的代码，从而导致修复已有漏洞和实现新的功能变得异常困难且耗时颇多，系统中任何一处出现微小的错误都可能导致整个系统的崩溃，而且修改任何地方就要将整个应用完全重新部署，导致部署频繁、测试周期过长、交付效率低下等问题，同时系统也呈现出不可靠、难扩展的痛点。不仅如此，在单体式应用中，开发人员难以对项目进行技术升级。

所以越来越多企业意识到对软件的系统架构升级的必要性。一个优秀的软件系统架构必须要很好地使软件代码符合规范的三个标准：重用、标准化封装和松散耦合。基于这些标准，微服务(microservices)架构应运而生。微服务架构作为一种灵活的设计风格，保持了最低限度的集中式管理。它将一个庞大的复杂系统分解成一组相互配合的小型服务。每一个服务即微服务，它们运行于自己的进程中，微服务之间通过轻量级应用程序进行通信。这些服务围绕业务功能进行构建，并通过全自动的部署机制进行独立部署。同时，不同的微服务还可以使用不同的编程语言开发，也可以使用不同的存储技术进行数据存储。

随着微服务架构的快速发展，很多大公司(诸如google、亚马逊等公司)都已经将其部分业务迁移至微服务架构，而且越来越多的其他公司也正在或正准备将微服务架构作为他们的目标平台。

但是在微服务的迁移过程中，会遇到一些严峻的挑战。其中一个挑战就是如何从基于单体式架构的应用程序中识别出微服务。现在在工业界，微服务的识别与提取大多都是人工进行的，由经验丰富的系统架构师与对业务非常熟悉的业务人员一同从业务的角度来着手，运用领域驱动设计的方法对系统的业务中的领域进行建模，并逐步分解。领域驱动设计之所以在微服务上的识别与提取上被广泛运用，主要是因为业界对微服务的颗粒度问题缺乏一个统一明确的规定，而领域驱动设计中的“限界上下文”则能很好地回答这个问题，它为微服务的划分提供了方法论，该方法论认为，在实际产品业务中，任何一个给定的领域都包含多个有界上下文，每一个有界上下文中的东西都可以分为两个部分，一部分不需要与外部通信，另一部分则需要与外部交换数据，所以每一个上下文都有明确的接口，接口决定了该上下文会暴露哪些信息给其他上下文。所以一个有界上下文划分出来的一个领域模型通常被认为是一个微服务。