基于微服务架构实现Restful服务快速发布的方法技术

本发明专利技术涉及一种基于微服务架构实现Restful服务快速发布的方法，包括如下步骤：(1)进行图形化服务装配处理；(2)进行服务运行处理。采用该基于微服务架构实现Restful服务快速发布的方法，用户可以通过图形化技术简单方便把任何一个普通的Javabean发布成Restful API；极大的提高了微服务应用系统之间的集成效率，让业务逻辑可以快速、直观的发布为Restful服务，降低了开发维护的成本；同时运用本发明专利技术的方法可以快速、直观的将现有的业务功能发布为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服务快速发布的方法，其特征在于，所述的方法包括如下步骤：(1)进行图形化服务装配处理；(2)进行服务运行处理。

【技术特征摘要】
1.一种基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的方法包括如下步骤：(1)进行图形化服务装配处理；(2)进行服务运行处理。2.根据权利要求1所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的步骤(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文档发布到服务运行平台相应目录。3.根据权利要求2所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的判断现有业务功能的方法是否已经发布过Restful服务API接口，具体为：判断是否存在相关的doc描述文档。4.根据权利要求2所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的构件包为包含一定功能逻辑的物理单元，所述的构件包包括实现业务功能的所有依赖资源。5.根据权利要求2所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的步骤(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接口描述信息。6.根据权利要求5所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的Restful API接口描述信息包括url、描述文字、请求类型、传入参数、返回格式和返回JSON。7.根据权利要求2所述的基于微服务架构实现Restful服务快速发布的方法，其特征在于，所述的步骤(1-6)包括如下步骤：(1-6-1)对新生成的构件进行编译检查，判断是否存在编译错误，如果是，则继续步骤(1-6-2)，否则继续步骤(1-6-3)；(1-6-2)提示用户进行修正，继续步骤...

【专利技术属性】
技术研发人员：王召，
申请(专利权)人：普元信息技术股份有限公司，
类型：发明
国别省市：上海;31