【关键词】商业信息系统 分层架构 异构系统融合 负载均衡 SOA
1 背景
商业零售业信息管理管理系统应用超过20年，随着各种零售业务的不断出现，信息系统也从单一的商品进销存管理系统，逐步扩展为功能细分的ERP 进销存、CRM 会员、SCM 供应链、WMS 仓储、TMS 物流配送等等几十种独立系统。近些年，随着线上线下一体化业务的兴起，又衍生出更多的线上运维管理业务系统。这些异构系统在提供各类专业业务的同时，也在企业内形成了一个个系统孤岛。
以满足消费者多种多样的需求为目标，现在商业业务变得日趋复杂多变，亟需打通各个异构系统之间的壁垒，使得各个系统可以灵活地按业务功能要求交互运转。技术的发展提供了可能，SOA 技术架构应运而生。为了适应零售业业务的快速多变的需求，可以在复杂的系统之上，采用基于SOA 技术架构的中台设计，实现在各个系统间的破壁运行，快速完成软件开发的落地工作，让信息系统变得更好用。
2 SOA技术架构优势分析
2.1 SOA技术架构
SOA （service-oriented architecture ），面向服务的体系结构，通过在中间层建立一系列的模块化组件，可以把中间应用程序的各种功能单元，按更细的维度进行划分，在接口中以契约的方式进行联系。
利用这些标准接口的协议，构建系统的各个服务之间，都使用统一的方式来联系。SOA 技术架构自身具有多种新
基于SOA 技术架构的多并发异构业务系统中台技术设计
文/沈进波
的特性，如架构的松耦合、模块的可复用、标准接口模式、外部访问支持、标准消息模式等。2.2 SOA技术架构优势
SOA 技术架构利用新的业务和管理能力，
实时集成。对数据和应用采用集中式系统，易于部署和管理，也易于技术功能调整，可以提高业务响应速度，并保持系统的稳定性。通过选用成熟的中间件，实现一个架构支持多种应用，降低成本（架构和人员）。在与第三方的
表1：SOA 技术分层架构特点
展现层应用层数据库层横向扩展Nginx 集基于会话的
单schema 多门店纵向扩展Nginx 集应用服务器按功能分组Docker 集按性能分
配
主从DB+读写分离缓存Nginx 集Memcache/Redis Memcache/Redis 负载均衡
Nginx 、Docker 集SpringCloud 负载均衡SpringCloud 服务网关
Nginx 、Docker 集SpringCloud 负载均衡
DAL 读写分离、领域寻址
高可用性
树形Nginx 集双机，Keepalive 分组间故障隔离
Nginx 、Docker 集
SpringCloud Hystrix
请求异步、队列、降级
主/从DB 双机
微应用粒度数据分库
高并发数据库预分配
安全性HTTPS JAAS/加密传
输，DMZ
基于角的权限DAL+数据范围
良好体验
微应用服务集成框架
共享注册程序间公用开发者透明开发者透明
易于管理
授权、管理、监控应用性能监控和报警数据库性能、容量监控和报警
图1：SOA 技术四层架构示意图
系统对接开发上，API 接口利用微服务平台提供标准服务，在与第三方对接的过程中再无后顾之忧。
SOA 技术在多系统应用中起到核心作用。技术架构上，在传统B/S 的三层架构内，增加一级基础服务平台层，将中间应用层拆分成上下层架构，对原中间层的服务功能再次分层，拆分出更小的数据服务模块。这些小模块为新的中间层提供与数据库层的业务交换访问，而应用层的开发者就不需要再面对底层数据库的约束，把全部设计意图实现到业务功能上。在
基础服务平台层上，比如出现增加数据库类型时，可以通过快速上线一个新数据库访问连接字的适配小模块，即解决所有应用层对新数据库类型的数据访问功能，这将极大提高中间服务层的开发效率，业务功能调试也变得更简单。SOA 技术四层架构示意图如图1所示。2.3 技术架构的扩展性
如表1所示。
3 业务架构设计
3.1 业务分割架构
分割架构主要是指业务拆分。根据具体的业务内容和高内聚、低耦合的原则，将复杂的业务进行模块化的划分，单独部署，接口化操作数据，实现业务的横向分割。细粒度分割复杂的业务系统，可以降低业务系统的复杂度，按照模块进行开发和维护，降低整体系统的宕机时间。
一般来说，分割架构需要开发、业务为主，运维、测试为辅，架构师统一主导进行，共同进行系统划分工作。
业务划分因公司的业务不同而异，支持服务化的开源技术框架也很多，常见的有Dubbo 、Dubbox 以及比较新的Spring Boot 、Spring Cloud 等。
首先是不可避免。一般系统初期，公司为了业务尽快上线，大多将业务功能堆加在一起。随着公司业务发展，系统拆分、系统重构不可避免。
做好计划，持久作战。系统拆分、系统
重构时间相对较长，一定要提前做好计划，避免出现项目持续时间久，项目疲惫的情况。
业务拆分要科学。业务的拆分一定要经过架构、开发、业务、DBA 等部门共同讨论，共同制定出既适合当下，又能够适合未来一段时间内(2~3年)的业务发展。
业务拆分要彻底。业务拆分不应该只是系统或是程序工程的拆分，还应该包括数据库的拆分。我们之前就是拆分了程序，未彻底拆分数据库，导致程序实现服务化后，后端数据库的压力不断增大。采用数据库中间件实现后端数据库的分库，但因为中间件的一些限制，开发又不得不修改一些跨库查询和跨库事务的情况。所以业务拆分一定要彻底，不管是项目工程，还是数据库。如图2所示。3.2 OAuth2.0开放性授权
OAuth （开放授权）是一个开放的标准。允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每
一个令牌授权一个特定的网站，在特定的时段内访问特定的资源。这样，OAuth 允许用户授权第三方
网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。
3.3 异步事务访问
使用异步事务替代同步事务。在业务处理过程中，将大的同步事务，根据业务特征拆分成多个异步执行的事务，分布式处理提高处理业务的效能。如图3所示。
4 分层架构设计
图2：业务分割示意图
图3：异步事务完整性方案示意图
系统在做分层架构后，一般情况下要主要包括前端接入层、中间应用层、公共服务层、数据存储层四个层次，其中接入层包括CDN、DNS转发、负载均衡、静态资源层等。信用负载均衡的系统分层架构图如图4所示。
4.1 业务应用层设计
业务应用层比较大的一块是做服务化，这会在下面的分割架构进行详细说明。这里主要说明简单的业务拆分和应用集的部署方式。
高内聚、低耦合是业务应用层实现目标，业务拆分是解耦的重要利器之一。一般根据公司业务系统的特点和关联进行拆分，对公共业务系统进行抽取形成公共业务应用，对所有业务系统进行接口化服务。各个业务系统之间独立部署，降低耦合度，减少了业务系统之间的依赖和影响，提高整个系统的利用率。
因为有前面的负载均衡和反向代理层，所有后端的应用服务器可以横向部署多台，实现高可用也起到用户访问分流，增加吞吐、提高并发量。实际应用部署中主要以Java应用居多，且多部署在Tomcat中，
以此为例，在应用服务器部署时，主要考虑以下几个问题或是建议：统一JDK和Tomcat版本。主要是为了方便管理，另外也方便做自动化运维部署。其中统一部署中的操作系统优化、安全加固，Tomcat优化。我们在做Tomcat自动部署的时候，采用的是根据系统配置自动优化的方式和安全加固策略进行。另外就是自动备份和日志的自动切割，都在统一部署脚本中体现。这样所有部署下来，安装位置、部署方式等都是一致的，方便统一管理，统一备份和升级。
动态页面静态化。这个根据访问量选择系统进行，提高页面的访问速度。
4.2 公共服务层设计
公共服务层将上层业务层公共用到的一些缓存、消息队列、session、文件图片、统一调度、定时任务等抽取出来，作为单独的服务进行部署，为业务层提供缓存、消息队列以及图片等服务。
缓存主要是指的缓存数据。应用服务器通过缓存服务器查询常用数据，提高系统的查询速度。消息队列主要针对高并发的写，采用异步调用消息队列，进行数据的临时存储，提高系统的并发量和系统效率。
数据缓存以及session存储主要是Redis。Redis的集部署方式在数据存储层会详细说明。
消息队列的主要中间件有ActiveMQ和RabbitMQ等，二者都提供master-slave或是集的部署方式。K
afka主要在搭建日志分析平台时用到过。对于ActiveMQ和RabbitMQ，二者并没有太大的区别，都在生产用过，也没
遇到太大问题。在技术选择中，还是选择开发
和运维最熟悉的为好，再具体点，建议以开发
最熟悉的为标准。
文件图片服务器，如果公司的数据比较
敏感且有较高的保密性，加上核心生产系统只
能内部使用的话，建议搭建内部分布式文件服
务器、图片服务器，使用FastDFS进行构建分
布式集文件服务器的。如果对外提供服务，
建议采用购买云服务，方便运维管理，而且云
服务自身的特性，也比较容易增加文件或图片
的加载速度。
公共服务层的架构和部署一般来说都提
供了主从和集两种高可用方式，并且都实现
分布式部署。由于公共服务的重要性，所有业
soa务都在调用，所以在实际生产部署的时候，一
定要采用高可用的方式进行部署，并且要有可
伸缩性和可扩展性。结合我们公司实际情况，
在进行公共服务部署时，除了采用主从或是
Cluster的方式进行部署。
为了快速的响应即时扩容的需要，还增
加了一键扩展的脚本，实现对集中服务器的
快速扩展。分布式扩展方式中的常用算法主要
是一致性hash的方式。
4.3 数据存储层设计
数据存储层主要分为关系型数据库和
NoSQL数据库。主要从高可用集包括负载
均衡、读写分离、分库分表等几个方面。
NoSQL数据库主要采用Redis为主。
Redis常用的高可用方案有哨兵模式和
Cluster。使用Redis除了上面讲的做共享
session存储之外，最大的应用就是缓存常用
数据。大应用建议生产环境中分集部署。
关于非关系型数据库，除了高可用、监
控之外平常工作中还面临很大的一个工作就是
分库和分片，如何方便快速扩展，这很有用。
图4：含有负载均衡架构示意图
图5
<<；下转171页
【关键词】物联网 河流监测 单片机 嵌入式
1 引言
随着物联网的发展，每个真实的物体都可以通过电子标签连入互联网，形成一个庞大的物联网，最保守的预测认为在2045年将会有超过1千亿的设备连接在互联网上。因此物联网未来将会改变和影响我们的工作生活各个
物联网技术在河流监测系统中的应用
文/杨亚军  张辛波  吴必造
方面。水是生命之源，随着我国工业化进程的逐步加速，随之而来的水污染问题也是不容忽视的。绿树青山就是金山银山，也就是水污染问题已经成为制约我国经济发展和人民健康长寿的关键问题。而我国在在水污染治理这方面相较于发达国家起步晚且存在一定的差距。虽然市场上目前存在许多水质监测仪，能监测水质的综合指标，但我国目前多数河流的监测都是采用仪器采集人工读取的方式。这样并不能完全做到实时监控河道情况，也增加了人员开销，还不便于综合数据后期对河道水质进行综合分析。
为了解决实时智能监测河流中水的温度、PH 、电导率、溶解氧、浊度、氨氮、总磷、总氮、COD 、叶绿素、蓝绿藻等；以及河岸的岸线雨量、河道水位与流量。综合了嵌入式技术以及物联网技术，设计了一个基于嵌入式的低功耗河流监测系统。系统主要分为RTU （Remote Terminal Unit ）远程终端设备和云端系统两部分。RTU 的主控模块采用M6Y2C 核心控制板和ARM 控制芯片；采集模块预留ADC 接口，RS485接口以及IO 接口三种类型的传感器接口，外接传感器来采集河流的水位、水量以及水质等信息；然后将采集到的数据暂存在存储模块中；并通过通信模块将数据通过4G 、2G
或NB 三种模式向云端发送数据；最终在云端可以查看RTU 传输上来的各项河流数据。
2 河流监测系统的硬件设计
RTU 设备硬件要实现对水中的温度、PH 、电导率、溶解氧、浊度、氨氮、总磷、总氮、COD 、叶绿
素、蓝绿藻等；以及河岸的岸线雨量、河道水位与流量进行监测，并通过传输模块实现实时上传到云端服务器上。因此本小节首先根据需求设计架构，再具体分析每个模块的功能。
2.1 RTU设备整体架构方案
RTU 设备要实现对水中状态进行监测就需要采集传感器，要实现实时上传到云端就需要设计传输模块。在进行系统设计时要注意以下几个要点：
（1）要根据待采集的水质特征选择不同的传感器，并统计不同传感器的接口类型在RTU 设备中预留一定数量的冗余采集接口；
（2）要确保RTU 设备所采集到的数据能最大可能的传送到云端服务器，因此在进行系统设计时要考虑到向云端传输数据模块的冗余；
（3）选择核心处理器时要考虑处理器能
对于Redis 的使用，建议在一开始规划时就考虑好扩展问题避免以后的迁移或是在线扩展等。这跟关系型数据库的分库分表有异曲同工之妙。Redis 的分库分片和扩展对系统架构来说很重要，尤其业务的高速发展期，越来越多的数据缓存在Redis 中，如果没有做好规划，将会很被动。
Redis 包含三种集策略：
主从复制：在主从复制模式中，首先会有主数据库(master)和从数据库(slave)的定义。主数据库是活动业务应用，随时进行读写，读写的数据会按时序的规则，把变化内容同步进入从数据库。一个master 可以拥有多个slave ，但是一个slave 只能对应一个maste 。
哨兵：哨兵的作用是监控 redis 系统的运行状况，他的功能包括：监控主从数据库是否正常运行；master 出现故障时，自动将slave 转化为master ；多哨兵配置的时候，哨兵之间也会自动监控；多个哨兵可以监控同一个redis 。
集：使用集，将采用多主数据库形式，需要同时打开每个数据库的cluster-enable 配置。每个集组中，如果要保持稳定运行，
应不低于三个以上主数据库配置。
集示意图如图5所示。
5 结束语
利用SOA 架构里的公共服务层设计，很好地解决中台系统的开发复杂度问题，将系统架构变得松耦合，有利于信息系统相对于业务发展的随需应变，使得快速迭代开发模式在多异构系统上得以实现。应用企业还可以在新架构基础之上，逐步对原有旧系统进行抽取式更换，通过全新定义一套业务对接
模型，并开始向不同软件提供商提供服务，使得异构系统的信息孤岛逐渐消除，为企业信息化应用提供更快捷的服务。
参考文献
[1]李永红.SOA 在软件工程开发中的应用[J].
电子技术与软件工程,2017(07):38-41.[2]倪枫.SOA 敏捷架构的TOGAF 层次化迭代建
模[J].上海理工大学学报,2018(15):133-135.
[3]刘家兴.计算机辅助信息分析的技
术框架及其发展趋势[J].中国新通
信,2018(09):22-25.
[4]张婷，张鑫，张新刚.基于CPN 的OAuth
协议建模与分析[J].计算机系统应用,2018(03):57-60.
[5]冯瑞青，张激，赵俊才.异构处理器多操
作系统协同技术研究[J].计算机系统应用,2018(12):177-180.
[6]丛红艺.Linux 平台Tomcat 的安全加固
[J].网络安全和信息化,2017(12):73-75.[7]丁志均，杨青等.异构Redis 集大规模
评论数据存储负载均衡设计[J].华东师范大学学报,2017(08):119-122.
[8]王玮.Linux 服务器安全防护部署[J].计
算机产品与流通,2018(17):25-28.
作者简介
沈进波（1977-），男，安徽省六安市人。主要研究方向为电子信息系统架构设计与软件开发。
作者单位
安徽商之都股份有限公司  安徽省合肥市  230022
<<；上接170页

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。