第 1 章 引言

第 2 章 分布式架构理论及典型实践

第 3 章 当前主流的 IT 架构分析

第 4 章 新一代银行 IT 架构分析

第 5 章 新一代银行 IT 架构实践

第 6 章 新一代架构下的运维管理

第 7 章 架构效能分析

第 1 章 引言

自人类社会有了经济活动之后，作为信用中介角色的“银行”就应运而生。银行为各种类型的经济活动提供支持，最早是提供存（吸收存款）、贷（发放贷款—）、汇（资金汇兑）这些最基础的金融服务的机构。但随着人类经济文明的发展，经济活动变的多样化，推送了金融行业的繁荣。一方面，金融行业衍生出更多不同类型的金融服务和产品，以及提供这些产品和服务的金融机构；另一方面，金融行业的老大哥“银行”所提供的金融产品和服务也随之变得越来越复杂。但无论银行的业务变得多复杂，它的核心职责依然是要记好账。

由于银行所维护的账本记录了经济活动参与人的权益，因此确保账本记录的准确性、安全性、私密性以及持续提高记账效率，一直是全球银行业务发展过程中全行业重点关注的基础能力。

自 20 世纪中期以来，计算机的发明及应用为银行业的发展提供了重大技术突破契机，过去依赖纸质账本、人手记账的作业模式，随着计算机的应用发生了根本性改变。账务数据实现了电子化，它们经由计算机程序自动运算，并且被记录到电子媒介上，自此银行在账务处理的质量和效率上都出现了跨越式的提升。

不过，随着近年来互联网的崛起，银行的角色逐渐发生了一些微妙的变化。过去银行一直扮演着账户管理者的角色，然而由于银行业的信息化步伐远比其他行业迅速，比如银行网点、ATM、POS终端以及网上银行、手机银行等业务实际上衔接了离线（Offline）世界和在线（Online）世界，从而使得银行业的信息系统成为跨行业信息化的枢纽。可以说，银行事实上是第一代“线上线下”（O2O）业务的代表。

互联网所带来的的信息化革命，大大推动了各行各业的信息化、网络化，从而导致银行作为连接离线世界和在线世界的枢纽角色，逐步受到了大小互联网平台的冲击。这些互联网平台通过切入各类生活场景，掌握了互联网上的海量用户入口，积累了规模更大、内容更丰富的交易和用户行为数据。银行与客户的关系逐步被这些互联网平台蚕食和隔断，与银行也逐渐变为在互联网平台背后提供金融账户服务的服务提供方。

更有部分提供第三方支付服务的企业，包括国外的 PalPal、国内的支付宝以及微信支付等，正在尝试通过其自身提供的“钱包”，替代银行账户扮演的角色，并且已经取得了初步成功。

《银行3.0：移动互联时代的银行转型之道》一书中预言，未来银行将会逐步消失，但银行服务将会以其他形式继续存在。

面对互联网这一轮信息化革命所带来的的冲击，大小银行面临转型升级的压力前所未有，必须通过自身求变来提升竞争力，从而获得更有利的发展空间。近年来，不少传统银行推出了直销银行业务；国内外也开始出现一些互联网银行，以无网点、轻资产、高科技方式来提供金融服务。这些都是银行业界为了应对市场发展趋势及竞争环境的变化而做出的尝试，试图通过创新经营模式来打造新一代银行。但创新的经营模式自身也会带来新的挑战：不一样的用户习惯要求不一样的用户体验；不一样的业务规模需要不一样的容量配置；不一样的服务渠道定义不一样的安全机制；不一样的产品定价依赖不一样的成本结构。最终结论是，不一样的银行需要不一样的信息系统架构来支撑。正因如此，在互联网浪潮的冲击之下，银行业也迎来了新一代银行 IT 架构的技术演变。

作为中国首批获得银监会批准筹建的 5 家民营银行之一，微众银行以互联网银行作为自身战略定位，其科技团队从一张白纸开始设计新一代银行 IT 架构，用了一年时间完成并实施，而且其构建成果也经历了一系列实际业务考研。微众银行这次前无古人的实践，为新一代银行 IT 架构的发展方向提供了重要启示，为银行业开辟了一条创新发展道路，也为后来者提供了可资借鉴的宝贵经验。

“互联网+”已被提升到国家战略的高度，商业银行业也面临着互联网时代的发展需求。在这样一个大趋势下，出现了“普惠金融”的发展模式。互联网作为一个不眠不休、无边界的“服务媒介”，为银行带来了全天候不间断寻求高质量银行服务的海量用户。这些用户按照银行传统的客户评价体系来看，往往属于“非高净值个人客户”或“小微企业”，而传统金融机构的业务成本和技术体系暂时难以为这些“普通人”提供更便利、快捷、随需随用的金融服务。与此同时，在互联网生活的熏陶下，“普通人”产生了五花八门的金融需求和众口难调的客户体验。更加直观的是海量用户将带来不间断的业务请求，并在业务高峰时期带来海量的并发需求。由此，对互联网时代的银行信息科技而言，以尽量低的成本为目标客户群提供高质量、稳定、高性能的基于互联网的银行服务，是“互联网+”时代下的普惠金融给银行 IT 部门带来的全新挑战。

传统银行服务与“互联网+”时代的银行服务模式差异：

• 服务理念
  高端客户创造价值
  普惠金融

• 服务模式
  线下人工服务
  在线智能服务

• 服务对象
  固定用户接入
  海量用户接入

• 业务网络
  分行网络覆盖方式
  互联网覆盖方式

• 科技诉求
  风险为主，兼顾成本
  风险与成本并重

微众银行承载着服务大众人群和小微企业的社会责任，也承担着探索普惠金融、互联网银行发展道路的重任。作为不大量开设物理网点、仅依托互联网为目标客户提供服务的“轻资产互联网银行”，微众银行的业务发展模式和 IT 系统的实现必然与传统银行有着较大的差异，它走的是一条“高效率、低成本、广覆盖”的创新发展道路，通过特色化、差异化和创新型服务，为社会大众、小微企业提供高效、便捷、普惠的金融服务。

在创立之初，微众银行便从全行战略的高度确立了“普惠金融为目标，个存小贷为特色，数据科技为抓手，同业合作为依托”的整体战略定位。在整个战略定位中，信息科技的作用显得尤为重要，它是实现个存小贷为特色的普惠金融业务的重要支撑。为了确保业务战略目标的实现，微众银行制定了“纯线上、轻人力、强系统”的科技发展战略，通过完全依托互联网作为客户服务渠道，规避线下渠道建设以及运营所带来的的高昂成本，最终实现整体运营成本的大幅度降低、运营效率的明显提升。

众所周知，过去以“IOE”（IBM 主机、Oracle 数据库和 EMC 存储技术）为代表的西方高端商业解决方案主导着中国银行业的信息科技建设。这些性能稳定、技术成熟、工程化程度高的成套解决方案，帮助中国银行业快速地缩小了与西方发达国家的差距，有力地支撑了中国银行业过去二三十年的发展。

随着银行业自身业务形态和业务量的发展，“IOE”技术体系的弊端逐渐显现：

• 单机性能出众，但其扩展能力有限，性能无法无限扩展，只能通过更换更加高级的型号来满足需求，这种升级过程的复杂度和操作风险都是非常高的

• 建设成本昂贵，运维成本一致居高不下。由于技术本身不向客户做技术转移，后期运维工作只能不断依赖厂商提供有偿服务。

• 由于银行本身不掌握技术，对于自身需求的技术可行性无法做出有效判断，关键创新往往依赖 IOE 厂商的评估与支持，无法客观地支撑业务的创新。

• 由于无法做到安全可控，IOE 技术对于中国的商业银行而言，完全是黑盒技术。银行作为一个关系国计民生的行业，如果其核心技术不能做到安全可控，必然为整个社会的稳定留下一个明显的安全风险。

以 IOE 为代表的传统银行技术体系已经无法提供一个安全可控、高性能、高度拓展、高度可靠且低成本的运行环境来支持普惠金融业务的发展，这也成了银行业发展的一个关键瓶颈。因此需要融合互联网和传统银行的技术理念来应对普惠金融对银行 IT 架构带来的全新挑战，充分汲取两个领域各自的技术特点。

六大新一代银行 IT 架构建设目标：

• 高性能
  亿级客户量、千万级别日均交易量

• 高弹性
  容量拓展性：通过严谨的容量规划，以及稳定、可预期的单处理节点容量，在保证节点稳定性、数据可靠性和业务高可用性的同时，根据业务发展的节奏，通过新增节点来实现容量的拓展
  性能拓展性：当存量业务出现性能瓶颈时，则通过存量节点的纵向拓展来解决

• 低成本
  高性价比，充分利用开源技术与低端服务器资源，有效降低架构建设和后续运营的相关成本投入

• 高可用性
  快速恢复：满足监管对恢复点与恢复时长的要求，提供全天不间断的银行服务
  高冗余与高密封舱化：全架构采用 2N 级高冗余度设计，杜绝单点风险
  多维度高可用性设计：在保证架构自身整体高可用的同时，为上层应用提供高可用性支撑

• 低风险
  架构整体的高可用性：风险发生的概率降低
  分布式架构资源充分隔离：单点故障的影响范围可控
  自动化运维体系：快速恢复故障

• 高规范性
  由标准化的物理及逻辑单元构成，符合行业的所有监管标准，从而实现自动化运维与规模化管理
  架构标准化、技术标准化、应用标准化

基于安全可控技术构建新一代银行 IT 架构：

• 传统银行
  以柜面为主，结合电子渠道

• 微众银行
  以互联网为主，没有线下渠道，互联网为其带来了海量客户。这些客户有着不同的需求，并希望享受到全天候不间断的高质量的银行金融服务。海量的用户带来了海量的交易和需要处理和存储的海量数据。

设计原则：

• 高性能
• 高弹性
• 高可用性
• 高规范性
• 低成本
• 低风险

微众银行依托分布式架构和相关开源技术产品研究的成果，以整体规划、业务驱动、快速迭代、按需投放、全局规划为基础，以业务需求驱动为导向，形成以安全可控架构建设为核心的整体建设思路。

• 新架构完全采用 X86 服务器，基于低端开发的硬件平台，提供整个架构运行所需要的计算及存储能力，没有采用任何高端硬件产品或解决方案，彻底摆脱了传统国外服务商对银行硬件资源的垄断和控制。

• 新架构完全采用开源技术构建基础架构，基于开源技术（如 Linux 操作系统、KVM 虚拟技术以及基于 MySQL 的数据库）进行深度二次开发，在确保技术完全安全可控的前提下提升了开源产品的可用性、可维护性和安全性。

• 新架构完全采用分布式架构，所有对客户提供的业务服务分部在不同的标准节点上，每个节点提供对一个客户群的全部服务，全网由多个这样的节点构成，从而实现架构横向与纵向的无限拓展，摆脱了传统集中式架构拓展性差的局限，大大降低了架构拓展的成本和风险。

第 2 章 分布式架构理论及典型实践

分布式系统

由多个部署在不同计算机上的模块构成，模块之间通过网络进行基于消息的通信与协同，互相交互以完成一项共同的任务。

• CAP 理论：关于运用分布式计算架构时需要充分考虑的基本原理
  一个分布式计算架构不可能同时满足以下三个特性，最多只能同时满足其中的两个，需要作出权衡和取舍
  1. 一致性（consistency）：每个请求获得都是最新写入的数据
  2. 可用性（availability）：每个请求都能获得一个响应，虽然不保证一定是最新的数据
  3. 分区容忍性（partition tolerance）：系统在网络故障导致的分区状态下依然能保持运行

架构师：

• 存储可靠性：持久数据存储、架构容灾基础、交易事务保障、安全可贵保证
• 确保事务的 ACID 特性

产品经理：

• 产品可用性：用户数据不能丢失或泄露
• 用户体验保障：页面等待超过8秒，用户基本上就会选择放弃
• 用户活动保障

数据库管理员：

• 省时省心省力：提升运维管理效率、降低复杂度、稳定性、可管理性、性能

金融数据库的九宫格挑战：

分布式数据库核心技术：

• 数据高可靠性
  基于数据冗余，并兼顾同步中和同步后的数据一致性状态
  一份数据有一个主副本 master 和多个从副本 slave，一般是 2 个，主从副本之间通过以下三项主要技术保证数据的一致性和性能问题：

  1. 基于快速复制通道，实现高性能、强一致的主从数据同步
  2. 支持灵活的多地区多园区复制策略，同步和异步灵活按需定制
  3. 覆盖同步后的数据一致性状态检查

• 系统高可用性
  基于故障 - 停止机制优化故障探测时间和故障转移时间

  1. 故障探测：基于“心跳” + 租约的方式，同时通过 SQL 服务质量来发现节点的亚健康状态
  2. 故障转移：重点优化从副本在提升主副本时，从副本需要用完本地同步日志的时间

• 高性能事务处理能力

  1. 多种业务场景下的 MySQL 参数调优
  2. 定制服务器配置
  3. 基于 Oracle 以及 MySQL开源社区版本内核深度定制 MySQL 内核
  4. 通常会在 SQL 层和 InnoDB 引擎上进行相关优化，从而提升事务处理能力

分布式数据库运维管理：

• 数据库管理

  1. 自动部署：机房、网络、操作系统和数据库版本的部署安装
  2. 按需生产：支持内存和硬盘完全解耦的方式，按照业务需求来一键式生产出数据库实例
  3. 版本升级：自动维护操作系统和 MySQL 版本的升级，通过专业的升级方案来及时修复漏洞，把变更风险降低到可控范围，保证线上业务稳定运行
  4. 监控告警：通过 MySQL 自身具备的特性数据进行采集和监控，支持分钟级异常告警

• 备份回档

  1. 备份：支持物理备份和逻辑备份，且备份数据和相关日志存储在专有的、可靠的备份存储集群与日志存储集群中，支持表、库和实例多维度快速回档到 N天的任意时刻（N 取决于数据库自身数据量与相关存储集群的容量间的关系）
  2. 回档：通过备份数据加日志数据的方式来完成数据回溯

• 弹性拓展

  1. 拓展：通过只读实例组来支持读拓展、实例规格拓展和分库分表，在只读实例组中，多个从副本自动负载均衡和进行异常剔除（异常包括从副本死机或者主从差距过大），从副本严格收拢读写权限
  2. 分库分表：自动分库分表基于分区表来实现数据分片功能，支持范围分区、哈希分区和列表分区，在子分区内，SQL 和事务 ACID 特性完全与单机版兼容
  3. 查询：在分布式查询方面，通过支持有限索引条件下推来提升分布式查询性能，为了简化异常处理，通常系统不会支持跨机外部事务

• 线上调优
  主要通过数据库实例监控诊断来完成，通过审计插件来采集实例内部从服务器到引擎的信息，根据规则，生成相应健康诊断报告和调优建议

• 安全审计
  通过审计插件完成

  1. 访问安全审计：主要是指对 IP、账号、对象、越权操作记录、不活跃账号的升级
  2. SQL 安全审计：主要是指对 SQL 注入、宽松条件的 增删改查操作、低效 SQL 语句的审计

• 成本控制

  1. 硬件成本
  2. 软件成本
  3. 维护成本

分布式缓存

• 基于内存 / 高性能 SSD 介质的数据存储服务，主要解决高并发、大数据场景下，热点数据访问的性能问题，提供高性能的数据快速访问能力，减轻关系型数据库的压力
• 将需要频繁访问的数据以键值对的形式写入缓存系统中，下次要获取同样的数据时，先从缓存中按键读取，如果命中旧直接使用缓存数据，不需要再访问数据库，命中率越高数据库的负载就越低。需要保证数据库与缓存数据一致，即当数据发生改变时，务必在更新数据库的同时，也更新缓存中的数据

缓存优点：

• 数据库负载大幅下降，大量的读请求被缓存过滤，不再到达数据库
• 答复降低数据访问延迟，特别是读请求的延迟，不再需要磁盘的输入和输出（IO）
• 系统可扩展性大幅增强，数据库不再是瓶颈，可以通过增加缓存来提升系统的吞吐能力

缓存问题：

• 容量：单机缓存容量有上限，但随着数据量的增加，如果缓存容量不随之增加，那么命中率会越来越低
• 高可用：单机缓存存在单点失效的问题，如果缓存失效，所有原来缓存挡住的请求，仍然会落到数据库中，从而造成雪崩效应，直接把数据库压垮
• 扩展性：单级缓存的处理能力也有上限，一旦单机处理不过来，缓存系统反而会成为瓶颈

分布式缓存核心技术：

• 分片技术
  将海量的数据切分成足够多的小片，每一片都包含整体数据的一部分，然后将这些数据分布存储到不同的存储机上。常见的分片技术包括一致性哈希和静态哈希等，根据当前请求的键值决定到哪个存储机上去获取数据，或者通过分布式缓存系统提供的接入层进行数据分发。
  当数据增长到一定程度的时候，分布式缓存系统可以自动进行扩容，将数据过多的存储机的分片搬迁到新增的存储机上。扩容过程应保证不影响数据的可用性。
  除了因为容量不足而进行扩容外，还可以将热点数据所在的分片单独放到一台新增的存储机上，使得系统的整体吞吐能力得到提升，还能不影响其他分片的数据访问。

• 主从结构
  分片只能解决容量的问题，每个分片所在的存储机仍然是单点，任何一台存储机失效，都会导致这部分数据的访问直接透传到数据库。因此，通常会为每台存储机增加一台或多台备机，当存储机因为网络或者主机本身的故障不可用时，分布式缓存系统将自动进行主备切换，让用户的访问切换到可用的备机上，同时也要为新的主机建立另一份备用数据，以保证整体数据的份数不变。这样任意单节点的失效都不会影响系统的可用性。

• 分层结构
  有些分布式缓存系统出了提供存储机之外，还会提供无状态的接入层。接入层一方面为了屏蔽客户端对分片的感知，使客户端的请求可以落在分一台接入机上，由接入及来判断应该访问哪一台存储机，另一方面使得系统可以平行拓展，一旦接入及的负载过高，可以随时增加新的接入及来提升整体的吞吐能力，从而提升系统的可扩展性。

• 无单点的主副本

• 实时可视化运维系统

• 自动扩缩容

• 自动重建备机

• 自动故障后搬迁

• 自动数据均衡

• 数据冷备份

• 跨机房容灾 / 异地容灾

分布式缓存特点：

• 高性能
  高吞吐、低延时的访问，减少磁盘 IO 和数据库的压力

• 高弹性
  支持弹性扩展，根据数据量以及并发请求量，动态增加或减少节点来应对数据访问负载，提供可预测的性能和扩展性，最大限度地提高资源利用率

• 高可用性

  1. 基于冗余机制，实现无单点失效
  2. 支持故障自动发现，透明地实施故障切换，不会因为服务器故障而导致缓存服务终端或者数据丢失
  3. 动态扩展时自动均衡数据分区，同时保障缓存服务持续可用
  4. 更高级的分布式缓存系统还包括跨机房和跨域的容灾特性

• 高可靠性

  1. 存储机的主备同步
  2. 定期备份及删除 binlog，针对机房掉电等极端情况可自动恢复数据
  3. 冷备中心保留若干天的存档数据，支持数据的追溯和回档

• 易用性

  1. 提供与拓扑结构无关的 API 接口
  2. 提供数据与管理视图
  3. 动态扩展或失效恢复时无需人工配置
  4. 自动选取备份节点
  5. 提供图形化的管理控制台，便于统一维护

分布式缓存典型应用场景：

• Web 页面缓存
• 应用对象缓存
• 状态缓存：包括 Session 回话状态及应用横向扩展式的状态数据等
• NoSQL 存储：将数据保存在磁盘上，并保证主备数据是强一致的，可以直接将这种分布式缓存系统当做一个分布式的非关系型数据库来使用，而不再需要关系型数据库

分布式存储

• 通过分布式技术，将网络中不同节点上的存储设备通过分布式应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能。

• 数据分散存储在分布式存储系统的各个独立节点上，供用户透明地存取。

• 采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用管理服务器定位存储信息

分布式存储特性：

• 可扩展性
  可以扩展到几百台甚至几千台的集群规模，而且随着集群规模的增长，系统的整体性能表现为线性增长。

• 数据高可靠性
  数据采用多副本或者网络 RAID 的方式进行存放，同时数据读写过程可以保证多个副本的强一致性（strong consistency），这样即使因为服务器或者磁盘故障导致某个副本数据丢失，仍可从其他副本中读取数据。

• 服务高可用性
  一个节点出现故障，不会影响整个系统的正常运行，因为故障节点的数据在其他存活节点上有冗余（副本），且存活节点能够继续对外提供服务。

• 低成本
  分布式存储系统的自动容错、自动负载均衡机制使其可以构建在普通 X86 服务器上。另外，现行扩展能力也使得增减机器非常方便，可以实现自动运维。

分布式存储主要挑战：数据、状态信息的持久化，在自动迁移、自动容错、并发读写的过程中保持一致性

• 数据分布

  1. 将数据均匀分布到多台服务器上
  2. 之后如何实现跨服务器读写操作

• 一致性
  将数据的多个副本复制到多台服务器上，即使在异常情况下也能够保证不同副本之间的数据一致性

• 容错

  1. 检测服务器故障
  2. 自动将出现故障的服务器上的数据和服务前移到集群中的其他服务器上

• 负载均衡

  1. 新增服务器和集群在正常运行过程中如何实现自动负载均衡
  2. 数据迁移过程中保证不影响已有服务

分布式存储几大分类：

• 分布式块存储

  通过聚合集群内本地服务器的磁盘容量和性能，以创建虚拟存储池，通过软件对虚拟存储池进行管理，并向计算节点提供块设备访问接口。

  可以满足服务器虚拟化，数据库、开发测试与虚拟桌面等场景下对性能、容量、可靠性的要求。

  1. 采用横向拓展的分布式架构，具有很强的扩展性，规模可以扩展到上千个节点，且随着存储服务器数量的增加，吞吐量和每秒进行读写操作的次数也会呈线性增长。
  2. 可以实现弹性伸缩，按需增减节点。
  3. 分为三大模块：
     1. 元数据管理模块：配置管理块存储单元与元数据信息、集群管理节点、IO 请求路由、拓扑、卷信息管理、节点状态监控等，同时还负责设备的分配、容量管理等
     2. 存储服务器：负责数据分布和存储，对逻辑资源池进行有效分配和管理。一定数量的块（chunk）构成一个块组（chunk group），客户端进行读写的时候从元数据存储服务器获取数据所在的块组，具体的数据到块的映射可以通过特定算法进行计算，可以大大减少元数据服务器管理的元数据，并减轻对应的负载。
        同时为了实现多副本数据存放，不同服务器上的多个块组构成一组（group），同一组存放一模一样的数据副本，实际写数据的时候显写主组，再同步到次组，只有所有副本都写成功了才算真正的成功。
        在读数据的时候通过算法定位后，只需要读取其中一个副本即可。
     3. 客户端模块
  4. 数据均衡机制保证了上层应用对数据的 IO 操作均匀分布在不同的存储服务器的不同硬盘上，不会出现局部的特点，从而实现全局负载均衡。
     1. 系统自动将数据块大三存储在不同服务器的不同硬盘上，冷热不均的数据会均匀分布在不同的服务器上，不会出现集中的热点
     2. 数据分片分配算法保证主用副本和备用副本在不同服务器和不同硬盘上的均匀分布，也就是说每个硬盘上的主用副本和备用副本的数量是均匀的
     3. 当扩容节点或者故障减容节点时，数据恢复重建算法保证重建后系统中各节点负载的均衡性

• 分布式文件系统

  运行在多台计算机上，相互之间通过某种方式实现通信，从而将集群内的所有存储空间资源整合、虚拟化，并对外提供文件服务的文件系统。

  分布式文件系统与文不是块存储系统很相似，区别在于两者所提供的访问方式不一样：

  • 分布式块存储提供块设备接口，通过块协议进行访问
  • 分布式文件系统提供文件系统接口，通过 OS 系统调用进行访问

  主要解决数据的分布和数据多副本的一致性问题，以及在异常情况下的数据迁移和数据修复问题。

• 分布式对象存储

  面向对象的、海量的互联网存储，以 AWS S3 为代表的通过 HTTP 接口提供访问的存储服务或者存储系统。

  提供键值对方式的 RESTful 数据读写接口，并且常以网络服务的形式提供数据的访问。
  对象名称就是一个地址，一旦对象被设置为公开，所有人都可以进行访问。

  主流使用场景为存储网站、移动 App 等互联网 / 移动互联网应用的静态内容（视频、图片、文件、软件安装包等）。

  最大优势是超大规模数据管理能力（性能不下降）：

  • 文件系统
    采用属性结构对所有文件和目录进行管理，当文件或目录过多时，检索性能就会极大下降
    系统级接口
  • 对象存储
    只有目录和对象两层结构，这种扁平化的结构令对象数量即使达到百亿级别，检索速度依然不会有大的变化
    应用级接口

分布式消息总线

消息总线的主要功能：

• 消息传递
  基本功能
• 服务管理
  找到提供服务的模块，发送方和接受方不需要了解彼此，仅需将消息交给消息总线即可，消息总线根据消息的请求内容查找提供服务。
• 异步解耦
  消息接收方可以异步处理消息后再将结果返回给发送方，在有些情况甚至不需要返回处理结果。消息发送者和消费者无需感知对方的存在，实现发送和接受的异步解耦。
• 屏蔽差异
  不同模块之间通过消息总线来实现交互，服务提供者和消费者仅仅关心消息的发送与读取，和平台、语言等均无关系。
• 流量控制
  消息总线可以在不堵塞消息发送者的前提下暂存消息，根据接受者的实际处理能力做到按需推送，起到削峰填谷的作用，在营销、秒杀活动中尤为重要，可以保证消费者不会被超过服务能力的请求压垮引发雪崩。
• 广播订阅
  在某些情况下，对于一条消息，需要在不同的模块中各处理一次，广播订阅功能可以做到一次发送多次接受消费，发送的消息可以被不同场景中的消费者接受订阅，增加新模块无需任何改动，方便扩展。
• 负载均衡
  对于有多个接受者的情况，消息总线可以将请求均衡地推送给各个接受者，接受者也可以依据本身的处理能力来判断是否接受。另外，消息总线还可以判断出消息接收端是否异常，对于异常的接收端可以进行故障隔离，以免扩大影响范围。
• 审计鉴权
  判断发起请求的模块是否合法，服务之前需要授权才能互通，对于非法的访问会返回鉴权失败。
• 可靠转发
  保证交互数据不丢失
• 故障自愈
  应该预备一定的容错性，以便在某个节点发生故障时不会影响服务的可用性。当主节点异常时，系统能及时发现并提升备份节点来继续服务。
• 性能问题
  单机处理能力是有上限的，分布式系统中的模块个数以及模块间的请求量是无法预计的，因此必须保证消息总线的处理能力不是分布式系统的性能瓶颈。
• 跨中心
  分布式系统的不同模块有可能分布在不同的数据中心，因此消息总线必须具有跨区域传输的能力，每个请求模块就近接入，由分布式消息总线来做透明底层联通。
• 监控审计
  对于分布式系统，优势需要对分布在不同机器甚至地区的模块间的消息交互进行审计，消息总线作为一个通信总控可以全量备份一定时间段内所有通过总线的消息，以备审计使用，这在金融领域十分常见。

消息总线以消息中间件为底层数据通信基础，并在这一基础上增加了服务目录、鉴权管理、流量控制、故障隔离、安全审计等功能，为分布式系统提供基础架构支撑。

分布式消息很好地解决以下问题：

• 分布式系统的不同组件分布在不同的网络计算机上，不同机器进程间如果直接使用网络应用程序不变成接口编写跨进程通信，会是一件非常麻烦的事情，可以避免编写大量的底层 socket 代码。

分布式消息总线的核心特性：

• 高可靠性：包括发送、存储和投递三个阶段

  1. 发送阶段：消息发送者确保得到消息总线返回的成功结果后才算完成发送，否则需要充实以避免发送阶段的消息丢失。
  2. 存储阶段：消息总线受到发送端的消息后需要多副本（防止单节点宕机后丢失消息，需要保证副本间的数据一致性）、持久化存储（避免在系统缓存中的消息还没来得及持久到磁盘等介质时节点断电等异常造成的数据丢失或损坏）成功后才能返回成功的消息。
  3. 投递阶段：消息总线将消息投递给接收端后并不能马上删除消息，而是在接收端处理完消息并明确告知后，才能删除这条消息并投递下一条。主要是为了防止接收端受到消息还未来得及处理就宕机的场景，在接收端看来这就相当于丢失了消息。

• 高可用性：主要由数据冗余（确保节点故障时数据不丢失，保证 RPO）和故障快速发现切换机制（消息生产者和消费者能够及时发现并切换到可用的消息总线节点，保证 RTO）来保证。

• 高弹性：通过流量控制实现削峰填谷，需要支持亿万级消息的长时间堆积。为了使消息以方便不能堵塞发送端，另一方面不能压垮接收方，消息总线起到蓄水防洪、按需流控的作用。分布式消息队列突破了单机存在的存储上限，使得消息总线的存储容量理论上达到无上限。

• 易用性：支持对每条消息的生产、消费等整个流程进行可视化跟踪，方便开发运维 Debug 定位问题。

消息总线典型应用场景：

• 异步解耦，错峰流控
  如果系统模块间时直连同步调用模式，消息接受者出现任何异常，都会影响发送者的正常服务。通过分布式消息总线来实现异步解耦后，消息发送方和急售房无需感知对方的存在，同时消息总线还可以缓存消息，防止大量请求涌入后引起雪崩，提高了分布式系统的整体可用性。

• 一次发送，消息多场景服用

分布式负载均衡网关：

• 网关
  连接不同网络的关口
• 负载均衡
  负责将请求按照指定策略分发给后端的服务器，能够均衡请求压力，发现和屏蔽后端服务故障，提升服务的稳定性和资源利用率。
• 分为硬件负载均衡（由厂商提供专用的软件和硬件）和软件负载均衡（运行在通用的服务器上）
• 流量转发
  根据请求的特征字段将请求转发给指定集群，比如 HTTP 协议的头部字段、URL 内容等
• 协议转换 / SSL 卸载
  将客户端不同的应用层协议转换成服务器支持的统一协议，减少后端服务的协议适配压力，提升业务开发效率，节省研发成本。
• 安全防攻击
  分析请求特征和它的安全行为，比较适合实现常见的安全功能，比如黑名单、访问频率限制、WAF（应用层防火墙）等。

负载均衡实现原理：

• 域名解析服务（DNS)
  提供一个域名作为负载均衡器的访问入口，然后给该域名绑定多个后端机器 IP 作为 A 记录，用户访问域名时，通过轮询方式返回不同 IP，实现负载均衡
  缺点：只能支持轮询的策略，受限于 DNS 缓存生效时间，无法实现快速地健康检查机制，而且每次返回的都是真实的服务器 IP 地址，存在安全隐患等缺陷

• 内容分发网络（CDN）
  首先将大量内容缓存到各个地方的服务器集群，用户访问时，返回离用户最近的或者负载最低的集群地址，实现负载均衡
  优点：提升用户访问速度，减少主站压力
  缺点：方案比较复杂，成本也很高

• HTTP 负载均衡
  可以针对 HTTP 协议的任意特征字段进行负载均衡，包括 HTTP 协议的 URL、头消息，甚至主体内容

• 链路层负载均衡
  负载均衡器受到用户请求后，通过修改请求的 MAC 地址来实现负载均衡
  优点：性能最高
  缺点：负载均衡网关必须和业务集群的机器在同一个 LAN 或者 VLAN 内，否则无法通过 APP 协议找到业务机器 IP；；业务集群的机器必须绑定 VIP，否则即使受到广播包也会丢弃掉。

• IP 负载均衡
  通过修改源 IP（SIP）或者目的 IP（DIP）实现负载均衡
  使用最多、使用场景最广且性能很好地负载均衡方案

负载均衡调度策略：

• 轮询 / 加权轮询

• 随机算法

• 最小响应时间
  通过记录每次请求所需的时间，得出平均的响应时间，然后根据响应时间的长短选择响应时间最短的机器。
  该策略能较好地反映服务器的状态，但是由于是平均响应时间，时间上有些滞后，无法满足快速响应的要求。

• 最小连接数
  记录当前时刻每个后端服务器正在处理的连接数，然后选择并发连接数最少的后端服务器。
  该策略能够快速地反映服务器的当前情况，较为合理地分配请求，适用于对当前系统负载较为敏感的场景。

• 哈希
  常用的哈希包括 IP 哈希、URL 哈希等，将输入按照指定的哈希算法生成响应的哈希值，根据哈希值取模在选择对应的后端服务器。
  该策略能够将相同 IP 或者 URL 的请求转发到相同的后端服务器上，使用有状态的服务场景。
  缺点：如果后端服务器发生变化（比如死机或者增加机器），请求和服务器的对应关系也会发生很大的重排。如果后端是 Cache 服务，会导致 Cache 命中率大幅降低。

• 本机 / 本机房优先

• 一致性哈希

分布式系统面临着远比单机系统更加复杂的环境，包括不同的网络环境、运行平台、机器配置等。负载均衡网关在如此复杂的环境中，通过运用各种不同的负载均衡策略，能够极大地减少各类错误的发生，提升系统的可用性和整体性能。

第 3 章 当前主流的 IT 架构分析

技术体系架构：对整个 IT 规划起到重要的支撑作用。

• 描述了定义所交付的业务系统采用的技术环境结构
• 建立和维护一套评价技术项目的核心技术标准
• 建立技术和业务系统有机结合的一种行之有效的方法
• 建立技术实现决策的框架
• 为企业的技术环境保持良好的发展态势提供管理架构

集中式松耦合架构理论和实践

耦合性架构

模块化设计理论：设计具有独立功能，并且和其他模块间没有过多相互作用的模块。

分而治之：把复杂的问题分解成许多容易解决的小问题。

耦合性：对一个软件结构内不同模块之间互联程度的度量。
耦合性强弱取决于模块间接口的复杂程度、调用方式和传递的信息。
耦合性从低到高，模块独立性从高到低：

• 非直接耦合
  模块之间完全独立
• 数据耦合
  模块间仅仅交换数据信息
• 标记耦合
  模块间通过参数表传递记录信息
• 控制耦合
  一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能
• 外部耦合
  一组模块均访问统一全局简单变量而不是统一全局数据结构，而且不是通过参数表传递该全局变量的信息
• 公共环境耦合
  模块之间通过一个公共数据环境相互作用
• 内容耦合
  一个模块可以直接访问另一个模块中的数据，或者不通过正常入口直接转到另一个模块中，或者一个模块有多个入口，或者两个模块有部分代码重叠

软件设计采取原则：尽量使用数据耦合，少量使用控制耦合和特征耦合，限制公共环境耦合的范围，完全不允许内容耦合，最终降低模块间接口的复杂性。

追求尽可能低耦合性（松散耦合）的系统架构，研究、测试或者维护任何一个模块，而不需要对系统其它模块有很多了解。模块间的耦合程度直接影响着系统的可理解性、可测试性、可靠性和可维护性。

从风险分散的角度出发，针对集中式松耦合架构的局限性，以分布式松耦合架构取而代之。在每个节点上以客户为单位，部署用于支撑该客户群的全部应用系统，每个应用系统在保持集中式松耦合架构特性的同时，在每个客户服务节点中有独立的物理资源，每个节点成为一个自包含的客户服务节点。

• 一个客户的全生命周期集中在一个节点上
• 设计单一客户的交易处理在单一节点上完成，节点间无依赖关系

分布式松耦合架构打破了银行应用系统间高依赖性对集中式松耦合架构整体可用性的影响，将单节点故障的影响范围从一个业务的所有客户（最终可能升级成为全部客户的全部业务），变为部分客户的全部业务。随着节点数量的增加，每个节点所服务的客户群在全行客户群中的占比会越来越低。由此可见，分布式松耦合架构通过有效的隔离，控制了单点故障可能引发的风险。

同时，依托分布式松耦合架构，通过节点数量来提升整体架构的并发处理性能。银行业务的并发来自不同的客户，单一客户无法造成系统并发处理压力。因此，当客户被分配到不同的节点上时，由于节点的自包含特性，架构整体处理性能在多客户并发的场景下，随着压力被分配到了更多的节点上，架构整体性能也会得到显著的提升，此外，但应用的研发难度大大降低，对硬件性能的依赖也大大降低。

在这个架构体系下，节点数量和客户米达很大程度上决定了分布式松耦合架构对于风险的分散和性能的提升。但是，节点数量的增加对于架构的整体建设和运营将提出巨大的挑战。因此，节点规划设计的标准化、相关技术的简约化成为分布式松耦合架构的工作重心。

集中式系统与分布式系统

集中式系统：事务的 ACID 特性

• 原子性（atomicity）
• 一致性（consistency）
• 隔离性（isolation）
• 持久性（durability）

分布式系统：CAP 理论和 BASE 理论

• CAP 理论
  一个分布式系统不可能同时满足一致性（C）、可用性（A）和分区容忍性（P）这三个基本需求，最多只能同时满足其中的两个。

• BASE 理论
  基本可用（basically available）
  弱状态（soft state）
  最终一致性（eventually consistent）

BASE 理论面向的是大型高可用、可扩展的分布式系统，跟传统事务的 ACI 特性是相反的。它完全不同于 ACID 的强一致性模型，剔除通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终依然会达到一致状态。

在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID 特性与 BASE 理论往往又会结合在一起使用。

第 4 章 新一代银行 IT 架构分析

• 六大设计原则：高性能、高弹性、低成本、高可用性、高规范性、低风险
• 分布式松耦合结构
• 分布式单主多副本架构

新一代架构概念模型解析：

从风险分散的角度，在集中式松耦合架构的基础上，横向切分集群，每个节点以客户为单位，部署用于支撑该客户的全部应用系统并拥有一个客户的所有数据，形成由多个可扩展的标准化客户处理节点构成的分布式松耦合架构。

为了规避 CAP 理论对分布式多节点架构的限制，将多主节点架构降级为单主多副本模式，在保证高可用性的前提下，牺牲一定的处理性能。对于任何一份数据，在保证存储至少三个副本的前提下，所有副本之间实现数据强同步，但仅由一个主副本对外提供全面的读写服务，其余从副本值提供有限的度服务或者不提供服务。这样做虽然牺牲了性能，但确保了架构可用性。

同时，通过分布式架构在降低了单集群的负载要求后，通过增加集群数量实现了架构整体的高性能。

关键概念：

• 数据中心（Internet Data Center，IDC）
  微众银行新一代互联网架构规划与管理的物理单元

  1. 网络吞吐能力以及安全防护能力
  2. 数据中心根据本中心定位，选择需要的模块组成数据中心的物理架构
  3. 每个模块的标准化包括其网络架构、物理部署、硬件设备型号等，但不包括其容量，模块的容量可按需横向扩展

• 数据中心节点（Data Center Node，DCN）
  微众银行新一代互联网架构规划与管理的逻辑单元，每个 DCN 是一个物理资源独立、应用逻辑自包含的节点，用于承载一个特定的客户群或者提供一组特定的服务。

  1. 分布式架构最小的逻辑部署单元
  2. 拥有独立的物理计算和存储资源，不同节点之间不共享
  3. 不同节点之间共享数据中心级的资源，主要包括：数据中心的基础设施、基础网络和数据中心的公共服务（例如消息总线等）
  4. 数据中心节点属于并值属于一个 IDC 中的一个物理模块
  5. 按照不同的用途，可以分为xxx

• 微众银行应用架构
  由应用域、应用系统、应用子系统、应用进程、应用服务和服务场景组成

• 标准账户
  在进行架构容量规划时，需要选择一种类型的账户作为标准，来衡量架构在当前资源部署形势下的整体容量。我们选择了业务逻辑清晰、稳定的个人人民币活期存款账户作为标准账户，其他类型的账户按照业务复杂度、数据量等维度定义折算系数，折算为标准账户后进行容量规划与评估。

实施成果：

• 2015 年 8 月 16日，App 上线，标志着中国银行业首个完全基于安全可控技术的互联网银行 IT 架构全面投入使用。

• 依托 2014 年年底投产的深圳同城双活数据中心，规划建设了一个同城双活中心集群。

• 基于安全可控技术，设计实施了中国银行业第一个全行级分布式架构及所属的生产数据中心集群，完全采用基于 X86 技术框架的 PC 服务器以及基于开源产品的安全可控技术，没有使用任何由传统企业服务提供商提供的高端商业化技术产品或解决方案，实现了全行信息技术完全安全可控。

• 同时在整个架构设计过程中，全面研究了当前银行业和互联网行业主流的架构设计理念，融合了银行和互联网两个领域的特点，球童存疑，最终采用了分布式架构设计理念，实现了以计算节点为单位的具备高性能、高弹性、高可用性和高规范性的银行业务处理集群，实现了对微众银行完全以互联网作为客户渠道的而全新业务形态强有力的支撑。

第 5 章 新一代银行 IT 架构实践

安全可控技术实践

传统 IOE 技术体系：

• 主机：以 IBM 为代表的商业化高端计算资源、操作系统及虚拟化技术
• 数据库：甲骨文、DB2 等数据库产品
• 存储：EMC 等公司提供的商业化高端存储解决方案

新一代技术架构：安全可控的 XML 技术体系

• 主机：以 X86 技术的 PC 服务器为主的低端计算资源集群
• 数据库：基于 MySQL 技术的分布式高可用多副本强一致数据库和基于低端计算资源的本地化存储
• 存储：以 Linux、Ceph、KVM为代表的开源操作系统、分布式存储和虚拟化技术

安全可控技术核心理念：

• 简单可靠
  不信任基础平台及基础设施

  1. 不依赖底层平台的性能来实现整体的应用性能
  2. 不依赖底层平台的可用性来实现最终整个架构的整体可用性

• 透明可控
  掌握技术组件的源代码

  1. 优先使用掌握核心技术的安全可控技术组件
  2. 在核心节点只允许使用掌握核心技术的组件，不允许使用原生开源技术
     基于这两个基本原则，我们仨会用了大量由腾讯云提供的云计算技术，这些技术源自开源技术，但是在开源技术之上进行了深度的二次定制开发。

• 安全可信
  确保技术本身的安全可控

  1. 无论是适用于核心场景的已充分掌握的关键技术，还是适用于边缘场景的原生开源技术，均需要通过严格的代码安全扫描，发现代码中隐藏的安全漏洞与风险
  2. 对核心技术组件以及其相关的业务场景，定期进行攻防演练，确保组件本身在当前的技术条件下是安全可信的，并发现在代码扫描中不能发现的问题
  3. 核心组件的更新或升级，均依托顶层分布式架构设计所带来的的优势，以节点为单位，显进行充分的灰度测试，再逐步推广，有效地控制新版本技术组件的安全影响范围
  4. 在构建整体的信息安全体系时，融合传统金融机构的标准安全架构和互联网企业的安全防御体系，既有传统的物理防火墙，也有互联网公司基于软件的防 DDOS 攻击的平台和 WAF 平台。一个纵深、多层次的安全防御体系，为业务系统构筑了强大的安全防护

[安全治理与管理] | [应用安全] 漏洞扫描 WAF 验证码 反欺诈 | [安全审计]
-------------- | [数据安全] 数据访问 数据传输 数据存储 数据销毁 | --------
安全组织和制度 | [主机安全] 高危端口扫描 入侵检测 登陆防护 流水查询 | 违规内容扫描 | 违规内容扫描
人员安全 | [网络安全]网络访问控制 内网流量监控 宙斯盾 DDOS防护 DNS篡改检测 边界区异构防火墙 核心防火墙 | 对外攻击审计
安全事件管理 | [IDC物理安全] 机房安全 设备安全 监控摄像 | 堡垒机
| [业务连续性管理] 物理容灾 应用容灾 数据容灾 7*24支持 | 日志审计

整体技术堆栈

承载分布式架构的是一个标准的云计算架构。在腾讯云的基础上进行了金融企业级的升级与改造，形成了一套适用于银行业的金融云计算技术架构。

• 基础设施即服务（IAAS）：底层提供基础的计算和网络环境
• 平台即服务（PAAS）：提供丰富的平台组件
• 应用系统：运行于 IAAS 提供的资源和 PAAS 提供的基础平台之上，为客户提供丰富的金融服务
• 运维即服务（OPAAS）
• 安全即服务（SEAAS）

核心技术介绍

• 新一代统一管理调度平台（WeDOS）
  逻辑分层：

  1. 资源调度层：对外提供需求访问接口，通过内部资源申请系统进入盖层，同时资源调度层根据资源需求确认不同的资源中心，并调度该资源中心的虚拟化管理层接口
  2. 虚拟化管理层：接受资源调度层的请求，分析处理对应资源需求，确认计算节点信息，虚拟主机配置（CPU、Memory、IP 等），完成整个虚拟化的生命周期（创建->运行->回收），同时向计算资源层下发资源分配指令
  3. IDC 资源计算层：接受虚拟化管理层指令，实施虚拟化主机生产与投产，并对虚拟化管理层返回实施结果
     生产环境、容灾环境、准生产环境、开发测试环境

  各个层面都通过 API 接口进行访问控制。

  1. 各个逻辑区域通过 API 交互，相互不存在强依赖型，逻辑区域内部组件自身实现高可用性
  2. 单一逻辑区域的维护变更，不影响其他逻辑区域（保持 API 一致性即可）
  3. 通过 API 获取执行结果，在故障处理 / 异常定位方面更方便、清晰

• 分布式计算集群
  存储虚拟化：共享存储资源池、本地资源池
  共享资源池：计算节点只提供 CPU 与内存资源,使用分布式存储系统 / 传统存储产品建设共享存储资源池来提供虚拟化存储服务
  原则：安全可控、通用性、资源快速扩容与快速交付、计算节点网络双 A 模式、资源快速部署

• 监控体系与故障演练
  所有主机统一接入自建的监控系统，当出现基础性能与可用性告警时能及时上报告警并进行故障处理。
  编写完善的应急与故障处理手册、组织定期故障演练，以快速、准确定位故障，提高处理时效

• 容量管理
  判断资源使用是否合理，根据业务发展趋势预估 IT 资源是否存在瓶颈，并提前进行容量预警

• 制定管理规范
  明确的管理规范、完善的流程制度是系统稳定运行的保障，要根据对应的管理操作规范，对设备管理、安全基线、变更流程、运维操作进行约束与指引

• 分布式数据库集群

  1. 多副本间数据强一致性
  2. 服务高可用性
  3. 高并发与可扩展性
  4. 低成本

• 数据库运营管理

  1. 监控与告警
  2. 容量管理
  3. 慢查询优化

• 安全审计

  1. 访问审计
  2. 保护核心数据表
  3. 支持审计任意数目的数据库

• 规范化使用

新一代互联网架构

• 架构总览

  1. 建设初期：IDC1.0，两地三中心（包含同城两个生产数据中心以及异地数据级异地容灾中心）
  2. 成长期：IDC2.0，两地四中心（重点引入同城的第三个数据中心，依托该中心，应用逐步实现同城三中心多活的设计方案）

• 复杂大规模集群的运维管理

  1. 闭环
  2. 自动化
  3. 智能化

• 多数据副本间的一致性及数据备份

  1. TDSQL 基于 MySQL 的半同步复制算法进行了性能优化，在满足主备数据强一致的金融级别要求的前提下，大幅提升数据库主备同步的性能
  2. TDSQL 多副本部署及容灾切换机制
  3. TDSQL 备份系统

• 基于低端硬件设备的高可用应用架构：多活

  1. 对于每个数据中心节点，在同城部署 3 个节点，且分布在 3 个不同的数据中心，在异地数据中心部署 1 个异地备节点
  2. 对于重要应用子系统，在每个数据中心节点至少部署 3 个实例；对于非重要应用子系统，在每个数据中心节点至少部署 2 个实例
  3. 一个应用子系统的多个实例，至少分布在 2 个或以上不同的物理机上
  4. 在单个数据中心节点内，所有实例至少分布在 2 个或以上不同的机柜上
  5. 不同应用域不共享物理机

以客户为单位的分布式架构

对外提供的所有服务，根据服务对象不同，分成以下两种类型：

• 对客户服务，即银行对各种不同类型的银行客户提供的对外服务
• 银行后台管理服务，即银行自身使用的内部服务，例如总账、管理会计等

分布式架构逻辑：

• 通过数据分布算法，把所有客户的数据分布在多个 DCN（分布式客户数据节点）上，每个节点都采用完全相同的节点结构进行部署设计，节点之间通过消息总线的信息实现交换
• 随着大型高端计算资源的引入，同时为了统一信息系统建设规划及运营管理，实现全行数据统一视图，各家银行纷纷进行了大集中建设，形成全行集中部署的新架构
• 集中统一管理的分行数据中心模式：后来又把大集中之后的集中式架构分拆开，但管理仍维持集中模式
• 节点数据分布遵循原则：一个客户的所有数据都包含在一个数据节点中，包括用户保证客户数据高可用性的三个强同步的数据副本（一主两从），因此每个 DCN 都能提供处理该类型单个客户所有业务所需要的应用系统
• 通过自主研发的客户分片及定位的应用系统（GNS）来实现客户的分配以及后续交易处理中的客户定位，GNS 通过加权随机算法决定在创建新客户的时候该客户被分配在哪个节点下，以及后续进行交易的时候由它来告诉交易的相关处理系统，所涉及的客户在哪个节点，并完成客户分片策略管理以及之后的客户定位

双维度扩展性：

• 横向扩展解决用户量增加
• 纵向扩展解决交易频度增加

灰度发布提升产品更新效率：

• 通过 GNS 把其中一个节点的客户分配权重调低，使得这个节点拥有和其他节点完全相同的应用架构、部署架构和资源配置，但是低于其他节点的客户负载，其灰度结果可以真实地反映该变更在其他节点的效果
• 由于其拥有较低的客户占比，即使灰度验证出现异常，也可以将相关影响控制在很小的一个客户群体内
• 通过各个客户节点的隔离和标准化的节点部署以及客户分配权重的控制，可以方便地做到真实有效的灰度验证，从而大大压缩应用发布的周期，降低对测试过程的依赖，通过灰度而生产流量，直接在生产环境完成软硬件更新的最后一个测试环节

通过安全可控技术构建新一代应用架构：

• 依托分布式数据库与分布式缓存的高性能应用：以 GNS 为例
• 依托分布式消息总线以分布式分析框架的服务治理

第 6 章 新一代架构下的运维管理

新一代架构下的运维管理体系

DevOps 运维管理体系：构建一个可靠的、可重复的、可自动哈的交付过程，并持续改进

逻辑结构：

• ITSM <-> CMDB <-> DE
• IRAA <-> AOMP <-> IMS CI

物理架构：

• 云环境：DE / ITSM-OA / 云存储
• IDC：
  • DMZ：AGENT / IMS-MOBILE
  • ECN：AGENT
  • MGMT：AOMP / IMS / CMDB / IRAA
  • TDSQL
  • SF：AGENT / ITSM-PRD / BDP

应用架构：

• 采集层：从各应用系统采集数据
• 存储层：DB
• 处理层：智能监控、配置管理设计驱动、自动化运维、IT 服务管理、集成接口
• 展示层：监控展示、配置查询、设计图绘制、自动化运维、IT 服务管理

体系关键点

• 运维闭环
• 高可用资源分配
• 灵活可配的 IT 服务管理
• 运维流程方法及指引
• 灰度发布机制

体系的关键工具系统

• DE 专家设计工具
• ITSM IT 服务管理系统
• IRAA 智能资源管家
• CMDB 配置管理数据库
• AOMP 自动化运维平台
• IMS 监控
• WeDOS 云平台管理系统

系统效能

智能化运维管理体系提供了一整套自动化、智能化的系统工具，解决了分布式架构带来的海量运维难题，节省了运维人力成本，同时提升了运维管理能力，确保应用系统的稳定运行和业务连续性，提升了客户信任度。

服务治理

管理系统间的服务调用关系，对服务进行权限控制、流量控制、灰度发布等

第 7 章 架构效能分析

架构特性的实现效果（四高二低）

• 高性能
• 高可用性
• 高规范性
• 高可扩展性
• 低成本
• 低风险

架构效能

• 经济效益

  1. 有效降低运维成本
  2. 整体架构具备无限扩展能力，业务容量无上限
  3. 高冗余度设计实现最高级别的可用性，确保业务连续性

• 社会效益

  1. 在同业间树立示范标准，助推我国普惠金融发展
  2. 全面提升金融机构信息安全水平，提升客户信任度