湖北省国税局电子税务局整体技术方案

湖北省国税局电子税务局

整体技术方案

一、纳税人端门户

用户界面：采用类似于bootstrap技术并按照编码规范统一

前端界面样式。采用类似于easyUT框架来统一前端UT组件。

提供统一风格的展示窗口：由门户提供统一的样式表、图片

和公共表头、表尾及js文件，将其放到公共区域，其它厂商统

一来调用样式表、图片，使用include引入公共的表头及表尾，

不允许各个厂商自行编写页面内联样式。

前端UI需要兼容IE8及以上版本。

二、各厂商之间的单点登录（纳税人端和税务端一致）

提供统一的登录入口。

采用cas+mysql实现单点登录。

提供java、php、.net等多种语言的客户端接入方案。

三、数据交换平台

建立全省公共的数据交换平台，分步骤实施，首先将现有所

有系统action数据交互方式改为接口API形式，然后逐步回收

权限、合并优化，实现数据集中管控。

四、“向导式”实现方案

采用敏捷开发，以用户的需求进化为核心，采用迭代、循序

渐进的方法进行软件开发。每一个功能或者页面都是相互独立的

节点，开发人员只负责实现单体功能。节点顺序和条件均由后台

统一配置，然后由“向导式引擎”，生成向导流程，并进行统一

协调运行。

五、云的架构

电子税务局的云服务由公有云和私有云两部分组成。

电子税务局云平台，整体架构自下而上，分为基础设施即服

务层(laaS)，平台即服务层(PaaS)、软件即服务层(SaaS)。整

体架构如下图所示：

籁

纳税人中心三洁士心纳眼中心申报中心

a

档案中心发票中心法规中心

a

应用

S中心;

用户中心安全中心支付中心一消息中心

监控中心发布中心施理中心评价中心

业务组件

发票信息访问组寄通用文书组件一|服务注世

与管理

歪市砒京区更浮堂举W

由壬信息法向经修二定，三三下三三二

___________________与匹克组

统一身分管理组件电子暨管理组件件

二二主二’二二式后m建运‘三管

理

区务总线

三系主数呼停应用中间单限卷

工作流引后一

一三”管磋

总续集成

i一息、中同衿限务容器平台服务与哆交

馒存售理

,基硝设施管理平台

a

*|虚拟机"!|物理机||存储||网络

基础设施即服务层(laaS)。基础设施主要包括计算设备、

存储设备、网络设备。通过虚拟化技术，实现对这些设备的虚拟

化，形成计算、存储、网络资源池。通过云计算平台，实现对虚

拟资源池的合理调度与管理，对外提供统一的标准化基础设施服

务，支持服务的自动化交付，支持资源的按需使用和动态伸缩。

平台即服务层(PaaS)。平台即服务层将各类平台软件和应用

程序归类为基础组件、技术组件和业务组件。其中基础组件提供

标准通用服务，包括关系型数据库、大数据、数据缓存、应用中

间件、消息中间件、容器、工作流引擎等，实现弹性计算、弹性

扩容、消息通讯、数据存储等功能，一般为市场商用产品；技术

组件为专项功能的技术支撑程序，包括统一身份管理组件、电子

档案管理组件等，并随技术扩展不断增加；业务组件为单项业务

功能程序，包括通用文书组件等，并随业务功能拓展不断增加。

所有组件已接口服务形式对外提供服务，云平台需提供服务集成

服务实现服务的统一管理，并提供持续集成和连续交付服务，为

应用提供开发、运行、部署等方面支撑。

软件即服务层（Saas）o软件即服务层分为应用中心和应用

系统两层，其中应用中心层对服务功能按技术支撑类和业务服务

类实现汇集；应用系统层通过发布应用系统将调用应用中心层服

务，实现相关业务功能。

公有云整体架构从上向下分为：L安全设备层、2.公共服务

层、3.接口层、4.数据层。

HHE

一、安全接入层，用于应用最外层的安全防护，一般放置

防火墙、堡垒机、WAF、DDos等设备。

二、应用服务层，主要存放各类应用服务器。通过VLAN

分为两个大的区域：

1.公共服务区。公共服务区内的各项服务是实现多应用系

统整合，为用户提供统一体验的重要基础，它还能支持未来在系

统中添加新的应用。公共服务区域的所有服务向微服务区域的所

有应用开放访问权限，各个微服务可以用接口的方式调用各类共

公服务，实现用户界面、待办事项、用户消息等数据集中显示显

示，集中管理，界面统一。公共服务区的服务包括：

身份认证及电子税务局门户主站。

CAS单点登录服务器。

用户身份信息接口.微服务中如果需要获取用户登录的信息

和用户身体基本信息，必须通过这个接口获得。

通用信息接口.微服务如果需要在电子税务局的用户提示信

息区域显示文字指示，必须调用这个接口。由电子税务局统一控

制显示。

通过待办事项接口。

顶层菜单接口.微服务如果需要使用顶层菜单，必须将菜单

数据用JSON传递给这个接口，由电子税务局统一在指定的位置

和样式显示菜单。

向导区域接口.微服务如果需要显示向导，必须过电子税务

局的接口在指定的位置和样式显示。

日志服务。

2.微服务区域。名个应用的服务器存放在本区域。为保证

各应用的安全性，控制各个微服务运维人员只能访问本人负责的

应用系统，微服务区各应用网段间不配置路由，应用间相互隔离，

互相不能访问。为保证用户体验的一致，每个微服务在开发时需

要遵循电子税务局统一制定的标准规范。目前微服务与数据库的

数据交互有两种方式待确定：

a.将所有应用与数据库交换的所有业务全部做成接口，所有

微服务只允许通过接口访问数据。

优点是完全隔离了业务系统与数据库，能为各个应用提供完

全一致的数据。屏蔽了底层业务系统的变化，当业务系统的数据

库发生升级等变化时，只需要修改这个接口，其它所有调用此接

口的应用都不用进行改变，减少了各个应用系统的维护量。

缺点是接口数量非常多，后期维护困难。

b.一部份专用的操作直接访问数据库，对外提供数据的操作

设计为接口。例如申报业务，增、删、改申报操作由微服务直接

访问数据库。但是申报的查询设计为接口。

优点是减少了接口数量，提高整体易维护性。减少接口服务

器的压力，提高了可靠性。

缺点是应用可以直接访问数据库，降低了对各应用系统访问

数据权限的控制能力。

三、数据交换层，用于存放接口应用服务。每个应用开商在

开发时，与数据库的交互操作都应按照规定的标准编写接口及相

应的文档。

四、数据层，通过防火墙与上部隔离。数据层分为两个区域：

1.文件存储区，用于集中存储所有应用中用户上传文件的存

储服务。为提高应用安全性，防止黑客通过上传文件漏洞查看应

用服务的软件代码和应用服务器操作系统文件，各个微服务应用

不允许直接将用户上传的文件放在应用服务器本机上，必须将上

传文件放到指定的存储区域。各个应用的存储空间通过目录权限

进行隔离，各应用不允许访问其它应用存储的文件。

2,数据库区，存放所有微服务需要使用的数据库。目前数

据存储方案有两种：

将代码、登记等信息同步存放在云上。申报等少数数量极大

的数据表的新增数据保存在云的缓存数据库中，到夜间服务器工

作压力降低时，通过DTS传输到本地内网服务器。

将代码、登记等信息同步放在云上，其它申报等数据都通过

MQ保存到私有云中。

以上两种方案需要进行压力测试后最终决定。

六、客户端助手

通过客户端程序，检测用户使用的浏览器版本、浏览器安全

设置等，同时安装相关CA驱动程序，提供检测结果展示，能够

自动修复客户端环境，检测通过后能自由使用电子税务局功能。

七、微服务设计方案

1.应用设计原则

将网上申报和网上审批进行彻底的组件化，将原有的单个业

务系统拆分成可独立开发、设计运行的小应用，每个服务都有自

己的处理和轻量通讯机制，这些小应用之间可以同接口完成交互

和集成，让系统尽可能快地响应变化。

微服务划分原则:

按照业务域划分（如：登记、认定、优惠、申报等。）

按照业务热点业务划分。（如：申报业务属于热点业务，将

进一步按照税种划分，比如：增值税，所得税）

按照功能划分（如：PDF打印，公共查询）。

具体划分以最终确定方案为准。

1.1>AKF拆分原则

x轴：指的是水平复制，是指单体系统多运行几个实例，做个集群加负载均衡的模式。

z轴：是基于类似的数据分区，用户量激增，集群模式推不住了，那就按照用户请求

的地区进行数据分区，武汉、襄阳等多建几个集群。

Y轴：就是所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如网上申报应用，一个集群撑不住时，分了多个集群，后来用户激增还是

不够用，经过分析发现是增值税和所得税访问量很大，就将申报应用拆成了三个申报服务、

增值税服务、所得税服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需

扩展。

1.2.拆分结果

根据对网上办税和涉税事项网上办理的2017全年的数据统计，根据可根据热点业务进

行拆分，共计24个服务。具体分为：

基础服务：

1）金三接口服务。

2）一户式查询服务。

3）基础数据查询服务。

4）PDF打印服务。

5）其他特色软件对接服务。

6）数据缓存服务。

7）统一资源服务

8）统一认证服务

9）门户服务

10）代办事项（纳税人）

11）代办事项（税务端）

申报类：

1）一般纳税人申报服务。

2）小规模申报服务。

3）所得税A类申报服务.

4）所得税B类申报服务.

5）重点税源直报服务。

6）财务报表服务。

7）所得税年报。

8）其他

涉税事项：

1）变更登记服务

2）外出经营情况服务

3）发票类服务

4）优惠备案服务

5）其他

13.前后端分离

前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，推荐的模

式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服

务端模板技术，比如JSP,把JavaJSHTMLCSS都堆到一个页面里，梢复杂的页面就无法维

护。这种分离模式的方式有几个好处：

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优

化效果会更好。

分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了,

更容易维护。

前端多渠道集成场景更容易实现，后端服务无需变更，采月统一的数据和模型，可以支

撑前端的webUl\移动App等访问。

1.4、无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完

成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,

反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思

是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应

的“有状态数据服务”中。

场景说明：例如以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架

构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。

迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓

存数据如何同步的问题。

1.5、Restful通信风格

无状态通信一RestfulAPI

作为一个原则来讲本来应该是个“无状态通信原则”，在这里直接推荐一个实践优选的

Restful通信风格，因为他有很多好处：

无状态协议HTTP,具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方

案HTTPS可用。

JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。

语言无关，各大热门语言都提供成熟的RestfulAPI框架，相对其他的一些RPC框架生态

更完善。

2、应用技术实施方案

2.1、技术选型

采用Springcloud进行开发。

2.1.1底层架构SpringCloud

SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了

分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、

数据监控等，都可以用SpringBoot的开发风格做到一槌启动和部署。

SpringCloud的子项目，大致可分成两类，一类是对现有成熟框架"SpringBoot化”的封

装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如

SpringCloudStream扮演的就是kafka,ActiveMQ这样的角色。对于想快速实践微服务的开发

者来说，第一类子项目就已经足够使用，如：

SpringCloudNetflix是对Netflix开发的一套分布式服务框架的封装，包括服务的发

现和注册，负载均衡、断路器、REST客户端、请求路由等。

SpringCloudConfig将配置信息中央化保存，配置SpringCloudBus可以实现动态修

改配置文件

SpringCloudBus分布式消息队列,是对Kafka,MQ的封装

SpringCloudSecurity对SpringSecurity的封装,并能配合Netflix使用

SpringCloudEurekaSpringCloudEureka是SpringCloudNetflix微服务套件中的一

部分，它基于NetflixEureka做了二次封装，主要负责完成微服务架构中的服务治理功能。

2.1.2技术细节

Eureka：服务注册中心：为了提供可靠性，通过HA技术进行服务器的冗余来增加可靠

性，当有一台服务器宕机了，服务并不会终止，因为另一台服务存有相同的数据。

Ribbon：负载均衡客户端：可以很好的控制http和tcp的一些行为。存在于每个微服务

的基础设施中。因为负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手

段之一。

Hystrix：断路器：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自

身的原因，服务并不能保证130%可用，如果单个服务出现问题，调用这个服务就会出现线

程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。

服务与服务之间的依赖性，故障会传播，会对整个微服纤系统造成灾难性的严重后果。Hystrix

就是服务为了解决故障的"雪崩"效应。

Zuul：智能路由：除了具备服务路由、均衡负载功能之外，它还具备了

权限控制等功能，为微服务架构提供了前门保护的作用，同时将权限控

制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体

能够具备更高的可复用性和可测试性。

HystrixDashboard：断路器聚合监控：提供接口状态的详细信息监控。

zipkin：分布式日志追踪系统：在服务调用的请求和响应中加入ID,标明上下游请求

的关系。利用这些信息，可以可视化地分析服务调用链路和服务间的依赖关系。

2.1.3技术版本

微服务改造全部采用SpringBoot1.5.7,SpringCloud版本为Dalston.RELEASE

表现层：Bootstrap+Html+Jquery

分布式缓存：Redis

数据库:MySql5.6

编码：UTF-8

工具：IDEA

SVN：Site-1.8.22

Web服务器：WEBLOGIC.TOMACAT

JDK:JDK1.8

开发环境：Maven3

八、对云资源的要求

1、软件要求：

1.2、Mysql集群

存放纳税人基础信息，登录信息，暂存数据、发票信息、代码表数据等其他实时性要求

低的数据。

13云存储

存放纳税人网上申请上传的附件以及其他的工具包和安装包。

1.4、Redis集群（可选）

存储查询热点数据，例如查询接口配置五分钟之内智能从Redis缓存中获得。

1.5、云弹性伸缩

可根据系统压力动态扩展云端硬件资源，提供标准接口，或者自动检测，无需手动。

1.6、云端负载均衡

因云端应用多已集群的方式提供，则需要云端负载均衡，针对云端应用进行负载。

1.7、分布式日志

无需开发就能快

捷完成数据采集帮助提升运维、运营效率，海量日志处理能力.

1.8、提供DTS（数据同步工具）

数据传输服务（DataTransmissionService）DTS支持关系型数据库、NoSQL、大数据

（OLAP）等数据源间的数据传输。它是一种集数据迁移、数据匚阅及数据实时同步于一体的

数据传输服务。数据传输致力于在公有云、混合云场景下私有云和公有云数据同步工具。

1.9、提供MQ（异步通讯通道）

消息队列（MessageQueue,简称MQ）具备低延迟、高并发、高可用、高可靠，可支

撑万亿级数据洪峰的分布式消息中间件。

2.硬件要求

应用内存存储

MySQL64G2T

Redis128G

影像资料