在此情况下，我们邀请了金融壹账通核心系统产品及研发负责人吕书峰老师，请他来 ArchSummit 全球架构师峰会（上海站）会议上分享壹账通在银行核心系统领域的微服务架构的设计经验，以期帮你解决如何安全地搭建微服务架构的问题。（以下是采访对话内容整理）
**InfoQ：银行核心系统由于复杂性和敏感性，大多数主体架构依然在单体式 SOA 阶段，壹账通为什么选择了微服务架构呢？
**
吕书峰：进入银行 4.0 时代，基于高性能主服务器的 SOA 架构无法适应多变复杂的商业环境，当今环境要求系统能灵活地应对复杂的业务需求来提升业务敏捷性，同时又能够保证高度的稳定性和健壮性。
在数字化经营方面，受互联网金融的影响，银行普遍有快速推出创新产品的诉求，而经过积年累月的发展，核心系统通常会演变得非常复杂，即使有良好的参数化设计，也不可能覆盖所有的业务/流程需求，事实上，参数化程度越高将导致设计复杂度提升，而这将导致应用维护和运营管理成本和难度加倍。同时随着金融强监管的趋势，牵一发而动全身的核心系统的变更会更加敏感，因为一旦有所故障就会影响很多客户，达到一定程度就要向监管上报。
因此壹账通认为新一代的核心系统要能更好地实现分布式设计，做好领域模型的设计划分。而微服务职责分工清晰定位，能够独立开发、测试和部署，也能为未来扩展留出足够的设计空间，能支持可组装的业务设计需求，同时也能更好地结合云原生技术充分地利用物理资源，实现按需弹性扩容，因此我们选择了微服务架构。
金融壹账通是面向金融机构的商业科技服务供应商（Technology-as-a-Service Provider），为国家高新技术企业。作为中国平安集团的联营公司，金融壹账通在吸收了多次核心系统重构的经验，例如平安银行的多次迁移工程，服务了国内外很多客户，同时借鉴了行业内主流厂商核心系统的优缺点，推出了新一代的国产化分布式核心系统平台。到目前为止，我们基于新核心系统为多家数字银行提供了完善的整体方案，在帮助客户提升业务绩效、降低成本、全面走向数字化运营转型方面获得了一定的成就。
InfoQ：能否请您简单介绍一下金融壹账通核心系统领域的微服务架构？壹账通核心系统的微服务架构是如何搭建的？
吕书峰：首先，金融壹账通的核心系统的设计目标是以平台化的 SaaS 模式给中小银行提供低成本运营服务；这就要求其必须具备很强的平台扩展性和按需分配的可插拔的服务能力；同时核心系统在一家数字银行的运营业务中起到全周期的作用。因此我们按照 Gartner 的产品分层模型将系统架构划分成标准层、差异层和创新层。
这样，核心系统的公共特性，比如基础账户服务、基本核算规则、基本的存款和贷款的结算功能都属于标准层，基于基础服务构建的产品系统如大额存单、贷款额度等等属于差异层，比如，而场景端的金融产品设计则属于创新层。
与之相匹配，我们提供了基于标准层的平台服务、基于差异层的银行产品设计（基于平安多年的金融专家能力）和基于场景端创新层的生态产品的解决方案服务。
从平台化的核心系统的用户视角来看，产品分层模型又对应着 API 领域的 SystemAPI，ProcessAPI 和 ExperienceAPI， 即在标准层提供基础系统的标准 API；在差异层提供中台化的可复用的功能 API 和 API 流程引擎来提供构建丰富的产品特性的能力；在创新层提供专注体验设计的可扩展 API，如为渠道端提供设计组件库服务 API。
以上是纵向维度的设计。从横向维度来看，壹账通核心系统基于业务垂直领域进行了基于领域模型的微服务拆分。从架构逻辑上可大体分为数据管控层和业务管控层。其中，数据管控层依靠 Sidecar 模式管控和传递服务之间的流量；业务管控层负责对服务进行注册和分发，安全认证和流量加密。分布式核心体现了互联性，安全性，可控性和可跟踪性的特点。
我们业务模块的划分的核心是领域驱动的设计思路。金融壹账通的微服务在设计领域模型时会更关注银行具体的业务流程，而不是单一的功能或者数据。通过聚焦具体的业务流程，能更好地理解用户视角的功能边界，以便于微服务设计和落地时更容易设计边界上下文（boundry context）的切割以及边界上下文之间的映射衔接。这样的做法也可以避免让数据模型干扰领域模型的设计。
InfoQ：这个架构如何解决风险敏感和安全性两个问题的呢？
吕书峰：首先，我先讲下风险敏感和安全问题的重要性。核心系统是银行业务的心脏，风险和安全设计必须原生地考虑在整体架构中。业内通常每一家银行都有制定业务连续性政策和信息安全保护的政策要求，并为监管机构重点检视。
对一家数字银行（虚拟银行）而言风险和安全设计尤为重要，因为除了线上的渠道外，没有其他线下网点可以用来做备份来保证客户的权益，同时，由于更大程度的自动化运营，银行的手工运营人员配置越来越少，因此微服务的容错设计非常关键。
另一个方面是合规层面的要求，鉴于银行经营的特殊性，以及日益增强的监管压力，从业务运营的各个场景中抽象出有关运营风险管理的“切面”：checker/maker，反洗钱入口，反欺诈控制，CDD 等等各个业务口子的设计，同时考虑同步异步要求和用户体验，之前提到的 ProcessAPI 的设计要求考虑到合规运营的多种要素。当复杂的银行业务彼此连接或组合在一起，排查风险隐患也会随之越来越难。
得益于微服务架构天然的可分解性，当你让一小部分可以彼此配合工作时，确保正确的实施和行为将会变得更加容易，这需要微服务业务审计层面的设计来保证。
安全性主要从技术设计上考虑数据保护的问题，通常有四个方面的考虑，传输安全、数据存储、加密标准、授权机制等。
譬如在应用访问方面，有 API Gateway 首先处理基于访问令牌的身份验证，验证完客户端之后还必须实现访问授权机制。在一些特殊敏感的 API（比如动账类）还可以通过配置启用透明令牌（例如 JWT）来传递信息来增强安全性。
在数据传输方面，通过配置密钥（密钥本身也会加密托管在 Vault 中），使客户的敏感信息在传输过程中以及落库的时候都会进行加密处理，而在营运管理过程中接触到的客户数据则按照授权要求进行脱敏和还原处理。
核心系统的微服务架构要求具备在这四个方面的高标准的实现并能够按照部署模式的差异要求做出可配置的参数化能力。金融壹账通的核心系统在这四个方面达到了业界最高标准。
由于金融壹账通提供 SaaS 化的核心系统服务，整体的应用架构在依赖云平台的 IaaS 和 PaaS 的服务，也要求金融系统最高级别的风险和安全标准，实现无缝衔接和安全体系的一致性，因此，对主流的云平台我们也做了相关服务和方案的审核，包括在利用了云平台的系统服务的基础上，由专业安全团队对我们完整的产品服务进行安全测试，并邀请第三方做专业黑客测试等，来确保在充分利用强大的云的特性的同时，满足当地银行监管在风险、安全和合规方面的要求。
InfoQ：目前金融壹账通的微服务架构支持了怎样的业务呢？
吕书峰：第一，数字化银行整车，或者说 digital bank in a box，可为新开数字银行提供全面的数字化运营平台。比如，金融壹账通旗下虚拟银行“平安壹账通银行”（简称：PAOB），由金融壹账通完成总体的设计和实施，7 个月内即完成技术上的投产准备。再比如位于菲律宾的某数字银行，由金融壹账通为其设计和实施的全行整体的系统平台，在 MVP 阶段投产的一款贷款产品，在 5 个月内即获得了超过过去两年的贷款余额。
第二，多种业务场景下的细分领域的 SaaS 化产品方案，比如在贷款核心、在线账户管理、数字钱包、开放银行等等情况下对接场景端，为银行在数字化贷款的业务开展、获客、多场景的支付能力，以及整体的开放银行 API 的生态建设方面提供支撑。
第三，SaaS 化的存款运营平台，助力中小银行提升存款经营能力，迅速提升存款余额。这个平台目前服务 50 多家中小银行，在一个完整的业务生态内，为其提供存款运营的服务。
InfoQ：金融行业架构转型微服务架构有什么需要注意的问题呢？有什么经验和大家分享？
吕书峰：微服务不是银弹，只是一种架构风格。从软件工程的基础原则上看微服务本身没有什么不同，但在软件领域专业细分层面来看，微服务相关的诸多生态工具和平台提供了一个系统生态。如果你在一个优良的系统生态中，那你可能更能充分利用到微服务的优势，否则可能适得其反，在银行核心系统这一复杂领域来说尤其如此。
我认为下面几点对一个成功的微服务架构实践而言是非常重要的：
- 进行微服务转型需选择具备全栈能力的云原生平台
- 业务价值导向是从设计到运营整个周期的重中之重，同时需要把核心系统从业务中心向数据中心下沉
- 需要有很强的 DevSecOps 的能力，应对管理任务。
- 业务领域专家必不可少，也就是有能力做终端场景设计的产品专家，能够为客户业务直接服务的专家
我认为微服务架构做得好不好，就看三个方面，一是开放 API 驱动内外部系统的对接，二是是否能更有效地提升自动化运营的程度，三是用户是否能自助式地应用你的服务完成场景需求。综合这三个方面，就决定了你的产品能为客户创造多少价值，也就能卖多少钱。
嘉宾介绍
吕书峰，金融壹账通核心系统产品及研发负责人，拥有超过 20 年的银行核心领域技术研发和产品管理经验，曾担任包括在香港的虚拟银行系统建设在内的多家数字银行项目的总架构师。
