微服务架构和安全体系设计方案

文/韩道岐

1 行业现状和问题

银行现有的IT架构已经不能满足互联网秒杀、低成本高用户群覆盖、技术自主可控等要求。银行的传统IT架构面临下列问题（图1）：

应用系统投产后的运营过程中，业务并发和数据量迅速成倍增长，数据库运维压力越来越大。业务监管、业务创新等需求，导致系统变更频繁，需要进一步缩短新业务上线和系统变更维护的计划停机时间。新老系统切换需要更稳健的升级方案。

反观大型互联网企业的系统，高峰并发能达到百万级别，大量使用廉价X86平台构建分布式云计算处理系统，自主研究和引入成熟开源技术，构建自主可控的各层平台软件，面向服务方式构建可扩展多层次架构。通过分而治之的策略，化解了大用户量、大业务量的问题。

而很多银行的新一代核心系统规划，进行读写分离、业务分库表的优化，账户和产品分离、支付和产品分离、核算和产品分离，使用不同技术构建混合平台模式的私有云，也提高了整个系统的并发能力。一些关键业务不再依托特定的软硬件平台，使用开放技术构建。

在某大行实施了更自主可控、低成本的软件定义的服务目录技术，在单数据中心内部服务调度能力也可达到20万/秒，并可很好的支持多数据中心并行服务、两地三中心灾备的大规模分布式部署要求，寻址和故障切换对应用透明。

表1：两种云化技术的功能对比

图1：传统IT架构面临的问题

2013年，容器技术被Docker的横空出世再一次引爆，其核心价值在于隔离性、封装性与跨平台部署。这就使得在微服务架构下的企业IT，可在开发、测试、运维过程中更加快速敏捷。企业在面临应用的快速迭代压力下，开始思考基于docker容器技术的下一代云变革，基于docker完善的工具链，逐层堆积组件集，按需构建应用，迭代各类精益调整的参数、配置文件、脚本，如图2所示。

2 主要技术方案

使用虚拟化技术实现IAAS层的自动化、大规模部署。使用openstack等开源技术，实现网络、存储、计算节点的虚拟化创建，提供云的资源管理、应用自动调度、监控、日常运维工具，使用docker技术固化系统和应用的安装镜像，如表1所示。

使用分布式队列、异步可靠消息、面向服务的封装技术，实施PAAS层功能的服务化。提供一个更好的支撑分布式应用开发、运行、测试的框架平台。

针对金融应用，提供固化的模型应用框架，快速开发调整。多租户的SAAS服务模式，可互联网方式运营应用服务，集中建设服务长尾。

根据上述需求，设计系统的整体软件逻辑架构如下四层：

（1）容器平台服务：轻量级容器技术，更高的性能、更快的部署速度应用+运行环境整体打包，一次构建，重复部署。

（2）平台软件服务：开源和厂商的各类中间件的集成，如：Tomcat、WAS、RDS（Oracle、mysql）、MQ（ActiveMQ、Kafka）、SLB(nginx、HA-proxy)，构建云化基线版本。

（3）支撑开发测试流水线DevOps，云上开发环境，云上测试环境服务化及部署。构建编译、打包、镜像制作、部署的全流程自动化。

（4）分布式微服务框架，海量服务自动注册、发现、路由、调用链跟踪与日志实时处理分析。高性能与扩展性，提供服务开发框架和微服务管理体系。使用统一的IDE工具集成开发、测试、服务框架、微服务管理功能，具有一体化、提高复用性、大规模团队分工协作等优点。

研究的创新点在于：提供高效寻址缓存和分布式服务注册中心机制，把上述三层的云服务统一管理、发布，通过管理台，随时随地可以获得各类资源状态、容错调用。重点解决分布式的准实时一致性、上亿用户并发的响应性能问题、实时容错能力三方面难题。

3 新一代架构设计

新一代最主要的特点为分布式、使用廉价的X86集群、虚拟化管理和扩展。

新架构可以横向扩展，容量和并发不再受限，系统容错和可维护性强。

需要平台化一些设计特征，提供安全可靠的服务容器，避免复杂的应用处理逻辑；针对公共需求固化公共组件，服务方式访问组件，避免组件耦合，最终减少每个应用系统的开发工作。

3.1 分布式

新的分布式架构，需要实现数据库、应用、存储、网络、计算节点的多节点并行计算，水平可在线动态扩展，垂直可分层分类隔离。通过全局的服务总线，松散耦合服务提供者和服务消费者；通过数据复制防丢失，数据多副本后，可提供不同服务，可水平扩展服务访问能力。

提供统一的分布式服务容器平台，支持各类技术组件、业务组件的部署和运行。相关服务规范，由平台统一实现，组件建设项目组只需关注组件功能目标。

分布式部署后，各系统间须使用标准化的服务方式访问，接口清晰易用、易调试，服务发布和服务访问由服务容器平台配置化实现，提供流程和各步骤访问关系视图、一致的调试日志视图，方便理解和维护。

平台使用插件机制，固化服务代理、服务组装、服务发布三类插件，都可以配置化部署在不同的计算节点上。通过DRQ分布式实时处理队列进行消息可靠传输处理，提供消息排队和优先级调度机制，根据服务接口字段配置化路由，分发给内部不同插件服务、分发给外部不同服务节点。DRQ提供数据缓存池机制，使用HASH内存池的方式高效率处理，KEY/VALUE方式简洁访问，自动的编解码数据，通过网络方式、本地DRQ队列方法高效传输数据。DRQ提供了同步消息传输、异步消息传输、响应消息的自动匹配、消息唯一性、生命周期登记和清理等机制，基于DRQ的这些机制，实现上层的各种服务模型会简化、可靠。

平台提供集群部署和管理服务，避免单点故障；无需一次性投入，可以根据业务的发展，增加机器；可以将不同类型机器组成集群部署(比如AIX、HP-UX、Linux等)

针对运行节点、插件、服务、应用模块、配置项资源，提供了动态安装、启动、停止、更新和删除机制。多版本并存，更新时，不影响当前版本，可预约新版本生效时间点，集群内部的同时更新生效。

图2：Docker的C/S服务架构

提供故障身份ID的识别和自动隔离机制，周边服务系统的故障会被服务容器快速识别和隔离，不影响其他服务的正常处理。

提供服务降级机制，控制服务并发量。可对服务、目的方、客户化应用条目，设置流量控制策略，并可以根据历史的成功率情况动态调整目的方并发数阈值。

3.2 寻址

服务的访问通过标准化和服务容器平台固化后，应用调用服务处理变得简单、高效。

应用可以透明、动态、高效的找到目的服务方，服务方可以灵活的水平拆分、不影响消费者的调用，是新架构第二个要解决的问题。

大量的服务地址，可以通过总线平台的服务代理插件配置，固化在总线平台中。缺点是当服务提供者发生扩容、服务地址切换、新服务投产等事件时，总线平台必须进行手工调整。总线平台的扩展和容错，还要依托负载均衡设备。

新架构设计了寻址组件和服务目录组件，实现软件方式的本地动态寻址，这样大量的内部寻址需求，可以避免依赖负载均衡设备和手工管理切换。通过AGENT隔离和授权、访问ACL、黑白名单、流量控制等机制，保障服务体系的安全可控。架构建议应用调用服务时，至少两次寻址容错、并保证使用唯一的全局流水号，提高成功率、避免服务重复处理，发生不一致时，可以根据全局流水号跟踪异常。

优势在于：服务的状态是动态注册进入服务目录的，实时在整个数据中心内部同步，服务消费者在本地发现服务，直接访问服务，取消了对负载均衡设备、总线平台的依赖。服务控制、负载均衡、资源节能调度或扩容、故障隔离、灾备切换、灵活路由等功能，都统一封装在寻址组件中，更一体化、自动化。

难点在于：服务访问需要标准化，消费者不再关心提供者的服务协议。需要规范各系统的服务访问实现，寻址、服务控制、监控登记，需要改造调用寻址组件的API。服务容量大幅提高后，给日志备份和分析、实时监控、指标统计、高效故障切换等实现带来数据量的压力，相关系统也必须使用分布式技术改造。

服务总线可以先完成寻址改造，一些服务组合和条件路由还是依托总线平台实现，不能下沉给服务消费者。

假设使用用户ID作为分段，水平切分服务时，消费者需使用该ID做应用寻址条件字段，访问服务方。跨多个用户的整合事务服务，需要独立建设系统，记录和保障分段的多个事务的一致性。

3.3 缓存和文件

为消除应用服务对数据集中访问的依赖，需要根据其变化频率和生效要求，定性出固定参数、非实时变更、动态数据、强一致性要求的账务数据。对不需要实时串行保持一致性的数据，采用复制和缓存技术，提高访问效率。通过缓存机制订阅关注的数据变更，减少网络的广播数据量。

平台级所有的资源配置都通过XML文件，部署到运行环境中，提供多版本的缓存装载、生效机制，运行引擎通过缓存访问最新版本配置项。

为应用级的静态参数，如：技术参数、业务参数、客户化表达式处理，提供KEY/VALUE形式配置和缓存装载，可以按需动态加载新版本后，应用使用统一API访问最新版本的配置。

针对动态数据，提供可读写的缓存机制，在服务处理过程中，根据需要动态登记缓存，按记录多版本管理数据。固化实现动态装载数据库表、动态装载数据文件的处理程序，在相关资源发生变化时，根据配置文件定义，自动完成装载缓存处理。作为备份服务器的缓存，需要能实时备份数据到文件系统中，保证消息类缓存的可靠性和可恢复。建议一次写提交、少量或无数据变更、大量读查询、能够忍受1秒变更信息延误的业务场景下，使用缓存机制。而频繁更新、需要高可靠一致性的数据修改处理，不能使用缓存。

分布部署时，文件服务也可以使用动态缓存机制，把文件直接放入缓存并从缓存中读取文件，对应用透明化文件的存放位置。保存文件时，需要先注册文件目录所在的动态缓存服务器，然后写入动态缓存服务器。读取文件时，需要先寻址文件目录存放地址后，再从对应的缓存服务器读出文件。支持分块传输和异步断点续传客户端。

文件服务也需要通过注册方式登记到服务目录中，应用可使用寻址方式获得文件服务器地址，使用标准发送、接收文件API完成可靠的文件传输，也可以交给客户端异步任务方式完成可靠的文件传输。传输API根据配置选择使用异步还是同步的方式写入备份服务器，通过配置两次写文件，读失败再通过备份服务器尝试读一次，提高文件的读写可靠性。

分布式哈希表DHT，是目前主要的大规模分布式存储方式，可不需要服务器方式，组织松散的P2P网络结构，利用各类资源组成大规模的数据共享服务。对于动态数据缓存和文件数据缓存，使用其中比较成熟的一致性HASH算法和KAD算法。

一致性哈希算法（Consistent Hashing）最早在论文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出，可以很好实现资源的均匀分布和快速按线索搜索。简单来说，一致性哈希将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1（即哈希值是一个32位无符号整形），整个哈希空间环按顺时针方向组织。0和232-1在零点中方向重合。各个服务器使用Hash进行一个哈希，具体可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。

KAD（Kademlia）算法，由于其简单性、灵活性、安全性成为主流的实现方式。KAD无需服务器，通过ID异或机制划分距离空间，几次近邻询问跳转，就可查询网络中的邻居节点、关键字字典、文件种子、文件索引字典等信息。每个路由节点中使用队列保存多个节点，使得节点查询更迅速、命中概率更高，队列中根据活跃时间进行换入换出，更有利于在p2p这种节点变更频繁的网络中快速找到有效的节点。

3.4 自动化和手工相结合实现的最终一致性

在软硬件故障率大幅下降的情况下，交易出现最终不一致的概率会大大降低。通过各环节的设备冗余，服务调用的2次容错尝试，也可以降低故障影响。

通过监控系统的吞吐情况，在超过警戒线时，及时增加相关资源，保证各环节没有堵塞消息、可横向扩展、在最小的时间范围内完成处理，也会增加最终一致性的比率。

当多个分布处理步骤场景下，某个步骤出现业务错误时，通过自动冲正机制，实现异步的多次回滚各个成功步骤，解决不一致性的问题。有一致性问题后，应及时提示客服人员，对当前超过一定时间没有完成回滚的交易，进行人工核对和手工回滚。日终进行多系统流水数据的自动化核对，发现不一致情况，批量调整。

针对账务类和关键类服务，还可以提供统一的差错接收服务，各系统在发送异常时推送差错消息。通过全局业务流水号，可展示各服务的完整性处理过程，方便集中处理中心的人员及时发现问题、分析问题，手工处理。

分布式架构下，过程的不一致会在短暂时间内产生的，因此业务流程设计时，必须保证每个步骤执行后，产生的信息或资金不一致状态情况，不会出现业务风险。如先扣款保证资金安全、不会重复入账处理，然后可以通过客服和事后调整解决问题。

3.5 云部署管理

在廉价的X86上，可以提供大量的虚拟化计算节点，分布式部署后，系统的安装、启停、更新、监控、调度、日志和异常分析，不再是简单登录到一个节点控制台即可完成的任务。需要一个完善的分布式部署、采集和管理框架，批量化完成大量节点的管理，自动化完成采集、分析、展现、调度资源、屏蔽故障的处理。

首先是服务容器和应用系统，提供稳定的版本包，制作到docker或kvm的虚拟化安装镜像中，IAAS平台创建完相关虚拟化设备资源后，就可以直接安装镜像。然后是提供一键化安装脚本，根据虚拟化结果的物理环境，自动调整操作系统、平台、应用的设置，装载一些标准化的参数数据。

对经常需要更新的应用、代理、第三方软件包等扩展程序，能够使用镜像仓库树型结构集中管理，登记相关版本包和依赖包、更新信息、差异比对情况、交付时间、验证测试时间、上线时间、各阶段责任人。在集群中，并行的命令方式执行下面的任务：出库版本并上传，部署新版本（解包、复制到部署目录）、启动、停止、重启、平滑刷新新版本、回退指定版本。

提供agent完成受控端的命令式处理（启停、实时查询等），预警、日志、状态定时采集处理。异常及相关错误信息的实时推送到展现端。

4 安全性

注册中心支持多租户的定义，集中控制所有服务的注册和寻址，可以方便的扩展各类安全控制策略。需要管理相关用户口令，访问的令牌，各类密钥。

服务消费者和提供者，都必须先自助在线上管理系统完成参与者定义，申请需要访问的服务、由提供方系统管理员授权，在线上管理系统获得用户、口令、APP KEY、证书、AGENT包，才能在生产环境中访问注册中心、注册服务、寻址服务。AGENT定时与注册中心认证、动态请求维护accessKey。消费者寻址成功后，AGENT提供一次性访问安全上下文（由服务、地址、用户名、accessKey、时间戳组成串，签名获得），在访问服务时必须提供安全上下文；服务方需验证签名，确认消费者身份后，完成授权检查。对服务方返回的结果数据，同样需要服务方签名，消费者验证签名，确认服务方身份后，进行后续处理。

在参与者调用API时，登记服务审计记录，保存现场信息、耗时信息。通过AGENT定时收集审计记录，汇总到注册中心，在注册中心统计、查询。

5 结论

通过分析行业现状，提出了服务总线平台建设要求和关键技术方案。结合多个银行总线项目的落地实践过程，建议切实可行的目标平台应用架构。

服务平台还需要加强网络安全的4个领域功能：保密、认证、不可否认和完整性。由下列内容组成：各类加解密算法，保密的密钥，安全认证和认证保持，信任凭证的保持和迁移。

在平台上应用相关安全技术，可响应目前国家倡导的安全、自主可控方针，将关键的银行业务系统，安全、平稳的过渡到分布式的SOA架构中。