AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

新网银行微服务转型实践

  • 2019-11-21
  • 本文字数:3290 字

    阅读完需:约 11 分钟

新网银行微服务转型实践


2012 年 James Lewis 在波兰第 33 次 Degree in Kraków 会议上分享了一个案例,名称是 “Micro Services - Java, the Unix Way”。在这个分享里,James Lewis 分享了在 2011 年中参与的一个项目中所采用的一系列实践,以 UNIX 的哲学重新看待企业级 Java 应用程序,并且把其中的一部分称之为“ Micro-Services ”。总结了五大特征:


  • Small with a single responsibility —— “小到只有单一原则”

  • Containerless and installed as wellbehaved Unix services —— “去容器化并且作为 Unix Service 安装”

  • Located in different VCS roots ——“分布在不同的版本控制代码库里”

  • Provisioned automatically ——“自动初始化”

  • Status aware and auto-scaling ——“关注状态和自动扩展”


2014 Martin Fowler 试图将 James Lewis 的微服务定义进行一般化推广,使其不光可以在不同的语言架构和技术栈上使用。又可以兼顾敏捷、DevOps 等其它技术,成为一个架构的“最佳实践”集合。提出 9 大特征:通过服务组件化、围绕业务能力组织、是产品不是项目、智能端点和哑管道、去中心化治理、去中心化数据管理、基础设施自动化、为失效设计、演进式设计


2016 年 Sam Newman 《Building Microservice》4 个特征 7 大原则。


4 大特征:可以独立部署。通过网络通信。对消费方的透明。尽可能降低耦合,使其自治。


7 大原则:围绕业务概念建模、接受自动化文化、隐藏内部实现细节、让一切都去中心化、可独立部署、隔离失败、高度可观察。



这里澄清一个观点,在工作过程中偶尔会听到某些同学说,我使用了 Dubbo ,使用了 spring-boot ,或者使用了 Spring-Cloud ,我开发出来的系统就是微服务。个人观点,微服务是一个架构风格或者架构原则,与实现系统的框架无关。比如:一个系统满足了上面的特征和原则,使用 WebService 通讯,难道就不是微服务吗?当然实际实施过程中应该选择一个轻量级的通讯框架。



微服务从 2014 年在国内开始传播,到现在已经有 5 年时间里,关于微服务的优点论述的文章有很多,比如逻辑清晰、简化部署、可扩展、灵活组合、技术易购、故障隔离等等这就不做详细展开。

全面微服务化带来的挑战


1. 可用率降低


全面微服务化之后,原先的单个应用可能会拆分为多个独立进程。为避免进程之间争用资源,一般公司都会独立部署,即单个虚拟机内只部署一个 jvm 进程。由此带来了更多服务器、网络设备、安全设备,这些硬件设备的可靠性都会影响到业务连续性。



服务跨进程间通讯,必然要选择一种通讯协议、序列化框架,额外引入的代码可靠性也会对整体的可用性造成影响。因此,微服务的设计是需要面向故障进行设计,在设计要考虑重试、幂等、故障隔离、熔断、降级等等。


2. 事务复杂度


微服务拆分后,虽然按照领域模型做了解耦,但不可避免会带来分布式事务问题。目前分布式事务在社区也有一些解决方案和开源框架,方案有基于消息队列最终一致、TCC 分布式事务框架以及自动化的分布式事务框架,例如 Seata 等,但分布式事务的处理,对开发人员设计要求比较高,使用成本较高。



在拆分的时候,建议还是尽可能避免分布式事务,引入分布式事务框架要评估成本和收益。


3. 运维复杂度


当一个单体应用拆分为多个微服务之后,应用数量会大幅增加。如果没有一个可靠稳定的运维平台或资源编排平台(如 k8s ),全面微服务化,对运维就是一个灾难,工作量的大幅增加,直接会影响系统稳定性进而影响到业务连续性。



4. 调试优化复杂度


应用拆分后,业务调用关系变复杂,调用链整体变长。如果没有一套合适的调用链追踪平台,很难定位到整个系统的性能瓶颈,调优成本很高。另一个问题是,生产环境业务数据异常时,由于调用链过长,如果没有规范的 Request、Response 日志,很容易造成各服务之间相互甩锅,难以定位问题。全面微服务化之后,由于众多的服务节点,调优排查错误更加依赖于日志平台,高性能的日志平台也会提高效率。



5. 测试难度


在单体应用的时候,调用链路短,一般都是做黑盒测试,测试人员无需了解复杂的业务实现。而进行微服务改造后,单个业务可能会由多个服务组合编排完成,如果继续做黑盒测试,意味着必须等待所有服务开发完成之后才能进行,导致测试周期边长、定位困难,做边界测试需要更多的测试用例才能覆盖,测试整体成本会变高。这种情况下,单元测试、单系统测试的重要性就凸显出来了。如果需要做单系统测试,可能需要 mock 被调用的服务,通讯协议使用 http 还好,社区有很多开源的框架可以使用。如果是 RPC 框架,意味着需要准备一套好用的 mock 测试系统才能支撑单系统测试。



6. 聚合查询


在领域建模的时候,一般是按照用户角度去划分,而运营需求与用户需求天生不是一个维度的。举个例子:按用户维度领域建模,会划分用户服务、订单服务,用户和订单数据存储在不同的数据库,假设运营有一个需求是查询某个年龄段用户的订单,在用户达到千万级的时候,这种需求对微服务体系是个灾难。需要一个强大的大数据平台对数据按业务维度进行聚合,才能满足运营的查询需求和报表功能。


微服务拆分原则


微服务拆分原则中,特别需要提到的是康威定律。


康维定律简单来说就是系统设计(产品结构)等同组织形式,每个设计系统的组织,其产生的设计等同于组织之间的沟通结构。如果单个服务由不同组织管理,需求无法达成统一,面临着令出多头、需求干扰的风险。


伸缩需求,同一个进程之内的不同业务功能,有时在业务量方面会出现较大的差异,具体要求的进程数量会有较大差别,这样的模块锁定在同一进程之内,势必会造成资源的浪费。


部署频率,同一个交付物内不同的组件有着不同的上线频率,会大大的提高上线流程的发生频率,会造成较大的人员浪费。


修改的相关性,如果同一交付物内的不同组件,经常会被同步修改,这可能说明,如果发生拆分,这两个模块应该是”在一起“的。


领域建模,针对业务领域,引入限界上下文(Bounded Context)和上下文映射 (Context Map)对业务领域进行合理的分解,识别出核心领域(Core Domain) 与子领域(SubDomain),并确定领域的边界以及它们之间的关系。依据核心领域和子领域划分微服务边界。


对于一个单体应用,拆分过程应该是循序渐进、逐步拆分、由简到繁、由粗到细,是一个渐进的过程。例如先将有明显边界的业务拆分为独立服务,无法明细边界的先混在一起,等业务需求逐步清晰后再拆。拆分时先拆分为几个相对较粗粒度的服务,根据业务需求情况,逐步将粗粒度的服务中相对稳定,可以沉淀的业务拆分为独立服务。在这个过程中,原有的单体应用也可以承担部分兼容能力,在改造完成前,不对外部系统造成过大的影响。



微服务的拆分是跟业务需求强相关的,如果业务需求变更不多、相对稳定,处理的请求并发量不高,单体应用的稳定性和可维护性更好,更加适用。

总结

微服务不是银弹,是用来处理海量用户、业务复杂和需求频繁变更场景下的一种架构风格。引用一句话“好的架构是演化出来的,而不是设计出来的”。任何一种架构的引入,都会带来利弊两个方面的影响,如何平衡才最重要。


四川新网银行是全国三家互联网银行之一,于 2016 年 12 月 28 日正式开业。新网银行注册资本 30 亿元,由新希望集团、小米、红旗连锁等股东发起设立,是银监会批准成立的全国第七家民营银行,也是四川省首家民营银行,同时也是全国第二家获得国家高新技术企业认定的银行。新网银行坚持“移动互联、普惠补位”的差异化定位,以及“数字普惠、开放连接”的特色化经营,着力打造成为一家数字科技普惠银行,依托领先的金融科技能力、稳健的大数据风控技术和高效的互联网开放平台运营模式,服务小微群体、支持实体经济、践行普惠金融。截止目前服务用户数 2900 多万,累计放款 9000 多万笔。



作者介绍


谢延泽,目前就职于新网银行,负责技术中台建设,核心系统技术架构设计。关注云原生领域,探索在金融行业实践思路。


本文转载自公众号阿里巴巴中间件(ID:Aliware_2018)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247488193&idx=2&sn=9bedfd8d55e54955d7927b5616adfae2&chksm=fdeb20a1ca9ca9b75dcc1432f17e48e2934c97bc50b1ff6ca5ff98355d7f55b43fd8eca64553&scene=27#wechat_redirect


2019-11-21 08:002495

评论

发布
暂无评论
发现更多内容

Nginx通过Cookie做灰度就这么简单

运维研习社

nginx 运维 灰度发布 5月日更

不是我吹!看完阿里高工码出Java150K字面试宝典,进大厂稳了

Java 程序员 架构 面试

Mysql InnoDB使用的锁

water

模块 4 作业

鲲哥

Go 并发编程-channel 连接一切

Rayjun

Go 语言

【Flutter 专题】125 图解自传 ACE_ICON.ttf 图标库

阿策小和尚

5月日更 Flutter 小菜 0 基础学习 Flutter Android 小菜鸟

技术栈,我该拿你怎么简化?

VoltDB

数据分析 5G 堆栈 边缘计算

你是做敏捷与DevOps的,还是做掉敏捷与DevOps的?

刘华Kenneth

DevOps 敏捷 转型 教练

kube-controller-manager之AD Cotroller源码分析

良凯尔

Kubernetes 源码分析 Ceph CSI

数智化社会供应链助力消费体验提升 京东图书千万好书“先5折再满减”

科技范儿

《看板方法官方指南》中文版发布了!

Bruce Talk

敏捷 Kanban Agile

架构师成长之路

soho

应用架构步入“无服务器”时代,Serverless技术迎来新发展

华为云开发者联盟

Serverless 华为云 无服务器 可信云 FunctionGraph

dubbo-go v3 版本 go module 踩坑记

apache/dubbo-go

Apache dubbo dubbo-go

一次事故,我对MySQL时间戳存char(10)还是int(10)有了全新的认识

华为云开发者联盟

MySQL 索引 时间戳 char int

大厂必问 iOS 面试题 - (上)

原来是泽镜啊

程序员 面试 ios开发

从外包辞职再到入职字节那天,我落泪了,没人知道我付出了多少

Java架构师迁哥

Hive|如何避免数据倾斜

数据社

hive 5月日更

技术管理课学习笔记 01

escray

学习 极客时间 5月日更

Django 之模板篇

若尘

django Template Pattern Python编程 5月日更 模板

iOS面试题--基础篇

ios 程序员 面试 编程之路

花5分钟手写一个简单的HashMap,搞定挑剔面试官

北游学Java

Java 面试 hashmap

iOS开发-60分钟入门

iOSer

ios iOS Document 移动开发 ios开发 iOS Developer

金三银四旗开得胜!春招字节正式批4面,顺利拿到offer

Java 程序员 架构 面试

领域驱动设计101 - 值对象

luojiahu

领域驱动设计 DDD

第一次凡尔赛,字节跳动3面+腾讯6面一次过,谈谈我的大厂面经

Java架构师迁哥

想要成为架构师?你只要满足这些条件就可以

华为云开发者联盟

设计 工程师 架构师 软件系统 软件架构师

MySQL数据库事务隔离性的实现

华为云开发者联盟

MySQL 数据库 事务 数据库隔离 事务隔离

教你一招:让集群慢节点无处可藏

华为云开发者联盟

节点 GaussDB 集群 慢节点 慢实例

接招吧!最强“高并发”系统设计 46 连问,分分钟秒杀一众面试者

面试 高并发 Java 25 周年

Java岗熬了6年,终成P8,只因搞懂了这七件事

Java架构师迁哥

新网银行微服务转型实践_技术管理_谢延泽_InfoQ精选文章