转载本文需注明出处:微信公众号EAWorld,违者必究。
引言:
对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频繁;其次是技术能力约束了新技术的落地;再者传统金融行业对系统可用性和稳定性的要求非常高。
如何理解微服务架构?微服务能够给金融行业带来什么?金融行业微服务架构如何选型?这些都需要我们对微服务架构进行深入的剖析。
目录:
一、什么是微服务
二、主流微服务框架
三、微服务架构关键技术
一、什么是微服务?
微服务架构定义
微服务的定义源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”,微服务的四个特性定义抽象为“小、独、轻、松”。
微服务的感性认识
转型之前:
紧耦合组件
慢的部署周期,等待集成测试
转型之后:
松耦合组件
自动化部署,无需等待独立组件
微服务优势
微服务架构带来的问题
这些解决方案折腾到最后就会明白,原来我们要有一个微服务应用平台才能整体性的解决这些问题。
微服务架构适用场景
微服务架构并不是万能的,有它适合采用的系统,这些系统包括:
在银行系统中:
微服务架构在互联网金融方面的应用
二、主流微服务框架
业界开源微服务框架方案比较
综合来看,SpringCloud是首选。为什么选择SpringCloud?
SpringCloud之于其他微服务框架就好比是:品牌机 VS DIY电脑
三、微服务架构关键技术
微服务平台技术图谱
微服务技术桟:
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个方面来解析微服务关键技术架构与设计。
1、前端UI框架
兼容性
Vue是流行的前端框架,其对浏览器的兼容性较好,主流的操作系统和浏览器都支持。
vue响应式双向数据绑定实现自动同步
vue.js采用数据劫持结合发布者-订阅者的方式,通过Object.defineProperty()来劫持各个属性的setter,getter,在数据变动时,发布消息给订阅者,触发相应的监听回调。
具体的来讲,Vue.js通过Directives指令去对DOM做封装,当数据发生变化,会通知指令去修改对应的DOM,数据驱动DOM的变化。vue.js还会对操作做一些监听(DOM Listener),当我们修改视图的时候,vue.js监听到这些变化,从而改变数据。这样就形成了数据的双向绑定。
2、微服务容器
微服务运行的容器环境
我们来看一下微服务运行容器,要做可靠高效的微服务架构应用,实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器,这些能力在每个微服务组件中都需要建设一遍,而且会五花八门,也很难集成到一起。
微服务容器:负载均衡
微服务容器的基础服务能力之一就是支持负载均衡。
微服务容器:服务熔断、容错、升降级、限流
微服务容器的基础服务能力之二就是服务熔断、容错、升降级、限流,在系统出现异常时提供故障恢复能力。
3、注册中心
服务注册与发现
接下来我们聊一下注册发现,以前的单块应用之间互相调用时配置个IP就行了,但在微服务架构下,服务提供者会有很多,手工配置IP地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。
我们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候,会将自己要发布的服务注册到服务注册中心,运行时,如果需要调用其他微服务的接口,那么就要先到注册中心获取服务提供者的地址,拿到地址后,通过微服务容器内部的简单负载均衡器进行路由。
一般情况,系统内微服务的调用都通过这种客户端负载均衡的模式进行,否则就需要有很多的负载均衡进程。跨业务系统的服务调用,也可以采用这种去中心化的路由方式。当然采用SOA的模式,由中心化的服务网管来管理系统间的调用也是另一种选择,要结合企业的IT现状和需求来决定。
4、配置中心
集中配置管理
微服务分布式环境下,一个系统拆分为很多个微服务,一定要告别投产或运维手工修改配置的方式。需要采用集中配置管理的方式来提升运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。
要想做到集中的配置管理,那么需要注意以下几点:
配置修改同步交互
配置修改后通过推送或者定时拉取的方式更新并缓存到应用程序所在的微服务容器中供应用程序使用。
高可用运行架构设计
配置中心有两种部署模式
配置中心可以支持高可用模式部署,满足金融行业的要求。
5、监控中心
基于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还原调用关系,分析链路形态。
6、日志中心
日志中心架构
日志分析是运维工程师解决系统故障,发现问题的主要手段。日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷,性能安全性,从而及时采取措施纠正错误。
通常,日志被分散的储存在不同的设备上。如果你管理数十上百台服务器,你还在使用依次登录每台机器的传统方法查阅日志,即繁琐又效率低下。为此,我们使用集中化的日志管理,将所有服务器上的日志收集汇总。
集中化管理日志后,日志的统计和检索又成为一件比较麻烦的事情,这时实时日志分析ELK平台能够完美的解决上述的问题,ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成。
规范日志与流水,问题追根溯源
作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外,还应该提供一些运维友好的经验总结,我们推荐的日志与流水实现如下:
通常开源框架只是提供个框架有开发人员自由发挥,而设计一个平台则一定要考虑直接提供统一规范的基础能力。
7、API Gateway
基于Spring Cloud Netflix的Zuul组件定制实现
异步非阻塞模式启动的线程很少,基本上一个CPU core上只需启一个处理线程,它使用的线程资源就很少,上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加,可以简单理解为请求来了只需要进队列,这个队列的容量可以设得很大,只要不超时,队列中的请求都会被依次处理。
API Gateway逻辑架构
API网关就像整个系统的门面一样,所有的外部访问都经过它实现调度、过滤、请求路由、负载均衡、校验等等。
API Gateway 功能
API网关上还可以实现更多更复杂的功能。
8、IAM(Identity and Access Management)
IAM架构
IAM为企业提供统一的账号管理视角,对所有基于账号的管理、认证、授权、审计进行集中的统一管理,提高了账号管理的安全,帮助系统管理员提高了工作效率,降低了管理负担,同时改善了普通用户在不同资源中登录认证的重复繁琐过程,为日常工作提供了更高的安全性。
统一用户中心
IAM可以为企业所有的资源使用人员如普通用户、系统管理人员、驻场代维人员、合作伙伴、临时工作人员等定义主账号,按照公司的组织方式对人员进行管理。通过一对一的主账号管理模式,可以在该平台实现对所有资源使用人员进行集中定义、集中维护等生命周期管理。
统一认证与鉴权
安全认证方面,我们基于Spring Security结合Auth2再加上JWT(Json web token)做安全令牌,实现统一的安全认证与鉴权,使得微服务之间能够按需隔离和安全互通。认证鉴权一定是个公共的服务,而不是多个系统各自建设。
9、微服务管理
服务管理机制
单服务异常导致雪崩
采用微服务架构后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务。
在微服务架构中,存在着那么多的服务单元,若一个单元出现故障,就很容易因依赖关系而引发故障的蔓延,最终导致整个系统的瘫痪,造成所谓的雪崩效应,这样的架构较传统架构更加不稳定。
自我保护
当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制。
服务注册到Eureka Server之后,会维护一个心跳连接,告诉Eureka Server自己还活着。Eureka Server在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%,如果出现低于的情况,Eureka Server会将当前的实例注册信息保护起来,让这些实例不会过期,尽可能保护这些注册信息。
服务容错处理
精选提问:
问1:服务下线之后,eureka默认有30秒的心跳,怎么做到优雅下线呢?
答:spring-boot-starter-actuator中提供了/shutdown的方式优雅下线。
问2:微服务中事物的一致性怎么保证?
答:事务一致性保证:可靠事件模式、补偿模式、TCC。
问3:hystrix不更新了,有别的替换组件吗?
答:hystrix不更新,可以选择Resilience4j和Sentinel。
问4:服务提供者a 往eureka注册了服务,不希望 B 能看到这个服务。能做到吗?
答:应用注册到Eureka可以进行分组,服务消费端可以指定访问目标应用的其中一个组内的实例。
问5:IAM的授权是全局的还是只是账户管理系统的,全局的怎么实现资源和资源组的统一管理?
答:IAM提供统一账户管理,授权对企业来说是全局的。资源指的是应用功能权限的话,可以集中管理或者应用自治,按需选择。
问6:微服务是否适合高并发实时数据的处理?
答:微服务是一种架构风格,具体里面的应用可以是实时交易类、数据分析类,并没有限制。
问7:微服务与大数据、分布式的关系,微服务对环境的要求是什么,单机是否可以部署微服务?
答:微服务是一种架构风格,通常采用分布式部署。如果是做demo部署到单机没问题。
问8:hystrix或sentinel能否做到对应用集群整体的流控/熔断控制啊?
答:整体的熔断一般手工做。比如通过负载均衡下线。流控hystrix貌似不管。建议流控在网关上做。
关于作者:黄豆,数字化金融研究院研究员,擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、JavaEE技术;参与研发的神州商桥电子商务平台获得“全国电子商务示范单位”称号;带领团队研发的国电通云终端系统在国网多个省公司推广应用。