微服务架构设计实践系列之4.2——4.3

微服务架构设计实践

目 次

1 序言

2 微服务

3 软件架构设计思想

4 微服务架构设计实践

4.1 项目概述

4.2 架构准备阶段

4.3 概念架构阶段

4.4 细化架构阶段

4.4.1 业务架构

4.4.2 数据架构

4.4.3 应用架构

4.4.4 技术架构

4.4.5 物理架构

4.4.6 开发架构

4.2 架构准备阶段

在架构准备阶段，主要是分析用户的需求，推荐采用“ADMEMS矩阵”矩阵方法进行需求结构化，即“需求层次-需求方面矩阵”。

通过业务级需求、用户级需求、开发级需求三个层次，功能、质量、约束三个方面对用户需求进行二维需求观分析，抽取出决定架构的关键需求。

ADMEMS矩阵如下图所示：

以下是分行特色业务云平台的关键需求，主要包括关键约束、关键质量和关键功能。

另外，根据这些关键需求，抽象出业务架构视图，从业务概念的角度，描述了整个系统要实现的功能。作为一种架构视图，本人把这部分内容放到《细化架构阶段-业务架构》部分，以便提供一个完整的架构视图。

4.2.1 关键约束

1.采用Java语言；

2.采用行方自主研发的Tesla平台作为基础开发平台；

3.采用分布式服务设计风格；

4.前期（一期、二期）应用运行在集群环境，后期迁移到基于Docker的云服务平台；

5.前期（一期、二期）数据运行在关系数据库环境，暂时不用考虑分库分表，后期随着业务量的增加，必须考虑分库分表；

6.项目周期：

一期：2017年3月1日至2017年7月31日，主要完成基于Tesla平台的分行特色业务云平台的搭建工作，含部分通用公共组件；

二期：2017年8月1日至2017年12月31日，主要完成分行特色业务云平台通用技术组件、业务组件、业务服务的开发、与不少于6个分行进行业务对接等；

三期：2018年1月1日至2018年5月31日，分行特色业务云平台分库分表、云服务平台迁移、业务对接等；

4.2.2 关键质量

4.2.2.1 性能

系统必须满足预期的性能目标，在并发用户数（Concurrent Users）、并发事务数（Transactions per Second，TPS）、响应时间、吞吐量（Throughout）等指标方面达到预估值，支撑使用人群的正常使用操作。

分行特色业务云平台预期的性能指标如下：（非集群环境）

1.并发用户数：200。

2.并发事务数：300。

3.平均响应时间：100ms。

4.2.2.2 可用性

可用性是指系统在指定时间内提供服务有效访问的特性。

分行特色业务云平台至少保证可用性是3个9，即软件具有较高可用性，也就是说软件年度不可用时间小于9小时。

分行特色业务云平台要在以下几个方面支持系统的高可用性：

1.高可用的应用

支持集群化部署：使用F5进行负载均衡，使用基于suce linux的X86虚拟机进行集群部署；

支持云化部署：允许分行特色业务云平台迁移到行方的私有云，该私有云基于Docker实现。

2.高可用的服务

服务降级熔断：当外部系统不可用或连续出现结果异常时，应可达到服务降级的效果，全熔断或部分熔断异常服务容量，保证正常服务的可用性，防止出现雪崩效应。

服务流量控制：对某一特定服务提供并发量控制，通过修改参数配置可调整服务并发数量。

服务对象权重控制：提供对不同服务对象（模块）的流量权重控制，通过修改参数配置可调整对不同服务对象提供服务的权重比例。

服务开关：单个服务动态开关，系统整体状态动态开关。

集群服务流量控制：针对于一个特定服务提供集群并发量控制，通过修改参数配置可调整服务并发数量。该功能推出后，可替换单实例流控的方式。

客户化并发控制：针对某一特定服务，解析接入报文数据后，对指定数据项匹配后做并发控制，如：针对某一商户进行单独并发控制。

3.高可用的数据

支持总行数据库DB2的高可用。

对于分行数据库的高可用性，由分行自己实现。

4.高可用的软件质量保证

代码：对代码版本进行控制。

测试：支持自动化测试。

服务灰度发布：对外服务变更时，做到对分行特色应用的透明，在验证周期内，保证对非验证分行应用不受影响，使得服务变更对分行特色应用造成的影响最低。

5.运行监控

进程/服务监控：对本地服务、进程繁忙情况提供监控界面，供系统负责人进行监控。

实时交易：对实时交易基本要素进行监控：交易金额、成功情况、耗时、渠道、客户信息等提供实时监控。

对流程编排过程的监控。

监控预警：设置告警级别，告警方式，告警规则，告警活动。

告警级别：自定义，页面显示，默认告警方式不同；

告警方式：邮件，短信，页面展示；

告警规则：该条告警执行的操作（如取连续3笔后台响应超时的交易），针对一个告警规则，指定告警级别及告警方式；

4.2.2.3 伸缩性

伸缩性指不需要改变软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或缩小软件的服务处理能力。

分行特色业务云平台需要支持多台服务器构成集群，并且加入新的服务器后可以提供和原来的服务器无差别的服务。

4.2.2.4 扩展性

扩展性指在对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。

分行特色业务云平台需要具备良好的扩展性，能在系统基础设施稳定不需要经常改变的情况下，对需求变更可以敏捷响应。

4.2.2.5 安全性

安全性指保护系统不受恶意访问和攻击，保护重要数据不被窃取。

分行特色业务云平台需要保证总分之间、第三方与总行、分行之间通讯安全，保证敏感的数据不外泄。

1.通讯安全

标准加解密功能：使用总行标准安全加解密方法提供给分行使用。

标准加验签功能：使用总行标准安全加验签方法提供给分行使用。

2.数据安全

日志脱敏功能：实现关键敏感字的日志脱敏功能。

加密存储功能：FTP密码明文存储、数据库密码明文存储修改为加密存储。

4.2.3 关键功能

4.2.3.1 公共技术功能

1.服务编排

使用Tesla的服务编排组件，进行复杂流程服务（涉及两个及其以上服务调用、以及需异常处理的服务）的封装。

2.基于Dubbo的服务调用

基于Tesla3.0的服务调用方式，实现服务位置的透明发现，软负载调用，服务超时设置，并发控制等功能。

服务权限管控等功能目前重点通过平台数据库控制机制实现，注册中心上的管控方式依赖于注册中心的可用性，仅作为辅助控制方法。

3.公共联机处理框架

实现公共的联机处理框架，提供通用的服务接入处理，包括入参预处理、初始化交易流水、更新交易流水、出参预处理等功能，对服务调用透明化，简化业务开发。

4.统一渠道接入能力

通过API网关，接入总行公共渠道，在网关上实现通讯协议解析，安全认证，流量控制，数据转换，协议转换等功能。

5.统一消息通知

服务通过配置化实现交易前、交易成功、交易失败、交易异常的消息通知机制，调用消息通知组件，与联机服务框架解耦。通知的方式可扩展，通知失败后的处理规则可选择。优先实现短信方式。

6.统一异常处理

服务通过配置化实现异常处理的自动处理，当异常处理到达最大重试上限后，将异常处理信息推送异常处理平台。同时，支持异常处理平台回调平台服务的实现。

7.异步任务调度

支持非持久化异步任务调度和持久化异步任务调度。

8.本地缓存

实现基于本地内存的缓存组件，缓存运行过程中极少变更的配置数据和业务数据。除此之外，本地缓存组件需要实现如下功能：

实现缓存查询服务、缓存更新服务（远程服务、本地服务）等缓存管理功能；

基于Zookeeper的Watch机制，实现了集群环境中，缓存更新事件的发布与订阅，以支持该组件在集群环境中的使用；

为了保证集群各节点缓存都进行了更新，在控制台增加了相应缓存查看，缓存更新功能，便于应用实例与ZK之间出现通讯异常时，缓存仍然能正常更新；

同时支持基于ZK的自动更新和基于控制台的手动更新，各应用根据实际情况配置；

同时支持应用级本地数据缓存和模块级本地数据缓存，各自管理，互不冲突；

9.自动任务调度

实现自动任务调度组件，以支持平台任务的定时调度，具体功能如下：

支持Tesla平台Function功能的跨模块调用；

支持任务持久化；

支持集群和分布式任务；

分线程池管理；

任务调度定义可配置化管理；

10.总分报文通讯组件

实现公共的报文通讯组件，供分行调用总行的服务，对分行屏蔽报文协议解析封装、压缩解压、签名验签功能。另外，提供灵活的扩展机制，供后续功能的扩展。

11.公共文件处理组件

实现文件配置化的组装、解析功能。

12.总分文件交互组件

分平台与总平台或后台公共模块文件交互的方案实现，使用公共组件，使分行对总分文件交互方式做到透明化。

13.全局序列号发生器

实现数据库存储全局序列号，应用启动时加载流水号段。

14.分布式集群文件配置

使用Tesla现有的配置管理中心能力实现，用于分布式应用的集群技术参数的配置。同时，配置的修改有历史记录可追踪，提供审计信息查看功能；

15.公共返回码管理

实现基于数据库的公共返回码管理，便于全平台的返回码资源共享，便于查看，维护。支持启动时加载数据库内容至本地缓存，支持动态刷新。

16.分库分表

应对大交易量交易对数据库单表造成的操作压力，支持进行分库分表操作，对表进行水平拆分和纵向拆分。

17.数据归档组件

应用系统对于长时间运行后，某些记录数过大（存量/增量指标）的表，且不需要提供实时查询的数据，应提供归档机制，直至满足监管和行内要求的最低保留时限，以避免数据无限增长对系统容量和运行效率造成负面影响。归档数据可考虑备份至本系统历史库，也可考虑归档至历史归档平台。

18.文件归档组件：

对于不需要长期保留的文件，如对账文件，产品信息文件等，需要提供定时清理机制，系统应可配置保留天数，超过天数（建议7天）的文件自动清理。

对交易日志文件，实现自动定期备份、归档和清理，避免因文件数量过多导致应用处理效率低下。对接ELK或日志归档平台进行备份后，自动清理。

19.标准通讯SDK

供接入商户使用，集成加解密、数字签名等安全功能，通讯协议拆解包等通讯功能，统一接入标准，简化商户接入难度。

20.公共批处理框架

实现批处理框架，以支持大量作业的并发处理、并发控制、异常处理等，具体要求如下：

互斥控制：

1)互斥作业应有防止并发控制机制；

2)单个批处理应控制并发重复执行；

3)前后依赖关系的批处理应保证顺序执行；

并发控制：对大数据量（量化）批处理应可实现并发处理，通过多线程/进程或数据库层实现并发，并发数可动态调整；

断点执行：单个批处理处理过程中失败，修复问题后应支持断点处继续执行；

紧急跳过：对于无法短时间修复的批处理，能提供紧急跳过该步骤，继续后续批处理功能；

通知机制：批处理开始、结束、异常等情况，可通过邮件和短信通知相关人员；

CPS调度：批作业应支持CPS系统调度发起交易和本地管理端发起交易。对处理失败的批处理，可通过本地管理端再次发起该作业；

异常业务数据通知：对批处理过程中遇到不影响继续处理，但存在异常或可疑的数据，产生工作流任务或实时通知业务人员进行异步处理；

定时任务自定义：系统提供自定义的定时自动任务，完成经常调整的定时任务，不建议通过系统的crontab定义自动任务。与其他系统有关联的作业，不建议使用此方式；

与联机交易冲突：

1)批处理过程应尽量减少联机（计划内）的可用性；

2)考虑资源（数据库资源/网络资源/进程资源等）不影响联机交易的可用性；

作业监控：对批作业状态及进度提供展示界面；

4.2.3.2 公共业务功能

1.应用日终组件

完成平台通用的修改平台状态、切日前任务处理，切日任务，切日后任务处理功能。同时，支持多个切日前任务的依赖关系、多个切日后任务的依赖关系分别可配置，根据依赖关系顺序执行。

2.日终对账组件

对分平台提供公共的日终对账能力，从支付平台按商户获取商户对账单文件，商户手续费文件。

3.额度控制组件

实现额度控制组件，支持通过配置化的数据项，控制指定交易的额度占用及释放。可按照数据级的颗粒度进行配置，如控制某个商户发起的指定交易额度控制规则。

在后端有额度控制功能前提下，可不进行配置，避免性能损耗。

4.频度控制组件

实现频度控制组件，支持通过配置化的数据项，控制指定交易的频度占用及释放。可按照数据级的颗粒度进行配置。如控制某个商户发起的指定交易频度控制规则。

在后端有频度控制功能前提下，可不进行配置，避免性能损耗。

5.通用黑白名单控制组件

通过配置的数据项，从指定的上下文中根据key=value的组合找出控制主键，并且对该主键进行黑名单准入或白名单准入功能。

4.2.3.3 基本服务封装

1.PE-支付引擎

封装总行支付引擎提供的通用支付相关的服务，预计17个，根据后期具体业务需求而定。

2.UNPS-统一网络支付系统

封装统一网络支付系统提供的在线支付相关的服务，预计27个，根据后期具体业务需求而定。

3.NPS-网络支付系统

封装网络支付系统提供的在线支付相关的服务，预计2个，根据后期具体业务需求而定。

4.RLS-零售贷款系统

封装零售贷款系统提供的贷款相关的服务，预计5个，根据后期具体业务需求而定。

5.移动支付收单系统

封装移动支付收单系统提供的移动支付相关的服务，预计5个，根据后期具体业务需求而定。

4.2.3.4 流程服务封装

1.支付结算服务封装

封装支付结算类的服务接口，包括通用的支付结算接口、招标通的服务接口、见证支付的服务接口、订单支付的服务接口等。

2.信息查询服务

封装支付/退款结果查询、交易结果查询、商户提现/余额查询等服务。

3.辅助服务

封装一些通用功能服务，如总分文件传输服务等。

4.3 概念架构阶段

在概念架构阶段，针对已经分析出的重大需求、特色需求、高风险需求，必须有针对性地确定解决方案，从而使系统提供的各种功能可以满足用户的需求。

在概念架构设计过程中，可以采用以下几步：

1.首先，针对每个关键需求，确定相应的解决方案，规划对应的系统、子系统或功能模块；

2.其次，对系统、子系统或功能模块进行分层设计。在此，引入分层概念，如：

逻辑层：重视职责的划分，职责之间通常是上层使用下层的关系，不关心上层和下层是否“能分布”在不同的机器上；

物理层：指能分布在不同机器上的软件单元，不同物理层之间必须跨机器访问。

按通用性分层：将通用性不同的部分划分到不同的层，以此作为系统的总体切分方式。

3.最后，采用“目标-场景-决策”表，质疑非功能需求，验证现有架构是否满足。如果不能满足，则调整架构。

“目标-场景-决策”表如下图所示：

4.3.1 概念性架构-全行体系视角

在确定了分行特色业务云平台关键需求以后，为了让开发人员对分行特色业务云平台在全行应用体系中所处的位置和角色有个清晰的了解，建议通过一张图展示分行特色业务云平台在全行应用体系中所处于的位置和所扮演的角色，如下图所示：

1.分行特色业务云平台总平台-服务融合中心

发挥总行大前置的作用，对分平台提供公共产品服务能力，并且在此基础上实现全行服务集中管控，隔离调用方与产品方的技术风险。

2.分行特色业务云平台分平台-特色业务分平台

在公共的特色业务开发框架内，使用标准化技术组件、业务组件，进行分行特色业务创新。

4.3.2 概念性架构-平台体系视角

确定了分行特色业务云平台在全行应用体系中所处于的位置以后，接下来就需要针对影响软件架构的重大需求、特色需求、高风险需求，有针对性地确定解决方案。

分行特色业务云平台概念性架构图如下所示：

1.分行特色业务云平台-基础开发平台（BCAP）

基础开发平台（BCAP）是基于Tesla技术平台开发的业务平台，作为分行特色业务云平台的基础开发平台，对总行和分行提供两种能力：技术能力和业务能力。通过这两种能力，实现开发敏捷和业务敏捷。

公共技术组件提供通用的技术能力，主要包括：

联机服务框架；

定时任务调度；

总分通讯机制；

公共异常处理；

批处理框架；

消息通知；

服务编排；

本地缓存；

全局序列号生成器；

API网关；

总分文件交互组件；

公共业务组件提供常用的业务能力，主要包括：

应用日终；

日终对账；

额度控制；

频度控制；

黑白名单；

2.分行特色业务云平台-服务融合中心（SCC）

服务融合中心是分行特色业务云平台中的总平台，位于总行，对外以服务的方式提供业务功能；

3.分行特色业务云平台-特色业务分平台（JCAP）

特色业务分平台是各分行根据自己的特色业务需求，基于分行特色业务云平台提供的基础开发平台进行开发的特色业务应用。

4.支撑系统

控制台：为开发人员提供系统管理、参数配置等功能，为系统管理人员、运维人员提供日志级别调整功能、缓存更新、查看功能、任务调度管理功能、异常任务查询功能等。

监控中心：收集应用发送过来的数据，然后进行统计、分析，并以图形页面的方式提供给运维人员查看。

服务管理平台：提供服务注册、发现、订阅、服务开关、服务限流、服务降级、服务权重调整功能。

特色业务开放平台：为分行开发人员提供工程创建、资源下载、接口测试、开发工具下载等功能。

5.开发规范

制定分行特色业务云平台的一系列开发规范，指导开发人员进行软件开发。

6.过程管理

通过一系列的过程管理，保证软件的持续交付的质量。

1 SpringBoot+ 高并发消息处理 EDM?项目 实战

2 SpringBoot ELK?分布式 数据分析

3 Netty?高 并发 UTS?项目实战

4 SpringCloud?微服务+NoSQL+ 负载均衡平台设计