基于微服务架构实现Restful服务快速发布的方法与流程

本发明涉及计算机软件技术领域，尤其涉及微服务架构应用系统技术领域，具体是指一种基于微服务架构实现Restful服务快速发布的方法。

背景技术：

在2014年，Sam Newman，Martin Fowler在Thought Works的一位同事，出版了一本新书《Building Microservices》。该书描述了如何按照Microservice架构模式设计及搭建一个具有良好扩展性并可持续开发的系统。除此之外，该书还将基于该模式的系统演化流程与Continuous Delivery(持续交付)等当前甚为流行的开发流程结合在了一起，使得Microservice架构模式看起来非常具有吸引力。基于这些原因，该架构模式迅速被业界所熟知，并在多个产品中成功的使用，产生巨大影响力。

REST(Representational State Transfer，表述性状态转移)描述了一个架构样式的网络系统，比如web应用程序。它首次出现在2000年Roy Fielding的博士论文中，他是HTTP规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP(Simple Object Accessprotocol，简单对象访问协议)以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是Restful。

随着组件拆分、服务解耦，各组件之间的调用均是通过接口实现，REST可以让这些拆分后的服务风格统一、便于维护和管理，以及REST的简单明确，服务直接通信和在http之上的相互同步，而且因为它们不需要任何额外的底层架构，使得REST成为微服务同步通信首要选择。

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。与Microservice(微服务)相对应的，这种方式一般被称为Monolithic。所有的功能打包在一个WAR包里，部署在一个JEE容器(Tomcat，JBoss，WebLogic)里，包含了DO/DAO，Service，UI等所有逻辑。(如图1所示)

由于Monolithic存在以下缺点：(1)开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；(2)代码维护难：代码功能耦合在一起，新人不知道何从下手；(3)部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；(4)稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉；(5)扩展性不够：无法满足高并发情况下的业务需求，以及开发语言和架构的选型与变更。所以，现在主流的设计一般会采用Microservice Architecture，就是基于微服务的架构。简单来说，如图2所示，微服务的目的是有效的拆分应用，实现敏捷开发和部署。

微服务架构由于存在多个微服务，那么服务之间的通信就显得很重要，服务之间的通信方式有两种：基于HTTP协议的同步机制(REST、RPC)；基于消息队列的异步消息处理机制(AMQP-based message broker)。REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是Restful，同时其轻量级以及通过HTTP直接传输数据的特性，微服务中使用Restful架构已经成为最常见方法。要理解Restful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义，具体如下所示：

资源(Resources)：REST的名称“表现层状态转化”中，省略了主语。“表现层”其实指的是“资源”(Resources)的“表现层”。

所谓资源，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI(统一资源定位符)指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。所谓“上网”，就是与互联网上一系列的“资源”互动，调用它的URI。

表现层(Representation)：“资源”是一种信息实体，它可以有多种外在表现形式。我们把资源具体呈现出来的形式，叫做它的“表现层”(Representation)。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的“.html”后缀名是不必要的，因为这个后缀名表示格式，属于“表现层”范畴，而URI应该只代表“资源”的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对“表现层”的描述。

状态转化(State Transfer)：访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生“状态转化”(State Transfer)。而这种转化是建立在表现层之上的，所以就是“表现层状态转化”。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源(也可以用于更新资源)，PUT用来更新资源，DELETE用来删除资源。

在目前主流的开发语言都存在相应的Restful框架，比如Java中的Rest Easy，Spring MVC；PHP中的Slim Framework，Yii；Ruby中的Grape等等。

虽然Restful很好的解决了微服务之间同步基于Http的通信，但是目前所有框架没有考虑到对于已存在系统(由于原来系统没有使用Restful的框架)支持。由于Java语言在市场占有率达到20％多，本次主要拿Java语言做整体解决方案的范例。原来已经存在的Javabean因为没有使用Restful框架，无法进行Restful API的发布，企业面临这个问题往往只能把原来的系统进行重新开发，面临着技术框架的选型以及升级，会带来导致容易出错以及系统的安全性与稳定性问题，同时会带来巨额的成本负担。针对这种情况，我们提供一种图形化技术，对于底层进行包装，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API。该技术可极大提高微服务系统之间的集成效率，让业务逻辑可以快速、直观的发布为Restful服务，大大提高了开发效率以及老系统无成本变成微服务系统，普元EOS产品的Restful服务发布组件正是基于该技术实现。

技术实现要素：

本发明的目的是克服了上述现有技术的缺点，提供了一种能够实现动态、快速发布Restful的API接口并将Javabean发布成Restful API的基于微服务架构实现Restful服务快速发布的方法。

为了实现上述目的，本发明的具有如下构成：

该基于微服务架构实现Restful服务快速发布的方法，包括如下步骤：

(1)进行图形化服务装配处理；

(2)进行服务运行处理。

较佳地，所述的步骤(1)包括如下步骤：

(1-1)判断现有业务功能的方法是否已经发布过Restful服务API接口，如果是，则继续步骤(1-5)，否则继续步骤(1-2)；

(1-2)新建构件包；

(1-3)在该新建的构件包中创建装配图文件；

(1-4)根据用户的操作，将现有业务功能的实现拖拽到装配图中，生成一个或多个Restful的API接口和相关的doc描述文档，继续步骤(1-6)；

(1-5)用户点击功能列表图示，修改一个或多个Restful的API接口以及相关的doc描述文档；

(1-6)保持装配图文件，且由面向微服务架构应用系统对该装配图文件进行编译检查，生成Restful API的doc描述文档；

(1-7)在所述的的构件包中创建或修改对应的Restful服务API接口的Mock数据文件中的Mock data；

(1-8)点击部署装配文件，图形化服务装配平台把装配文件的Restful的API发布到服务运行平台变成Restful的服务，同时把相应Restful API的Doc和Mock文档发布到服务运行平台相应目录。

更佳地，所述的判断现有业务功能的方法是否已经发布过Restful服务API接口，具体为：

判断是否存在相关的doc描述文档。

更佳地，所述的构件包为包含一定功能逻辑的物理单元，所述的构件包包括实现业务功能的所有依赖资源。

更佳地，所述的步骤(1-5)包括以下步骤：

(1-5-1)从资源管理器中拖拽现有业务功能的实现到可视化编辑器中；

(1-5-2)对业务功能实现中的方法进行逐一检查，判断该方法的参数和返回值中是否包含有复杂数据类型，如果是，则继续步骤(1-5-3)，否则继续步骤(1-6)；

(1-5-3)判断传入参数或返回数据是否含有List、Map或Javabean复杂数据类型，如果是，则继续步骤(1-5-4)，否则继续步骤(1-5-5)；

(1-5-4)配置复杂数据类型中存放的元素的具体数据类型，继续步骤(1-6)；

(1-5-5)弹出服务装配向导，在向导中输入构件的名称和Restful API接口描述信息。

更进一步地，所述的Restful API接口描述信息包括url、描述文字、请求类型、传入参数、返回格式和返回JSON。

更佳地，所述的步骤(1-6)包括如下步骤：

(1-6-1)对新生成的构件进行编译检查，判断是否存在编译错误，如果是，则继续步骤(1-6-2)，否则继续步骤(1-6-3)；

(1-6-2)提示用户进行修正，继续步骤(1-7)；

(1-6-3)点击保存装配图文件，生成Restful API的doc描述文档。

更进一步地，所述的编译错误包括注解标签错误和接口描述错误。

更佳地，所述的步骤(1-8)包括如下步骤：

(1-8-1)建立一个新项目；

(1-8-2)右击新生成的构件包，弹出部署按钮；

(1-8-3)点击部署按钮，装配文件的Restful的API发布到服务运行平台变成Restful的服务。

更进一步地，所述的新项目包括该面向微服务架构应用系统中实现Restful服务快速发布的服务运行Mock与Doc平台所依赖的框架。

更进一步地，所述的装配文件的Restful的API发布到服务运行平台变成Restful的服务，具体为：

把Doc与Mock文件克隆到部署所述的新项目的相应目录下，完成部署操作。

较佳地，所述的步骤(2)包括以下步骤：

(2-1)启动服务运行Mock与Doc平台的服务器；

(2-2)通过浏览器访问所述的服务器的地址，查看Restful的API接口描述信息；

(2-3)根据Restful的API接口描述信息，进行API的Mock测试。

更佳地，所述的描述信息包括url、描述文字、请求类型、传入参数、返回格式和返回JSON。

更进一步地，所述的请求类型包括GET、POST、PUT和DELETE。

更进一步地，所述的步骤(2-2)包括如下步骤：

(2-2-1)查询服务器启动端口信息和url链接地址；

(2-2-2)通过浏览器访问步骤所述的的url链接地址，查看所有发布过的Restful API列表，通过所述的url查询对应的Restful API概要信息；

(2-2-3)点击所述的Restful API的概要信息，查看Restful API的描述信息。

更佳地，所述的步骤(2-3)包括如下步骤：

(2-3-1)根据Restful API的详细信息描述文字，根据Mock data填写对应的数据进行http调用，并返回相应的数据；

(2-3-2)判断返回结果是否正确，如果是，则结束步骤，否则继续步骤(2-3-4)

(2-3-4)根据提示信息，进行调试直到返回结果正确。

更进一步地，所述的判断返回结果，具体为：

将返回的数据格式和数据与Restful API定义的Schema进行比较，判断返回结果是否正确。

采用了该发明中的基于微服务架构实现Restful服务快速发布的方法，可以得出采用了该发明的业务应用系统中实现微服务架构的Restful API快速发布方法，使得开发以及发布Restful变得异常简单，开发效率大大提高，同时通过图形化的开发以及发布方式，使得用户对Restful的细节不需要太多的了解，降低了学习和维护的成本，特别是通过对于底层进行包装，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API；运用本发明的方法可以快速、直观的将现有的业务功能发布为Restful服务，大大提高了应用系统间的集成效率，大大提高了开发效率以及老系统无成本变成微服务系统，而且工作性能稳定可靠、适用范围较为广泛，便于企业业务架构向微服务架构转型。。

附图说明

图1为现有技术的系统整体功能模块示意图。

图2为现有技术的微服务构架示意图。

图3为本发明的基于微服务架构实现Restful服务快速发布的方法的系统整体功能示意图。

图4为本发明的基于微服务架构实现Restful服务快速发布的方法的方法中的系统整体功能流程示意图。

图5为本发明的基于微服务架构实现Restful服务快速发布的方法的Restful API服务装配示意图。

图6为本发明的基于微服务架构实现Restful服务快速发布的方法的Restful服务Mock调用示意图。

图7为本发明的基于微服务架构实现Restful服务快速发布的方法的外部调用发布Restful API服务示意图。

具体实施方式

为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。

在一种有效地实施方式中，该基于微服务架构实现Restful服务快速发布的方法，包括如下步骤：

(1)进行图形化服务装配处理；

(2)进行服务运行处理。

在一种较佳的实施方式中，所述的步骤(1)包括如下步骤：

(1-1)判断现有业务功能的方法是否已经发布过Restful服务API接口，如果是，则继续步骤(1-5)，否则继续步骤(1-2)；

(1-2)新建构件包；

(1-3)在该新建的构件包中创建装配图文件；

(1-4)根据用户的操作，将现有业务功能的实现拖拽到装配图中，生成一个或多个Restful的API接口和相关的doc描述文档，继续步骤(1-6)；

(1-5)用户点击功能列表图示，修改一个或多个Restful的API接口以及相关的doc描述文档；

(1-6)保持装配图文件，且由面向微服务架构应用系统对该装配图文件进行编译检查，生成Restful API的doc描述文档；

(1-7)在所述的的构件包中创建或修改对应的Restful服务API接口的Mock数据文件中的Mock data；

(1-8)点击部署装配文件，图形化服务装配平台把装配文件的Restful的API发布到服务运行平台变成Restful的服务，同时把相应Restful API的Doc和Mock文档发布到服务运行平台相应目录。

在一种更佳的实施方式中，所述的判断现有业务功能的方法是否已经发布过Restful服务API接口，具体为：

判断是否存在相关的doc描述文档。

在一种更佳的实施方式中，所述的构件包为包含一定功能逻辑的物理单元，所述的构件包包括实现业务功能的所有依赖资源。

在一种更佳的实施方式中，所述的步骤(1-5)包括以下步骤：

(1-5-1)从资源管理器中拖拽现有业务功能的实现到可视化编辑器中；

(1-5-2)对业务功能实现中的方法进行逐一检查，判断该方法的参数和返回值中是否包含有复杂数据类型，如果是，则继续步骤(1-5-3)，否则继续步骤(1-6)；

(1-5-3)判断传入参数或返回数据是否含有List、Map或Javabean复杂数据类型，如果是，则继续步骤(1-5-4)，否则继续步骤(1-5-5)；

(1-5-4)配置复杂数据类型中存放的元素的具体数据类型，继续步骤(1-6)；

(1-5-5)弹出服务装配向导，在向导中输入构件的名称和Restful API接口描述信息。

在一种更进一步的实施方式中，所述的Restful API接口描述信息包括url、描述文字、请求类型、传入参数、返回格式和返回JSON。

在一种更佳的实施方式中，所述的步骤(1-6)包括如下步骤：

(1-6-1)对新生成的构件进行编译检查，判断是否存在编译错误，如果是，则继续步骤(1-6-2)，否则继续步骤(1-6-3)；

(1-6-2)提示用户进行修正，继续步骤(1-7)；

(1-6-3)点击保存装配图文件，生成Restful API的doc描述文档。

在一种更进一步的实施方式中，所述的编译错误包括注解标签错误和接口描述错误。

在一种更佳的实施方式中，所述的步骤(1-8)包括如下步骤：

(1-8-1)建立一个新项目；

(1-8-2)右击新生成的构件包，弹出部署按钮；

(1-8-3)点击部署按钮，装配文件的Restful的API发布到服务运行平台变成Restful的服务。

在一种更进一步的实施方式中，所述的新项目包括该面向微服务架构应用系统中实现Restful服务快速发布的服务运行Mock与Doc平台所依赖的框架。

在一种更进一步的实施方式中，所述的装配文件的Restful的API发布到服务运行平台变成Restful的服务，具体为：

把Doc与Mock文件克隆到部署所述的新项目的相应目录下，完成部署操作。

在一种较佳的实施方式中，所述的步骤(2)包括以下步骤：

(2-1)启动服务运行Mock与Doc平台的服务器；

(2-2)通过浏览器访问所述的服务器的地址，查看Restful的API接口描述信息；

(2-3)根据Restful的API接口描述信息，进行API的Mock测试。

在一种更佳的实施方式中，所述的描述信息包括url、描述文字、请求类型、传入参数、返回格式和返回JSON。

在一种更进一步的实施方式中，所述的请求类型包括GET、POST、PUT和DELETE。

在一种更进一步的实施方式中，所述的步骤(2-2)包括如下步骤：

(2-2-1)查询服务器启动端口信息和url链接地址；

(2-2-2)通过浏览器访问步骤所述的的url链接地址，查看所有发布过的Restful API列表，通过所述的url查询对应的Restful API概要信息；

(2-2-3)点击所述的Restful API的概要信息，查看Restful API的描述信息。

在一种更佳的实施方式中，所述的步骤(2-3)包括如下步骤：

(2-3-1)根据Restful API的详细信息描述文字，根据Mock data填写对应的数据进行http调用，并返回相应的数据；

(2-3-2)判断返回结果是否正确，如果是，则结束步骤，否则继续步骤(2-3-4)

(2-3-4)根据提示信息，进行调试直到返回结果正确。

在一种更进一步的实施方式中，所述的判断返回结果，具体为：

将返回的数据格式和数据与Restful API定义的Schema进行比较，判断返回结果是否正确。

在微服务环境下，把一切都看成资源，而Restful是当下最流行的架构风格。由于轻量级以及通过HTTP直接传输数据的特性，Web服务的Restful方法已经成为最常见的替代方法。可以使用各种语言(比如Java程序、Perl、Ruby、Python、PHP和Java Script[包括Ajax])实现客户端。Restful Web服务通常可以通过自动客户端或代表用户的应用程序访问。但是，原来已经存在的Javabean因为没有使用Restful框架，无法进行Restful API的发布，企业面临这个问题往往只能把原来的系统进行重新开发，面临成本和技术的困难。

我们提供一种图形化技术，对于底层进行包装，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API。该技术可极大提高微服务系统之间的集成效率，让业务逻辑可以快速、直观的发布为Restful服务，大大提高了开发效率以及老系统无成本变成微服务系统，便于企业业务架构向微服务架构转型，普元EOS产品的Restful服务发布组件正是基于该技术实现。

JSON(Java Script Object Notation)是一种轻量级的数据交换格式。它基于ECMAScript的一个子集。JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯(包括C、C++、C#、Java、Java Script、Perl、Python等)。这些特性使JSON成为理想的数据交换语言。易于人阅读和编写，同时也易于机器解析和生成，同时提升网络传输速率，正使由于JSON存在的特性与Restful能够进行很好的结合，所以本次实施案例选择JSON格式。

在实际使用当中，请参阅图3至图7所示，该面向微服务架构应用系统中实现Restful服务快速发布的方法，包括图形化服务装配平台和服务运行Mock与Doc平台。其中图形化的服务装配平台包括图形化装配，编译检查和快速创建一个新的构件(包括对外Restful API接口以及实现)；服务运行Mock与Doc平台包括服务运行平台服务器，构件的Restful API的Doc文件和构件的Restful API的Mock文件，请参考图3系统整体功能模块示意图所示。

该面向微服务架构应用系统中实现Restful服务快速发布的方法中的构件包是指包含一定功能逻辑的物理单元，且每个构件包作为一个最小的部署单元部署到面向服务的架构运行系统环境中，构件包下包含实现业务功能的所有依赖资源。

所述的图形化装配Restful服务以及服务Doc与Mock运行如图4整体功能流程图所示，包括以下步骤：

(1)判断业务功能是否存在Restful的Doc描述文件；

(2)如果步骤(1)描述Doc文件不存在，则新建的构件包，新建装配图文件；

(3)拖拽现有业务功能的实现到装配图中，将在装配图中生成一个构件。

(4)为生成的构件添加一个或多个服务，并指定服务的接口描述，然后进入步骤(6)；

(5)如果步骤(1)描述Doc文件不存在，则修改构件上存在对应的Restful服务相关信息；

(6)保存装配图文件，系统会对装配图文件进行编译检查，并且生成对应的Restful APIDoc文件；

(7)创建或者修改对应的Restful服务API接口的Mock数据文件中的Mock data；

(8)点击部署，把构件下Restful API的Doc和Mock文件克隆到新增项目中；

(9)启动新建项目所在的服务器；

(10)通过浏览器访问项目地址，通过里面的模块查看Restful API的描述信息；

(11)通过浏览器访问项目地址，通过里面的模块进行Restful API的Mock测试，验证其正确性。

完成服务装配后的服务装配示意图如图5所示。

所示服务Mock运行的过程如图6所示，包括以下步骤：

(1)启动新建项目所在的服务器；

(2)通过浏览器访问项目地址，可以查看到Restful API的服务列表；

(3)根据url查询到新发布的Restful API，通过里面的模块进行Restful API的Mock测试，验证其正确性(返回的JSON格式与Restful API的schema比较)。

所示外部调用发布的Restful API调用请求过程如图7所示，包括以下步骤：

(1)客户端发起http的Restful调用请求；

(2)根据url进行匹配，找到服务端对应的Restful API接口；

(3)由接口找到对应的实现类；

(4)实现类会调到业务系统逻辑功能代码，并且返回业务功能数据；

(5)最终有Restful构件服务返回JSON格式的数据给客户端。

经过以上步骤，开发和发布Restful API功能全部完成，从中可以得出采用了该发明的业务应用系统中实现微服务架构的Restful API快速发布方法，使得开发以及发布Restful变得异常简单，开发效率大大提高，同时通过图形化的开发以及发布方式，使得用户对Restful的细节不需要太多的了解，降低了学习和维护的成本，特别是通过对于底层进行包装，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API；运用本发明的方法可以快速、直观的将现有的业务功能发布为Restful服务，大大提高了应用系统间的集成效率，大大提高了开发效率以及老系统无成本变成微服务系统，而且工作性能稳定可靠、适用范围较为广泛，便于企业业务架构向微服务架构转型。

采用了该发明中的基于微服务架构实现Restful服务快速发布的方法，由于其中在开发期提供一个可视化的Restful API服务装配工具，直观形象、快捷方便的生成Restful API装配文件，特别是通过对于底层进行包装，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API；同时，通过服务运行Mock与Doc平台，可以通过Doc查询API的文档以及每个Restful API信息(包含url，描述文字，请求类型，传入参数，返回格式，返回JSON等信息)，可以通过Mock测试每个Restful API服务，从而达到动态、快速发布Restful服务以及Restful API服务文档说明(Doc)与测试(Mock)的能力，极大的提高了微服务应用系统之间的集成效率，让业务逻辑可以快速、直观的发布为Restful服务，从而使其更加直观、简单和高效，性能稳定可靠，降低了开发维护的成本；同时运用本发明的方法可以快速、直观的将现有的业务功能发布为Restful服务，大大提高了应用系统间的集成效率，大大提高了开发效率以及老系统无成本变成微服务系统，而且工作性能稳定可靠、适用范围较为广泛，为业务系统微服务化软件技术的进一步发展奠定了坚实的基础。

在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。