论文部分内容阅读
摘要：随着移动和智能终端的兴起以往采用基于SOA的架构方式，定义各种服务接口的模式越来越难于应对现有的挑战，越来越多的企业服务以微服务的形式进行架构设计。不同的业务数据来自不同的微服务，报表系统需要穿越这些服务获取数据，又不破坏各个业务微服务的上下文边界，这就给系统的设计和定义带来了一定难度。本文提出借助Rest API在其他微服务不繁忙的时候批量获取数据，结合基于事件的数据推送模式，在各个微服务数据发生变化的时候以消息通知报表系统，从而保证了各个服务边界，又保证了报表系统的独立性，从而达到了微服务的设计要求。
关键词：微服务；报表生产系统；J2EE
引言
随着移动计算、移动互联网、智能终端设备的兴起一场入口革命就此开始。与传统互联网单一的网页入口相比移动终端和智能终端的入口多样化和差异化就非常大了，导致企业服务不得不考虑在多种UI体验下展示系统，应用必须面对Android、IOS、移动浏览器、传统浏览器等不同UI展现形式的挑战。以往采用基于SOA的架构方式，定义各种服务接口的模式越来越难于应对现有的挑战，越来越多的企业服务以微服务的形式进行架构设计[1，2]。
越来越多的架构师倾向于以轻量化、敏捷化的方式将服务部署到云端，这就是微服务架构设计的基础思路。其架构设计特定主要是以业务来组织服务，去中心化的设计，自动化的分布式部署，良好的语言无关性。简单说就是设计的服务可以做到专才专用，能够自动部署到云端，无需过度关心具体硬件的计算模型[3，4]。
大部分企业服务中报表系统往往是串联多个业务的综合系统，也许一张报表中有来自财务的统计数据，也有来自库存的统计数据，还有来自人员组织的数据。显然不同的业务数据来自不同的微服务，报表系统需要穿越这些服务获取数据，又不破坏各个业务微服务的上下文边界，也就是说并非像以往的应用那样需要直接访问数据。这就给系统的设计和定义带来了一定难度，本文将提出设计方案解决这一问题。
1 设计方案选择
微服务的架构倾向于按业务组织服务，每个业务都有比较清晰的上下文边界，对外提供通讯接口。而报表系统的微服务由于其特殊性在于其数据依赖于其他业务服务，在保证上下文边界的同时，还需要考虑其数据的时效性，系统总体的性能和可靠性，并且微服务设计均要考虑设计对开发的复杂度，因为微服务是为了快速上线和快速迭代而产生的。
借鉴传统的报表系统，可以将其他业务系统的数据通过数据库的同步技术同步到报表微服务中形成数据仓库，再来本地服务生成报表。这样做显然破坏了微服务的边界，最直接的问题是自身的报表数据库结构必须依赖其他微服务，当其他业务服务修改表的时候，报表服务必须修改。
如果直接通过Rest API来访问那么虽然复合微服务的特点，但是由于报表所需要的业务数据量非常大，几乎是一个完整的业务库，那么访问性能可能很低和可能因为数据流量过大导致影像其他微服务。
显然，上述方案均无法达到设计要求，本文提出借助Rest API在其他微服务不繁忙的时候批量获取数据，结合基于事件推送的基于事件的数据推送模式。由于微服务开发应用是一个迭代过程，大部分业务系统可能已经上线了一段时间才会上线报表服务。所以，通过Rest API在其他业务不繁忙的时候批量获取数据。在数据完成了初始化的情况下，当业务系统的数据发生变更的时候发出消息通知报表服务更新数据。显然，这一做可以比较好的在服务边界、数据时效性、系统稳定性和运行性能之间做到很好的平衡。另外，报表服务的开发是一个独立的服务，并不会影响其他服务所以在开发效率可以得到保证。
2 服务设计方法
上述设计的关键是基于事件的驱动模式，那么系统设计需要考虑一个消息总线来根据变更数据请求的不同派发不同的消息。各个服务之间的交互都是在API层完成的，为报表服务提供一个专用的消息监听器，监听各个业务服务的API接口，对报表感兴趣的服务接口进行监听，当发生数据变更的时候如果其服务的事务正确提交，那么就有服务接口的监听器向消息总线发消息，由于报表服务会订阅该消息，那么就可以从消息队列中获得数据变更的消息。由于报表的数据库引擎是用于分析的数据仓库引擎，所以对于变更消息频繁的交易类消息会记录在一个临时的交易数据库防止数据紊乱。
最后，报表服务的数据可能存在逻辑次序上的依赖关系，例如销售数据和库存数据来自不同的微服务，销售了一笔订单，库存也许会减少，但是由于消息无法保证到达的次序，对于报表而言可能此时会出现错误的统计结果。这里就需要进行服务的编排，在报表微服务中会有一个消息缓存，在缓存中根据操作的次序性进行排队，以保证報表数据的合理性。
3 结论
采用微服务设计报表系统，虽然无法像传统应用那样直接访问数据，但是其清晰的服务边界，通讯接口和终端之间是一组扁平化的关系，报表的展示可以是任意的终端形式，报表终端不会破坏各个服务边界。报表终端的开发语言无需和应用系统保持一致，从而让每个服务之间都是独立运营的。本文提出借助Rest API在其他微服务不繁忙的时候批量获取数据，结合基于事件的数据推送模式，在各个微服务数据发生变化的时候以消息通知报表系统，从而保证了各个服务边界，又保证了报表系统的独立性，从而达到了微服务的设计要求。
参考文献：
[1] 基于微服务的企业移动办公平台规划设计[J]. 张向祺. 信息技术与标准化. 2016（03）
[2] 一种基于微服务架构的新型云件PaaS平台[J]. 郭栋，王伟，曾国荪. 信息网络安全. 2015（11）
[3] Experience on a Microservice-Based Reference Architecture for Measurement Systems. Vianden，Lichter，Steffens. Asia-Pacific Software Engineering Conference . 2014
[4] 面向服务的电子商务平台集中运维管理实践[J]. 张冰. 电力信息与通信技术. 2015（09）
作者简介：石文磊（1996-）男，汉族，河南省鹤壁市，本科，湖北工程学院新技术学院，学生，、软件工程方向。
关键词：微服务；报表生产系统；J2EE
引言
随着移动计算、移动互联网、智能终端设备的兴起一场入口革命就此开始。与传统互联网单一的网页入口相比移动终端和智能终端的入口多样化和差异化就非常大了，导致企业服务不得不考虑在多种UI体验下展示系统，应用必须面对Android、IOS、移动浏览器、传统浏览器等不同UI展现形式的挑战。以往采用基于SOA的架构方式，定义各种服务接口的模式越来越难于应对现有的挑战，越来越多的企业服务以微服务的形式进行架构设计[1，2]。
越来越多的架构师倾向于以轻量化、敏捷化的方式将服务部署到云端，这就是微服务架构设计的基础思路。其架构设计特定主要是以业务来组织服务，去中心化的设计，自动化的分布式部署，良好的语言无关性。简单说就是设计的服务可以做到专才专用，能够自动部署到云端，无需过度关心具体硬件的计算模型[3，4]。
大部分企业服务中报表系统往往是串联多个业务的综合系统，也许一张报表中有来自财务的统计数据，也有来自库存的统计数据，还有来自人员组织的数据。显然不同的业务数据来自不同的微服务，报表系统需要穿越这些服务获取数据，又不破坏各个业务微服务的上下文边界，也就是说并非像以往的应用那样需要直接访问数据。这就给系统的设计和定义带来了一定难度，本文将提出设计方案解决这一问题。
1 设计方案选择
微服务的架构倾向于按业务组织服务，每个业务都有比较清晰的上下文边界，对外提供通讯接口。而报表系统的微服务由于其特殊性在于其数据依赖于其他业务服务，在保证上下文边界的同时，还需要考虑其数据的时效性，系统总体的性能和可靠性，并且微服务设计均要考虑设计对开发的复杂度，因为微服务是为了快速上线和快速迭代而产生的。
借鉴传统的报表系统，可以将其他业务系统的数据通过数据库的同步技术同步到报表微服务中形成数据仓库，再来本地服务生成报表。这样做显然破坏了微服务的边界，最直接的问题是自身的报表数据库结构必须依赖其他微服务，当其他业务服务修改表的时候，报表服务必须修改。
如果直接通过Rest API来访问那么虽然复合微服务的特点，但是由于报表所需要的业务数据量非常大，几乎是一个完整的业务库，那么访问性能可能很低和可能因为数据流量过大导致影像其他微服务。
显然，上述方案均无法达到设计要求，本文提出借助Rest API在其他微服务不繁忙的时候批量获取数据，结合基于事件推送的基于事件的数据推送模式。由于微服务开发应用是一个迭代过程，大部分业务系统可能已经上线了一段时间才会上线报表服务。所以，通过Rest API在其他业务不繁忙的时候批量获取数据。在数据完成了初始化的情况下，当业务系统的数据发生变更的时候发出消息通知报表服务更新数据。显然，这一做可以比较好的在服务边界、数据时效性、系统稳定性和运行性能之间做到很好的平衡。另外，报表服务的开发是一个独立的服务，并不会影响其他服务所以在开发效率可以得到保证。
2 服务设计方法
上述设计的关键是基于事件的驱动模式，那么系统设计需要考虑一个消息总线来根据变更数据请求的不同派发不同的消息。各个服务之间的交互都是在API层完成的，为报表服务提供一个专用的消息监听器，监听各个业务服务的API接口，对报表感兴趣的服务接口进行监听，当发生数据变更的时候如果其服务的事务正确提交，那么就有服务接口的监听器向消息总线发消息，由于报表服务会订阅该消息，那么就可以从消息队列中获得数据变更的消息。由于报表的数据库引擎是用于分析的数据仓库引擎，所以对于变更消息频繁的交易类消息会记录在一个临时的交易数据库防止数据紊乱。
最后，报表服务的数据可能存在逻辑次序上的依赖关系，例如销售数据和库存数据来自不同的微服务，销售了一笔订单，库存也许会减少，但是由于消息无法保证到达的次序，对于报表而言可能此时会出现错误的统计结果。这里就需要进行服务的编排，在报表微服务中会有一个消息缓存，在缓存中根据操作的次序性进行排队，以保证報表数据的合理性。
3 结论
采用微服务设计报表系统，虽然无法像传统应用那样直接访问数据，但是其清晰的服务边界，通讯接口和终端之间是一组扁平化的关系，报表的展示可以是任意的终端形式，报表终端不会破坏各个服务边界。报表终端的开发语言无需和应用系统保持一致，从而让每个服务之间都是独立运营的。本文提出借助Rest API在其他微服务不繁忙的时候批量获取数据，结合基于事件的数据推送模式，在各个微服务数据发生变化的时候以消息通知报表系统，从而保证了各个服务边界，又保证了报表系统的独立性，从而达到了微服务的设计要求。
参考文献：
[1] 基于微服务的企业移动办公平台规划设计[J]. 张向祺. 信息技术与标准化. 2016（03）
[2] 一种基于微服务架构的新型云件PaaS平台[J]. 郭栋，王伟，曾国荪. 信息网络安全. 2015（11）
[3] Experience on a Microservice-Based Reference Architecture for Measurement Systems. Vianden，Lichter，Steffens. Asia-Pacific Software Engineering Conference . 2014
[4] 面向服务的电子商务平台集中运维管理实践[J]. 张冰. 电力信息与通信技术. 2015（09）
作者简介：石文磊（1996-）男，汉族，河南省鹤壁市，本科，湖北工程学院新技术学院，学生，、软件工程方向。