CN108337106B

CN108337106B - 物联网微服务系统架构的构建方法、平台及计算机设备

Info

Publication number: CN108337106B
Application number: CN201711366004.1A
Authority: CN
Inventors: 杨金林
Original assignee: Qingdao Haier Technology Co Ltd; Haier Uplus Intelligent Technology Beijing Co Ltd
Current assignee: Qingdao Haier Technology Co Ltd; Haier Uplus Intelligent Technology Beijing Co Ltd
Priority date: 2017-12-18
Filing date: 2017-12-18
Publication date: 2021-07-16
Anticipated expiration: 2037-12-18
Also published as: CN108337106A

Abstract

本发明公开一种物联网微服务系统架构的构建方法、平台及计算机设备，所述方法在应用层中检测目标服务接口应用是否与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑；当检测结果为是时，在平台服务层创建一个Dubbo服务，并将所述业务逻辑存入所述Dubbo服务。本发明能够降低耦合度，快速迭代系统。

Description

物联网微服务系统架构的构建方法、平台及计算机设备

技术领域

本发明涉及系统架构，具体涉及一种物联网微服务系统架构的构建方法、平台及计算机设备。

背景技术

目前市面上存在很多开源技术框架，对于非互联网企业，该企业并未把技术储备放在高投入的位置上，技术架构负责人对技术框架的理解可能只处于基本层面，在这种环境下设计的系统架构只是流行技术框架的堆积，因此使用该系统架构开发的产品或平台，对其性能、快速迭代、向下兼容等能力的风险难以预料。对于互联网企业，各企业系统架构差异大，从创业初期到后期发展阶段，每家企业的第一版系统架构都是轻量级，随着业务量增加后，系统架构在升级第二版时会考虑向下兼容。由于一个企业的系统架构基本成型，后期基本不会发生质的变化，在此基础上再开发定制化技术框架，弱化开源框架的不稳定性和减免付费软件的高成本。目前互联网企业的系统架构问题仅仅是能否快速响应，快速响应的基本条件是建立一个符合公司一段时间内业务发展的系统架构。而现有的系统架构存在以下问题：

1、技术框架稳定但系统架构很弱，后期很难持续维护。

2、平台中的各子系统耦合度高，版本迭代周期长，工作效率低，服务器平台稳定性差，平台的运行对开发人员能力要求比较高等等问题。

发明内容

本发明的目的是为了提供一种物联网微服务系统架构的构建方法、平台及计算机设备，降低耦合度，能够快速实现系统迭代。

依据本发明的一个方面，提供一种物联网微服务系统架构的构建方法，

在应用层中检测目标服务接口应用是否与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑；

当检测结果为是时，在平台服务层创建一个Dubbo服务，并将所述业务逻辑存入所述Dubbo服务。

所述目标服务接口应用包括：

新增业务时，物联网微服务系统中原有的、承载该新增业务的原有服务接口应用；

或者，新增业务时，新建的新服务接口应用。

可选地，本发明所述方法中，所述应用层中的目标服务接口应用和原有服务接口应用对外采用安全套接字层超文本传输协议https+验证规则的方式进行通信。

可选地，本发明所述方法中，所述应用层中的目标服务接口应用和原有服务接口应用根据是否涉及用户登录信息分为两种通信方式：

涉及用户登录信息时，将采用在应用中集成拦截器，将用户信息保存到浏览器cookies中；

不涉及用户登录信息时，应用采用安全套接字层超文本传输协议https进行通信。

可选地，本发明所述方法中，所述所述目标服务接口应用和原有服务接口应用均包括rest接口应用。

依据本发明的另一个方面，提供一种物联网微服务系统架构平台，包括平台服务层和应用层，所述应用层位于平台服务层之上，所述平台服务层和应用层之间通过通信网络进行通信，

所述应用层，用于检测目标服务接口应用是否与系统中一个或多个原有服务接口应用具有相同的业务逻辑；

所述平台服务层，用于当检测到在所述应用层中目标服务接口应用与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑时，在平台服务层创建一个Dubbo服务，并将所述相同的业务逻辑存入所述Dubbo服务。

可选地，本发明所述平台中，所述应用层还用于当新增业务时，判断应用层中目标服务接口应用与物联网微服务系统中原有服务接口应用的业务类型是否相同，若相同，采用物联网微服务系统中原有服务接口应用形成原有的、承载该新增业务的原有服务接口应用；若不同，新建的新服务接口应用。

可选地，本发明所述平台中，所述应用层中的目标服务接口应用和原有服务接口应用对外采用安全套接字层超文本传输协议https+验证规则的方式进行通信。

依据本发明的第三个方面，提供一种计算机可读存储介质，所述存储介质上存储有物联网微服务系统架构的构建程序，所述程序被处理器执行时实现上述任意一项所述物联网微服务系统架构的构建方法的步骤。

依据本发明的第四个方面，提供一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的物联网微服务系统架构的构建程序，所述处理器执行所述程序时实现上述任意一项所述物联网微服务系统架构的构建方法的步骤。

与现有技术相比，本发明的效果如下：本发明提供的物联网微服务系统架构的构建方法及平台，当新增业务时，当检测应用层中的目标服务接口应用与系统中一个或多个原有服务接口应用具有相同的业务逻辑时，在平台服务层创建一个Dubbo服务，目标服务接口应用和系统中的原有服务接口应用调用存入Dubbo服务中的业务逻辑，从而降低了平台部署时的复杂度，提高平台部署上线的成功率，可以灵活的指定开发人员负责最小功能模块的开发及保障。

本发明应用层中的服务接口应用对外采用https+验证规则的方式进行通信。对内分根据涉是否及用户登录信息分为两种通信方式，其中涉及用户登录信息的通信方式采用在应用中集成拦截器，将用户信息保存到浏览器cookies中；另一种采用https进行通信。本发明可以按照对内对外、技术层级的方式进行组合，使业务、技术、运维各个层面运作都很顺畅。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明物联网微服务系统架构的构建方法的流程图；

图2是本发明物联网微服务系统架构的构建方法示例的流程图；

图3是本发明物联网微服务系统架构的构建方法示例的时序图；

图4是本发明物联网微服务系统架构的构建平台的原理框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参见图1所示，为了解决现有技术中的问题，本发明提供一种物联网微服务系统架构的构建方法，

具体步骤如下：

步骤S01、在应用层中检测目标服务接口应用是否与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑，本实施例，所述服务接口应用为rest(Representational State Transfer，表述性状态传递)接口应用，应用层均采用rest接口提供服务；

步骤S02、当检测结果为是时，在平台服务层创建一个Dubbo服务，并将所述业务逻辑存入所述Dubbo服务，所述目标服务接口应用和所述原有服务接口应用调用存入Dubbo服务中的业务逻辑，切断了接口应用之间的依赖，将依赖关系变为接口应用对Dubbo服务的依赖，将公共的业务逻辑沉降到Dubbo服务中实现，提高系统间调用的效率。因为平台服务层服务对内部web应用提供Dubbo服务，是内部服务器之间的通信，安全等级要求并不高，所以平台服务层服务要强化分布式部署，提高高并发能力和稳定性。所述服务接口应用即业务子系统，但是如果一个业务子系统没有或者很少被其他业务子系统依赖则没有必要单独创建一个Dubbo服务。

可能地/可选地，本实施例，当新增业务时，还包括判断应用层中目标服务接口应用与物联网微服务系统中原有的服务接口应用的业务类型是否相同，即判断是否增加服务接口应用，若相同，采用物联网微服务系统中原有的服务接口应用形成原有的、承载该新增业务的服务接口应用；若不同，新建服务接口应用。因此所述目标服务接口应用包括：新增业务时，物联网微服务系统中原有的、承载该新增业务的原有服务接口应用；或者，新增业务时，新建的新服务接口应用。所述新增业务包括业务逻辑的增加以及业务线的增加，所述业务线即业务范围。例如：新增业务逻辑，一个卖书商城，后来增加了卖衣服，最后增加了卖鞋，可见书和衣服分别是图书影像、穿戴用品两条业务线。这时需要预估，可以根据用户的访问量，如果网站的访问量小，所有的业务用一个服务支撑即可，只需要增加接口；如果网站访问量大，每一个业务都需要用独立的业务逻辑来支持，甚至男装、女装、男鞋、女鞋都需要不同的业务逻辑来支撑。网系统架构相比互联网的专一性显得更加大而全，随着新增业务，通过增加新的接口应用以及Dubbo服务，降低了系统的复杂度，并且便于在一很短的段时间(例如：2小时)内实现版本的迭代更新，升级将变的更加简单，由于架构比较轻量，以后切换到IaaS平台也很容易。

可能地/可选地，本实施例，所述应用层中的服务接口应用对外采用安全套接字层超文本传输协议https(Hyper Text Transfer Protocol over Secure Socket Layer)+验证规则的方式进行通信，保证接口调用的安全性。因为https一般为双向验证，发送和接收双方都要有安全机构颁发的公钥，双方经过三次握手建立信任关系后再交互数据；而验证规则为关键参数和隐含参数拼接再对其进行加密，接收方通过比对这个加密字符串是否一致来验证请求是否受信来实现的，其中隐含参数双方通过线下统一。

可能地/可选地，本实施例，所述应用层中的目标服务接口应用和原有服务接口应用对内根据是否涉及用户登录信息分为两种通信方式，涉及用户登录信息时，采用在应用中集成拦截器，将用户信息保存到浏览器cookies中，因为每次请求时使用，因cookies是有作用域的，所以cookies的信息是相对安全的。不涉及用户登录信息时，应用采用安全套接字层超文本传输协议https进行通信，该种直接采用https通信方式同样适用不需要和其他业务子系统共享用户信息的对内通信。或者所述应用层中的服务接口应用对内均采用一种通信方式。本发明按照安全级别调整技术架构，一是给第三方调用的，属于对外，另一是提供给页面调用的，属于对内，第三是给后台管理调用的，属于对内，供第三方调用的需采用单独的rest应用，提供给页面的和后台管理调用均属于对内，因此可以采用一个应用，也可以分别采用两个应用。在安全和效率上达成平衡。

本发明中所述资源层包括业务数据库、数据缓存(Redis)、资源文件，对于高并发的读写可以将数据库进行分布式处理，因物联网行业对数据存储并发性要求不高，只考虑读写策略即可，即数据库对外提供访问域名，域名解析时会自动根据数据操作读写情况映射到对应的读或写的数据库，降低数据库悲观锁的产生概率，减少等待时间。Redis作为分布式系统部署的会话同步解决方案，其并发性能非常高，万级数据以下的并发都没有问题，只做主备即可，但Redis不支持事务，对数据的实时性要求较高的业务需要单独对业务进行处理。资源文件一般由网络入口处配置CDN加速，提高全国各个地区下载文件的速度，降低主资源服务器的访问压力；资源服务器一般为主备机，即备机以一定的周期同步主机的资源文件，尽可能的防止主机因硬盘损坏而导致的文件不可恢复。应用层的应用也可以直接访问资源，一般情况为web应用没有对应的Dubbo服务或者相对个性化的业务操作时调用。

从传统web项目到互联网/物联网平台，技术架构由于业务的复杂度增加而逐渐变的复杂，软件编码风格倾向于用空间换时间的方式，大量的数据冗余用于保证系统的稳定性和数据的可靠性。而软件方面海量服务器的运维尽可能虚拟化、自动化，通过资源层将物理服务器虚拟化，通过软件对服务器进行集中管理和监控，在此基础上软件中间件的自动化实施才变为可能，比如使用Docker引擎，可以瞬间初始化上千个实例来应对高并发请求，即上千个负载均衡的应用节点。

物联网相对互联网并发要求并不算高，但是数据的可靠性是同等重要的，因此物联网行业暂时不封装资源层是可行的，但部署应用还是要借助一些自动化部署工具，如jenkins。运维人员按照开发团队的要求提前做好自动化配置，上线时只需要对配置做简单的调整即可执行自动化部署，由软件执行脚本自动化部署各个物理服务器，减少人工部署的重复工作，降低人工操作的出错概率。

本实施例将结合具体应用示例，对本实施例所述方法进行阐述，需要指出的是，本实施例中公开的大量技术细节用于解释本发明，并不用于唯一限定本发明。

本实例基于所述物联网微服务系统的基础架构，所述物联网微服务系统的基础架构即第一个版本，该基础架构包括应用层(SaaS)的接口应用和资源层(IaaS)的存储数据，所述接口应用通过接口访问资源层的存储数据，该第一个版本只要保证能够通过接口正常访问即可。本发明在基础架构的基础上构建物联网微服务系统，所述物联网微服务系统包括应用层(SaaS)、平台服务层(PaaS)和资源层(IaaS)，参见图2所示，当新增业务时，具体步骤如下：

首先，判断应用层中目标服务接口应用与物联网微服务系统中原有的服务接口应用的业务类型是否相同，即判断是否增加服务接口应用，若相同，采用物联网微服务系统中原有的服务接口应用形成原有的、承载该新增业务的服务接口应用；若不同，新建服务接口应用；

然后，在应用层中检测目标服务接口应用是否与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑，所述服务接口应用为rest接口应用；

最后，当检测结果为是时，在平台服务层创建一个Dubbo服务，并将所述业务逻辑存入所述Dubbo服务，所述Dubbo服务是分布式服务框架,由阿里巴巴公司开源的一个高性能优秀的服务框架。所述目标服务接口应用和所述原有服务接口应用调用存入Dubbo服务中的业务逻辑，切断了接口应用之间的依赖，将依赖关系变为接口应用对Dubbo服务的依赖，将公共的业务逻辑沉降到Dubbo服务中实现，提高系统间调用的效率。因为平台服务层PaaS服务对内部web应用提供Dubbo服务，是内部服务器之间的通信，安全等级要求并不高，所以PaaS服务要强化分布式部署，提高高并发能力和稳定性。所述服务接口应用即业务子系统，但是如果一个业务子系统没有或者很少被其他业务子系统依赖则没有必要单独创建一个Dubbo服务。

本示例以U+开放平台为例，目前使用以下时序来迭代开发系统，参见图3所示：

步骤001、需求方通过产品经理向开发人员提出需求；

步骤002、开发人员开发完毕后给运维人员提工单申请部署；

步骤003、运维人员通过jenkins对申请部署的应用执行自动化部署，最终部署到物理服务器或虚拟机上；

步骤004、判断目标服务接口应用是否与系统中一个或多个原有服务接口应用具有相同的业务逻辑即开发的业务被其他应用依赖，

如果开发人员开发的业务与系统中一个或多个原有服务接口应用有相同的业务逻辑，那么需要将业务逻辑沉降到平台服务层，通过平台服务层创建的Dubbo服务对内提供接口，进入步骤005，使用Dubbo服务的优点是连接方式为长连接，减少反复连接带来的延迟；

如果不存在相同的业务逻辑，wed应用通过rest接口直接调用物理服务器中的数据；

步骤005、开发人员给paas平台管理员提工单申请部署；

步骤006、paas平台管理员配置环境信息；

步骤007、通过paas平台自动将服务部署到对应的节点上，通过日志得知是否部署成功；

步骤008、wed应用通过rest接口调用Dubbo服务，通过Dubbo服务调用物理服务器中的数据。

本发明的参与人员有：事业部业务人员、产品经理、开发人员、运维人员、paas服务管理员，各个角色按照以上的流程能够很好的配合工作，各司其职，各负其责，使团队间、小组间协助更加顺畅，责任分工更加明确最终能够为用户提供好的开放平台。

U+开放平台从最初的5个rest应用，调整为5个rest应用和3个dubbo服务，直到现在已经有15个rest应用，8个dubbo服务，每一次系统的拆分必然是由于业务的扩展，增加一类新的业务或者两类业务产生的关联关系。虽然应用很多，但是每次升级依然能够在2个小时内完成当前版本的更新，未来IaaS平台上线后，升级将变的更加简单，由于架构比较轻量，以后切换到IaaS平台也很容易。

本发明从业务形态调整技术架构，采用服务接口应用调用dubbo服务，切断服务接口应用之间的依赖，将依赖关系变为服务接口应用对dubbo服务的依赖，将公共业务逻辑沉降到dubbo服务中实现。如果只调整算法只需修改dubbo服务，如果只变更某类业务需求，其他业务对应的rest应用则不用升级，在业务复杂度和技术复杂度上达成平衡，实现了将系统框架微服务化，使业务子系统间耦合度降低，使产品迭代更加容易，本发明制定一个可持续的架构扩展策略并坚持按照该策略将业务需求落地，使业务系统稳定、可持续扩展。

在本发明的第二实施例中，提供一种物联网微服务系统架构平台，应用层(SaaS)1、平台服务层(PaaS)2和资源层(IaaS)3，参见图4所示：

所述平台服务层2，用于当检测到在应用层中目标服务接口应用与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑时，在平台服务层创建一个Dubbo服务，并将所述相同的业务逻辑存入所述Dubbo服务；

所述应用层1，用于检测目标服务接口应用是否与系统中一个或多个原有服务接口应用具有相同的业务逻辑，且所述目标服务接口应用和所述原有服务接口应用调用存入Dubbo服务中的业务逻辑。

所述资源层3包括业务数据库、数据缓存(Redis)、资源文件，对于高并发的读写可以将数据库进行分布式处理，因物联网行业对数据存储并发性要求不高，只考虑读写策略即可，即数据库对外提供访问域名，域名解析时会自动根据数据操作读写情况映射到对应的读或写的数据库，降低数据库悲观锁的产生概率，减少等待时间。Redis作为分布式系统部署的会话同步解决方案，其并发性能非常高，万级数据以下的并发都没有问题，只做主备即可，但Redis不支持事务，对数据的实时性要求较高的业务需要单独对业务进行处理。资源文件一般由网络入口处配置CDN加速，提高全国各个地区下载文件的速度，降低主资源服务器的访问压力；资源服务器一般为主备机，即备机以一定的周期同步主机的资源文件，尽可能的防止主机因硬盘损坏而导致的文件不可恢复。应用层的应用也可以直接访问资源，一般情况为web应用没有对应的Dubbo服务或者相对个性化的业务操作时调用。

可能地/可选地，本实施例，所述应用层1还用于当新增业务时，判断应用层中目标服务接口应用与物联网微服务系统中原有服务接口应用的业务类型是否相同，若相同，采用物联网微服务系统中原有的服务接口应用形成原有的、承载该新增业务的原有服务接口应用；若不同，新建的新服务接口应用。因此所述目标服务接口应用包括：新增业务时，物联网微服务系统中原有的、承载该新增业务的原有服务接口应用；或者，新增业务时，新建的新服务接口应用。所述新增业务包括业务逻辑的增加以及业务线的增加，所述业务线即业务范围。

可能地/可选地，本实施例，所述应用层1中的目标服务接口应用和原有服务接口应用对外采用https+验证规则的方式进行通信。

可能地/可选地，本实施例，所述应用层1中的目标服务接口应用和原有服务接口应用对内根据是否涉及用户登录信息分为两种通信方式，涉及用户登录信息时，采用在应用中集成拦截器，将用户信息保存到浏览器cookies中；不涉及用户登录信息时，采用https的通信方式。

可能地/可选地，本实施例，所述目标服务接口应用和原有服务接口应用采用rest接口应用。

在本发明的第三实施例中，提供一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的物联网微服务系统架构的构建程序，所述处理器执行所述程序时实现所述物联网微服务系统架构的构建方法的步骤，具体步骤如下：

步骤S01：在应用层中检测目标服务接口应用是否与物联网微服务系统中一个或多个原有服务接口应用具有相同的业务逻辑；

步骤S02：当检测结果为是时，在平台服务层创建一个Dubbo服务，并将所述业务逻辑存入所述Dubbo服务。

由于在第一实施例中已经对物联网微服务系统架构的构建方法做了具体说明，本实施例在此不再赘述。

在本发明的第四实施例中，提供一种计算机可读存储介质，所述存储介质上存储有物联网微服务系统架构的构建程序，所述程序被处理器执行时实现所述物联网微服务系统架构的构建方法的步骤，具体步骤如下：

本实施例中，所述的存储介质可以包括但不限于为：ROM、RAM、磁盘或光盘等。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种物联网微服务系统架构的构建方法，其特征在于：

所述物联网微服务系统包括应用层SaaS、平台服务层PaaS和资源层IaaS；

2.如权利要求1所述的物联网微服务系统架构的构建方法，其特征在于，所述目标服务接口应用包括：

或者，新增业务时，新建的新服务接口应用。

3.如权利要求1或2所述的物联网微服务系统架构的构建方法，其特征在于，所述应用层中的目标服务接口应用和原有服务接口应用对外采用安全套接字层超文本传输协议https+验证规则的方式进行通信。

4.如权利要求1或2所述的物联网微服务系统架构的构建方法，其特征在于，所述应用层中的目标服务接口应用和原有服务接口应用根据是否涉及用户登录信息分为两种通信方式：

5.如权利要求1或2所述的物联网微服务系统架构的构建方法，其特征在于，所述目标服务接口应用和原有服务接口应用均包括rest接口应用。

6.一种物联网微服务系统架构平台，包括平台服务层和应用层，所述应用层位于平台服务层之上，所述平台服务层和应用层之间通过通信网络进行通信，其特征在于：

7.如权利要求6所述的物联网微服务系统架构平台，其特征在于，所述应用层还用于当新增业务时，判断应用层中目标服务接口应用与物联网微服务系统中原有服务接口应用的业务类型是否相同，若相同，采用物联网微服务系统中原有服务接口应用形成原有的、承载该新增业务的原有服务接口应用；若不同，新建的新服务接口应用。

8.如权利要求6或7所述的物联网微服务系统架构平台，其特征在于，所述应用层中的目标服务接口应用和原有服务接口应用对外采用安全套接字层超文本传输协议https+验证规则的方式进行通信。

9.一种计算机可读存储介质，所述存储介质上存储有物联网微服务系统架构的构建程序，所述程序被处理器执行时实现权利要求1至5中任意一项所述方法的步骤。

10.一种计算机设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的物联网微服务系统架构的构建程序，所述处理器执行所述程序时实现权利要求1至5中任意一项所述物联网微服务系统架构的构建方法的步骤。