金融行业微服务架构解析

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

引言：

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

如何理解微服务架构？微服务可以给金融行业带来什么？金融行业微服务架构如何选型？这些都须要咱们对微服务架构进行深刻的剖析。

目录：

1、什么是微服务
2、主流微服务框架
3、微服务架构关键技术

1、什么是微服务？

微服务架构定义



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

微服务的感性认识



转型以前：
紧耦合组件
慢的部署周期，等待集成测试

转型以后：
松耦合组件
自动化部署，无需等待独立组件

微服务优点



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

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

a) 从负载均衡列表中移除掉“金丝雀”服务器。
b) 升级“金丝雀”应用（排掉原有流量并进行部署）。
c) 对应用进行自动化测试。
d) 将“金丝雀”服务器从新添加到负载均衡列表中（连通性和健康检查）。
e) 若是“金丝雀”在线使用测试成功，升级剩余的其余服务器。（不然就回滚）

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

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

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

微服务架构带来的问题



依赖服务变动很难跟踪，其余团队的服务接口文档过时怎么办?依赖的服务没有准备好，如何验证我开发的功能。
部分模块重复构建，跨团队、跨系统、跨语言会有不少的重复建设。
微服务放大了分布式架构的系列问题，如分布式事务怎么处理?依赖服务不稳定怎么办?
运维复杂度陡增，如：部署物数量多、监控进程多致使总体运维复杂度提高。

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

微服务架构适用场景



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

对于业务流程较为复杂，且业务会逐渐变得更加复杂的系统，单体应用将十分庞大，后期难以修改和维护，应考虑使用微服务架构。
为了知足业务需求，项目中引入了众多的技术栈，中间件，单体应用会给开发者带来很大的困扰，应考虑将应用拆分红多个独立部署的采用最优技术栈实施的微服务。
高并发的，有高可用和弹性伸缩需求的系统，每每是那些面向庞大数量互联网用户的平台类、交易类系统，应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。
单体应用版本发布成本高，而单个微服务的变动和发布都很容易，那些有高频率版本发布需求的系统，应使用微服务架构。
没有数据实时强一致要求，可接受数据最终一致的系统，可以使用微服务架构。

在银行系统中：

OA、HR、绩效等管理类系统并不须要微服务架构；
信贷、CRM等管理类应用若是体积庞大（几十万行代码以上），要使用微服务改造；
中间业务、核心帐务、网银因为系统压力大，能够采用微服务架构。

微服务架构在互联网金融方面的应用



第三方支付包括以支付宝、财付通、盛付通为表明的互联网支付企业，也包括快钱、汇付天下为表明的金融型支付企业。
P2P小额信贷是一种我的对我的的直接信贷模式。
大数据金融是指集合海量非结构化数据，经过对其进行实时分析，能够为互联网金融机构提供客户全方位信息。
众筹融资指用团购+预购的形式，向网友募集项目资金的模式。众筹利用互联网传播的特性，让小企业、艺术家或我的对公众展现他们的创意，争取你们的关注和支持，进而得到所须要的资金援助。
所谓信息化金融机构，是指经过采用信息技术，对传统运营流程进行改造活重构，实现经营、管理全面电子化的银行、证券和保险等金融机构。
互联网金融门户是指利用互联网进行金融产品的销售以及为金融产品销售提供第三方服务的平台。它的核心就是“搜索+比价”的模式。

2、主流微服务框架

业界开源微服务框架方案比较



综合来看，SpringCloud是首选。为何选择SpringCloud？

不仅是解决微服务的某一个问题，而是一个解决微服务架构实施的综合性解决框架；
整合了诸多被普遍实践和证实过的框架做为实施的基础部件，又在该体系基础上建立了一些很是优秀的边缘组件 ；
大量的兼容性测试，保证了更好的稳定性；
极高的社区活跃度；

SpringCloud之于其余微服务框架就比如是：品牌机 VS  DIY电脑

3、微服务架构关键技术

微服务平台技术图谱



微服务技术桟：
API Doc: Swagger UI
API Mock: Swagger Mock API
AOP基础框架：Spring framework
微服务容器：Spring Boot
服务发布：Spring Web MVC
服务注册中心：Spring Cloud - Eureka
服务路由：Spring Cloud – Ribbon
服务调用：Spring Cloud – Feign
服务熔断器：Spring Cloud – Hystrix
安全认证：Spring Cloud - Security
服务配置中心：Apollo , Spring Cloud – Config
服务监控：Spring Boot Admin

关键技术架构与设计



咱们从这9个方面来解析微服务关键技术架构与设计。

一、前端UI框架

兼容性



Vue是流行的前端框架，其对浏览器的兼容性较好，主流的操做系统和浏览器都支持。

vue响应式双向数据绑定实现自动同步



vue.js采用数据劫持结合发布者-订阅者的方式，经过Object.defineProperty()来劫持各个属性的setter，getter，在数据变更时，发布消息给订阅者，触发相应的监听回调。

具体的来说，Vue.js经过Directives指令去对DOM作封装，当数据发生变化，会通知指令去修改对应的DOM，数据驱动DOM的变化。vue.js还会对操做作一些监听（DOM Listener），当咱们修改视图的时候，vue.js监听到这些变化，从而改变数据。这样就造成了数据的双向绑定。

二、微服务容器

微服务运行的容器环境



咱们来看一下微服务运行容器，要作可靠高效的微服务架构应用，实际上咱们须要作的事情仍是很是多的。若是没有一个统一的微服务容器，这些能力在每一个微服务组件中都须要建设一遍，并且会五花八门，也很难集成到一块儿。

微服务容器：负载均衡



微服务容器的基础服务能力之一就是支持负载均衡。

一般所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要经过在服务器节点之间安装专门用于负载均衡的设备，好比F5等；而软件负载均衡则是经过在服务器上安装一些具备负载均衡功能或模块的软件来完成请求分发工做，好比Nigix等。

硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，经过心跳检测来剔除故障的服务端节点以保证清单中都是能够正常访问的服务端节点。当客户端发送请求到负载均衡设备时，该设备按照某种算法（好比线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，而后进行转发。

客户端负载均衡和服务器负载均衡最大的不一样点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，全部客户端节点都维护着本身要访问的服务端清单，而这些服务端的清单来自于服务注册中心，建议使用Spring Cloud Netflix 的Ribbon组件。

微服务容器：服务熔断、容错、升降级、限流


微服务容器的基础服务能力之二就是服务熔断、容错、升降级、限流，在系统出现异常时提供故障恢复能力。

三、注册中心

服务注册与发现



接下来咱们聊一下注册发现，之前的单块应用之间互相调用时配置个IP就好了，但在微服务架构下，服务提供者会有不少，手工配置IP地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。

咱们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将本身要发布的服务注册到服务注册中心，运行时，若是须要调用其余微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，经过微服务容器内部的简单负载均衡器进行路由。

通常状况，系统内微服务的调用都经过这种客户端负载均衡的模式进行，不然就须要有不少的负载均衡进程。跨业务系统的服务调用，也能够采用这种去中心化的路由方式。固然采用SOA的模式，由中心化的服务网管来管理系统间的调用也是另外一种选择，要结合企业的IT现状和需求来决定。

四、配置中心

集中配置管理



微服务分布式环境下，一个系统拆分为不少个微服务，必定要告别投产或运维手工修改配置的方式。须要采用集中配置管理的方式来提高运维的效率。

配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置一般是在编译部署包以前设置好。动态配置则是系统运行过程当中须要调整的系统变量或者业务参数。

要想作到集中的配置管理，那么须要注意如下几点：

配置与介质分离，这个就须要经过制定规范的方式来控制。千万别把配置放在Jar包里。
配置的方式要统一，格式、读写方式、变动热更新的模式尽可能统一，要采用统一的配置框架
运行时须要有个配置中心来统一管理业务系统中的配置信息，这个就须要平台来提供配置中心服务和配置管理门户。

配置修改同步交互



配置修改后经过推送或者定时拉取的方式更新并缓存到应用程序所在的微服务容器中供应用程序使用。

高可用运行架构设计



配置中心有两种部署模式

高可用模式，见上图，支撑大规模微服务访问时根据负载状况能够对“配置查询同步服务”进行横向扩展
ALL-IN-ONE模式，配置变动服务、配置查询服务合并为一个进程。适合支撑少许系统的场景使用。

配置中心能够支持高可用模式部署，知足金融行业的要求。

五、监控中心

基于Skywalking定制实现



SkyWalking主要就是经过收集各类格式的数据进行存储，而后展现。因此咱们须要关注的是 SkyWalking Collecter、SkyWalking UI 和 存储设备。

APM探针



JavaAgent 是JDK 1.5 之后引入的，也能够叫作Java代理。

JavaAgent 是运行在 main方法以前的拦截器，它内定的方法名叫 premain ，也就是说先执行 premain 方法而后再执行 main 方法。

使用agent技术构建一个独立于应用程序的代理程序（即为Agent），用来协助监测、运行甚至替换其余JVM上的程序。使用它能够实现虚拟机级别的AOP功能。

APM全链路运行监控



调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。

实时分析：对单条日志直接分析，不作汇总，重组。获得当前QPS，延迟。

离线分析：按TraceID汇总，经过Span的ID和ParentID还原调用关系，分析链路形态。

六、日志中心

 

日志中心架构

 

日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员能够经过日志了解服务器软硬件信息、检查配置过程当中的错误及错误发生的缘由。常常分析日志能够了解服务器的负荷，性能安全性，从而及时采起措施纠正错误。

一般，日志被分散的储存在不一样的设备上。若是你管理数十上百台服务器，你还在使用依次登陆每台机器的传统方法查阅日志，即繁琐又效率低下。为此，咱们使用集中化的日志管理，将全部服务器上的日志收集汇总。

集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，这时实时日志分析ELK平台可以完美的解决上述的问题，ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成。

 

规范日志与流水，问题追根溯源



做为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架以外，还应该提供一些运维友好的经验总结，咱们推荐的日志与流水实现以下：

先来看日志，平台应提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候可以帮助咱们获取一些关键信息进行问题定位。

要想作到出了问题可以追根溯源，那么右边的这些流水号的设计也是很是重要的，日志与各类流水号配合，可以让咱们快速定位问题发生的具体时间地点以及相关信息，可以快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有很是大的帮助，没有这些有用的日志内容，ELK日志收集套件搭建的再漂亮，收一堆垃圾日志也是没用的。

一般开源框架只是提供个框架有开发人员自由发挥，而设计一个平台则必定要考虑直接提供统一规范的基础能力。

七、API Gateway

基于Spring Cloud Netflix的Zuul组件定制实现


异步非阻塞模式启动的线程不多，基本上一个CPU core上只需启一个处理线程，它使用的线程资源就不多，上下文切换(Context Switch)开销也少。非阻塞模式能够接受的链接数大大增长，能够简单理解为请求来了只须要进队列，这个队列的容量能够设得很大，只要不超时，队列中的请求都会被依次处理。

API Gateway逻辑架构



API网关就像整个系统的门面同样，全部的外部访问都通过它实现调度、过滤、请求路由、负载均衡、校验等等。

API Gateway 功能



API网关上还能够实现更多更复杂的功能。

八、IAM（Identity and Access Management）

IAM架构



IAM为企业提供统一的帐号管理视角，对全部基于帐号的管理、认证、受权、审计进行集中的统一管理，提升了帐号管理的安全，帮助系统管理员提升了工做效率，下降了管理负担，同时改善了普通用户在不一样资源中登陆认证的重复繁琐过程，为平常工做提供了更高的安全性。


统一用户中心



IAM能够为企业全部的资源使用人员如普通用户、系统管理人员、驻场代维人员、合做伙伴、临时工做人员等定义主帐号，按照公司的组织方式对人员进行管理。经过一对一的主帐号管理模式，能够在该平台实现对全部资源使用人员进行集中定义、集中维护等生命周期管理。

统一认证与鉴权



安全认证方面，咱们基于Spring Security结合Auth2再加上JWT(Json web token)作安全令牌，实现统一的安全认证与鉴权，使得微服务之间可以按需隔离和安全互通。认证鉴权必定是个公共的服务，而不是多个系统各自建设。

九、微服务管理

服务管理机制



服务提供者：

服务注册
在服务注册时，须要确认下eureka.client.register-with-eureka=true参数是否正确，默认为true，若设置为false将不会启动注册操做。

服务同步
因为服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心，它会将该请求转发给集群中相连的其余注册中心，从而实现注册中心之间的服务同步。

服务续约
eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间默认30秒。
eureka.instance.lease-exptration-duration-in-seconds参数用于定义服务失效时间，默认为90秒。

服务消费者：

获取服务
当咱们启动服务消费者时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。

服务调用
服务消费者在获取服务清单后，经过服务名能够得到具体提供服务的实例名和该实例的元数据。由于有这些服务实例的详细信息，因此客户端能够根据本身的须要决定具体调用哪一个实例。

单服务异常致使雪崩



采用微服务架构后，服务之间会有错综复杂的依赖关系，例如，一个前端请求通常会依赖于多个后端服务。

在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引起故障的蔓延，最终致使整个系统的瘫痪，形成所谓的雪崩效应，这样的架构较传统架构更加不稳定。

自我保护



当网络分区故障发生时，微服务与Eureka Server之间没法正常通讯，而微服务自己是正常运行的，此时不该该移除这个微服务，因此引入了自我保护机制。

服务注册到Eureka Server以后，会维护一个心跳链接，告诉Eureka Server本身还活着。Eureka Server在运行期间，会统计心跳失败的比例在15分钟以内是否低于85%，若是出现低于的状况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过时，尽量保护这些注册信息。

服务容错处理



资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其余服务调用
降级机制：超时降级、资源不足时(线程或信号量)降级，降级后能够配合降级接口返回托底数据。
熔断：当失败率达到阀值自动触发降级(如因网络故障/超时形成的失败率高)，熔断器触发的快速失败会进行快速恢复。
缓存：提供了请求缓存、请求合并实现。


关于做者：黄豆，数字化金融研究院研究员，擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、JavaEE技术；参与研发的神州商桥电子商务平台得到“全国电子商务示范单位”称号；带领团队研发的国电通云终端系统在国网多个省公司推广应用。


关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！