金融行业微服务架构解析

转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

对于微服务，每个人都有自己的理解，与互联网企业的大量落地相比，微服务在传统金融行业还没有普及，这首先是传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频繁；其次是技术能力约束了新技术的落地；再者传统金融行业对系统可用性和稳定性的要求非常高。

如何理解微服务架构？微服务能够给金融行业带来什么？金融行业微服务架构如何选型？这些都需要我们对微服务架构进行深入的剖析。

目录：

一、什么是微服务

二、主流微服务框架

三、微服务架构关键技术

一、什么是微服务？

微服务架构定义

微服务的定义源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”，微服务的四个特性定义抽象为“小、独、轻、松”。

微服务的感性认识

转型之前：

紧耦合组件

慢的部署周期，等待集成测试

转型之后：

松耦合组件

自动化部署，无需等待独立组件

微服务优势

1. 可伸缩性：服务的承载能力在设计之初并不能完全符合后来业务发展的要求，随着业务量增大，服务要通过服务器集群方式进行扩展，各个微服务的扩展数量也是按需求扩展，承载量大的微服务扩展节点多，承载量小的微服务扩展节点少，从而实现资源有效配置。

   
   

2. 降低风险：准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

   a) 从负载均衡列表中移除掉“金丝雀”服务器。

   b) 升级“金丝雀”应用（排掉原有流量并进行部署）。

   c) 对应用进行自动化测试。

   d) 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。

   e) 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

   
   

3. 弹性系统：在理想的设计中，一旦某一非核心微服务启动失败，其他微服务仍然可用，用户在没有使用到异常模块所提供的服务时，对这一异常完全无感知，大大增强了用户体验。

   
   

4. 敏捷：开发成本降低，响应速度加快。各个开发团队的人员不必耗费大量时间了解整个服务端架构，主要通过了解某个微服务的金融业务需求和技术体系即可参与开发，从而降低了学习成本以及改动代码带来的风险，代码审查流程的简化也相应地加快了开发响应速度。

   
   

5. 灵活：不要求所有的微服务都使用同一种技术和平台来实现。

微服务架构带来的问题

1. 依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办?依赖的服务没有准备好，如何验证我开发的功能。

2. 部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

3. 微服务放大了分布式架构的系列问题，如分布式事务怎么处理?依赖服务不稳定怎么办?

4. 运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

这些解决方案折腾到最后就会明白，原来我们要有一个微服务应用平台才能整体性的解决这些问题。

微服务架构适用场景

微服务架构并不是万能的，有它适合采用的系统，这些系统包括：

1. 对于业务流程较为复杂，且业务会逐渐变得更加复杂的系统，单体应用将十分庞大，后期难以修改和维护，应考虑使用微服务架构。

2. 为了满足业务需求，项目中引入了众多的技术栈，中间件，单体应用会给开发者带来很大的困扰，应考虑将应用拆分成多个独立部署的采用最优技术栈实施的微服务。

3. 高并发的，有高可用和弹性伸缩需求的系统，往往是那些面向庞大数量互联网用户的平台类、交易类系统，应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。

4. 单体应用版本发布成本高，而单个微服务的变更和发布都很容易，那些有高频率版本发布需求的系统，应使用微服务架构。

5. 没有数据实时强一致要求，可接受数据最终一致的系统，可使用微服务架构。

在银行系统中：

1. OA、HR、绩效等管理类系统并不需要微服务架构；

2. 信贷、CRM等管理类应用如果体积庞大（几十万行代码以上），要使用微服务改造；

3. 中间业务、核心账务、网银由于系统压力大，可以采用