传统架构升级微服务的设计与实现

李明 王伟 张栋栋

摘 要 为了实现信息化系统“一系统、一平台、多场景、微应用”的整体建设思路，传统架构已然满足不了现在企业的需求。本文将着重讲解微服务架构下系统的总体框架设计，技术层面实现，灾备视图设计以及系统解决方案。系统依托云平台进行建设，包括IaaS层和PaaS层基础组件，并为系统提供核心运维支撑。通过解决实际业务中的文件传输，数据存储，加解密文件验证新架构的可行性。公司一体化业务应用建设，对原各业务应用进行组件化和服务化封装，并基于自主可控的技术框架构建微应用，实现“统一展现、服务共享、数据共源”的一体化业务应用。

关键词 微服务；数据库；灾备设计

中图分类号 TP3 文献标识码 A 文章编号 1674-6708（2019）235-0140-03

基于传统的企业级复杂应用分析与发展方向研究结论，传统架构方式必然转向微服务、微应用架构方式建成“稳定安全、统一开放、简洁友好、高效领先”必然是新一代企业级应用系统形态，随着技术发展及海量数据的增长，特别是大型企业电商系统，它本身业务非常复杂，存在海量业务数据的内外网传输，并需要进行大量的加解密计算，如何实现应用快速迭代，快速部署，提高系统性能的新架构迫不及待。微服务架构是降低系统复杂度，提高系统性能的最优选择，是适合敏捷开发方法持续改进的系统。微应用是一个具有清晰边界，有一定独立性的业务单元，它通过调用一个或者多个微服务，实现一组同类型的单一业务目标或业务场景的功能逻辑组合软件包。

1 微服务与微应用

1.1 总体介绍

微服务架构模式的目的是将大型的业务应用系统拆分为多个模块相互配合的服务，每个服务都能够很容易得局部调整或优化。微服务应该是从业务逻辑上符合SRP原则的才叫微服务，SRP原则是单一职责原则。分解后的微服务架构包含多个前端服务和后端服务[1]。前端微应用实现业务操作；后端服务微应用实现业务逻辑模块。

优点：每个服务足够内聚，足够小，代码容易理解、开发效率提高；服务之间可以独立部署，微服务架构让持续部署成为可能；一个服务的内存泄露并不会让整个系统瘫痪；系统不会被长期限制在某个技术栈上，在微服务架构下不会受限于开发语言。缺点：分布式系统架构更加复杂；开发人员要设计服务之间的通信，微服务数量增加了服务治理的难度。

内部服务之间的通信方式有两种：基于HTTP协议的同步机制（REST、RPC）。依据应用功能设计阶段成果，系统与16个外部系统有集成关系，涵盖平台类、数据类、业务应用类、三方支付、公共服务平台，集成方式采用应用集成、数据集成两种。系统按照微服务架构设计，将系统划分为主体微服务、高负载（含资源消耗型）微服务、技术组件微服务等。

1.2 总体框架设计

系统总体技术架构分为应用层、服务层、数据层和平台基础层；系统依托云平台进行建设，包括IaaS层和PaaS层基础组件，并为系统提供核心运维支撑[2]。系统使用云平台IaaS层软硬件设施；系统使用云平台PAAS层核心功能分布式服务总线，对微服务统一注册管理。系统总体技术路线涵盖服务端和三个客户端（Web端、Windows端和移动端）。

2 关键技术实现

IT系统微服务化，是一种更加彻底的模块化，这种模块化不仅仅某一层内部的孤立切分和横向解耦，而是包含展示层、服务层、应用层甚至数据层的纵向、横向彻底解耦，它不像传统的模块化一样仅仅影响了设计，而是深刻影响了包括分析、设计、开发、测试、运维在内的软件全生命期的整个过程。

2.1 优先业务需求

业务功能包括：计划管理、采购管理、合同管理、废旧物资处置管理、供应商关系管理、质量监督管理、专家管理、采购标准管理、监察管理、运维管理。基于“一个平台，多个场景”的战略思路，BPM模型应当纵向分层级，横向分场景。借助业务流程监控，可以看到平台中所有的流程及其活动状态，并进一步获取流程绩效数据，进行大数据分析。

2.2 非功能需求

拆分微服务实际上存在两个层面的决定：是否可拆分，有沒有必要拆分。第一个层面主要考虑业务独立性、数据独立性、技术独立性，第二个方面的考虑主要是可维护性、可扩展性、性能等非功能需要。决定微服务划分的第一要素是可维护性、其次是性能、再次是扩展性，如果某次划分在这几个方面对系统整体上没有贡献，则不应该划分为微服务。

2.3 系统灾备设计

微服务化是一个迭代的过程，从非功能需求角度抽象微服务：1）文件接收微服务文件下载微服务；2）内外网穿透内网接受微服务；3）内外网穿透外网发送微服务；4）解密微服务；5）专家打分微服务；6）短信发送微服务；7）邮件发送微服务；8）鉴权微服务；9）非结构化平台数据传送接口；10）供应商查询中标结果；11）拍卖微服务。

阶段一：两地两中心、异地数据级灾备

建设内容：生产中心数据持续保护、异地数据级灾备架构。资源部署方式：生产中心与异地灾备资源配比为1：0.5，即生产中心采用高可用设计，灾备中心采用单机；WEB、应用服务器部署在云平台；

灾备建设路线：生产高可用：当系统生产环境中局部故障导致数据库不可用时，或发生逻辑错误时，生产本地高可用能够快速恢复数据。

故障应急恢复：当生产环境发生大范围故障或灾难时，为业务不间断提供支撑。

透明集成：当业务系统整体或局部切换到灾备环境后，仍然可以正常对外服务，而无需关心其它系统是运行在生产环境还是灾备环境

阶段二：数据灾备的技术架构

对于数据灾备，Oracle Data Guard提供了一种数据同步技术来实现Oracle的高可用性、增强的性能以及自动的故障转移方案，为主数据库创建和维护多个备用数据库，主数据库的改变能够自动将信息从主数据库传送到备用数据库，并保证在此过程中没有信息的丢失。

Oracle Data Guard是通过Oracle数据库归档日志来实现的，并通过Oracle Net来传输日志；而Golden Gate是通过对归档日志的捕捉并分析其的变化来实现的，有自己独享的传输方式；CDP技术是通过数据库镜像来实现数据同步，数据库镜像的归档以及传送策略是通过CDP软件来完成[3]。

数据一致性：无论系统从生产环境切换到灾备环境还是从灾备环境切换回生产环境，数据都不能出现混乱或丢失。

3 系统解决方案

解决非结构化文件的网络传输问题，实现对文件的存储路径和生命周期的管理。特别是大批次招标过程中海量非结构化文件处理的性能问题、稳定性问题，基于非结构化文件处理存在的性能问题，重点专注于解决资格预审文件、投标文件加解密过程中的性能问题、安全问题、容错性问题、稳定性问题以及功能需求实现问题，并提出可行的解决方案[2]。

为满足系统文件上传业务需求，提供以下几点设计方案：应用微服务、文件传输微服务分别部署在独立的网络和独立的硬件设备上，实现网络隔离，提高网络性能；采用断点续传提高容错能力，提高文件上传性能，利用消息队列消峰，避免系统访问过载导致崩溃；提升网络带宽满足文件上传需求[4]。

系统数据由结构化数据、半结构化数据和非结构化数据构成。结构化数据是指存储于数据库表中的数据，包括业务类数据、运行监控数据等，结构化数据的存储和访问由关系数据库负责，采用Oracle数据库管理系统。半结构化数据包括采购标准、供应商信息、投标信息等模块存在大量的动态表单。非结构化数据采用集中式存储技术。供应商上传的投标文件来源关系复杂，种类多、数量大，而且要求在较短时间内完成内外网的文件搬运，对存储的容量和性能都有较高的要求[5]。

关于加密过程特定算法描述如下：通过随机函数生产随机密钥（对称算法使用的密钥）；待加密文件使用该对称密钥进行加密得到密文；对称密钥使用密码机的公钥进行非对称加密得到密钥的密文；将第2步的密文与第3步的密钥密文通过统一格式捆绑形成最终的加密文件。

关于解密过程特定算法描述如下：通过对已加密文件的解绑得到原文密文以及密钥密文；密钥密文使用密码机的私钥进行解密得到对称密钥；原文密文使用对称密钥（对称算法）进行解密得到原文。

4 结论

传统IT架构已无法应对爆炸式的业务增长，部分国内外企业已尝试采用先进的架构。国內外业务应用的先进实践表明，技术上采用微服务架构是解决复杂业务问题的有效手段；系统构建方式上可结合业务特点对微服务进行中心化管理；建设方式上适当引入成熟产品，自主开发业务应用。公司一体化业务应用建设，应基于微服务架构，对原各业务应用进行组件化和服务化封装，并基于自主可控的技术框架构建微应用，实现“统一展现、服务共享、数据共源”的紧耦合的一体化业务应用。

参考文献

[1]王磊.微服务架构与实践[M].北京：电子工业出版社，2015.

[2]刘辉军，刘培峰，邱钰峰，等.基于开源框架及容器技术的微服务架构研究[J].电力信息与通信技术，2018，16（6）：90-94.

[3]黄嘉诚，董晶.基于微服务的智能档案服务系统设计与实现[J].电子设计工程，2018.

[4] 龙新征，彭一明，李若淼.基于微服务框架的信息服务平台[J].东南大学学报（自然科学版），2017，47（S1）：48-52.

[5]周丹，雷晓玲，章民融.基于微服务架构的校车安全管理系统设计与应用[J].计算机应用与软件，2018.