云原生银行Service Mesh技术

Posted 2021-04-23 XDiH

一、概述

Service Mesh又叫做服务网格，是云原生技术中最新的发展方向，可以大大简化银行业务开发的复杂度，加快业务上线的速度；Service Mesh已经在Google、微软、阿里、网易等大型互联网公司落地实践2年以上，承载过每秒百万级并发量级别的考验。

二、传统银行系统架构历史回顾

90年代早期或之前的银行业各个分支行都是人工记账，定期由各分支行定期逐级上报进行信息传递：

90年代中后期，随着银行、金融业务的快速增长，早期的人工记账、集中送报的形式已经不能满足业务的增长需求了，比较大型的国有银行开始在分行级别部署基于IBM PowerPC机型的分行中心：

2000年，各大银行开始做非分布式的大集中，分为“网状”和“集中式总线”两种：

1.网状：

网状系统的缺点是业务集成困难，需要对接多种不同的服务和协议。对接成本和维护成本高。这一时期的系统对接方式一般是通过tcp/soap协议直接进行调用，难管理，难维护。

2.集中式总线：

集中式总线的架构解决了网状对接困难的问题，但是esb本身是一个集中化的瓶颈，在流量和系统稳定性上都存在潜在的隐患，比较典型的包括了IBM, ServiceMix, Oracle的一些esb解决方案提供商。但是esb带来的另一个问题是：不同的系统提供商之间的服务协议不同，不能互通，一旦选用了一种就锁定了，很难再改用或兼容另外一种；即便是到了2021年的今天，很多小的城商行都没有完全实现集中式总线的系统架构。换而言之，集中总线式的系统架构已经能满足大部分“流量不大、业务迭代速度慢”的银行业务需求了。

2012年后，银行开始实现业务互联网化，互联网化之后的架构如下图：

互联网化后，在银行核心不改变的情况下，业务逐渐拆小，迭代速度加快，开始向分布式、互联网化的服务架构演进。从之前使用的J2EE，Solaris，PowerPC大型机向基于VMWare, KVM的虚拟机，和RedHat, Spring, Dubbo等通过软件进行服务定义、治理演进，DevOps、负载均衡、分布式系统逐渐进入银行的业务研发。

三、微服务化银行信息系统

2015年之后，随着互联网金融、FinTech、万众创新的趋势推行开来，互联网的业务变化速度和碎片化的需求逐渐影响到银行的业务变化；银行也需要跟随互联网客户的需求更快地改变自己的业务、技术实现。因此催生出了容器化、微服务化的互联网银行系统架构。

截止2021年的今天，只有互联网银行像网商、微众和技术演进比较靠前的银行（如：平安银行）采用了这样的架构。微服务让系统间去耦合，服务的抽象和功能更聚焦。例如负责维护对账的系统只关心对账的功能、业务系统集成下层微服务的功能使得业务的迭代更加快速，开发新业务的复杂度也逐渐降低。

四、基于云原生的银行

微服务多了，需要考虑的系统间的交互的复杂性也同时增加了，这么多微服务怎么进行治理？并发、基于大规模分布式系统的ACID、全一致性、微服务的版本、向下兼容、监控、限流、熔断、微服务间的分布式事务等问题到达一定规模后，并不一定能使微服务的研发比传统大系统更快速。

比如：上图是Netflix的一个微服务分布图，当微服务成百上千之后，微服务的治理和持续迭代是成混沌的，一定程度阻碍系统的发展和演进。

因此诞生了K8s和Service Mesh技术。基于云原生的服务开发、治理，让业务的开发更简单，最终到达业务的研发只是一些接口的集成、联调和测试。业务研发只需要思考业务的流程，而不再需要思考系统、分布式、通信、运维的复杂关系。

云原生

云原生的概念指的就是解决上面说到的问题，大部分的分布式系统的复杂问题都被云平台提供的能力包掉了，业务的研发尽量多的Focus在业务本身的流程上。这里说到的能力包括：

1.系统的动态扩缩容

2.灰度发布

3.自动调度

4.自动修复

K8s

K8s源于Google的Borg系统，Google的分布式服务早在2010年之前就已经很强大了。一个Youtube的视频会被切分成100份，每份同城3副本；Borg就是用来云化管理云服务自动调度、动态扩缩容能力的；K8s是强化的开源版本。K8s之前，不同编程语言的服务之间互相调用是一个比较困难的事情。

K8s的系统架构简单说来分为这么几个概念：

1.API Server

API Server是外部和K8s进行交互的入口，包括部署容器，扩容等功能。

2.Scheduler

Scheduler是K8s的调度器，他对一个容器需要的cpu, 内存等资源在集群上进行动态的分配和管理。

3.Etcd

etcd是一个分布式的kv存储，用来存储服务、集群、部署等管理关系。

4.Controller

Controller负责动态扩容、缩容、自动修复等功能。

5.Node

Node是集群上一个节点在K8s上的抽象。

6.Pod

Pod是一个部署的单位，里面可以有1个或多个容器。

7.Service

Service是开放服务调用，服务发现的抽象。

8.Deployment

Deployment描述的一次部署，关联一个或多个Pod。

基于K8s的云原生服务已经可以把银行内大部分的技术服务、数据库、中间件都进行统一的、自动化、程序化的进行更简便的管理。

K8s也可以比较轻易的实现灰度发布。

Service Mesh

基于K8s和容器化虽然能把服务的部署、发布、规模等管理做到大部分自动化、简单化。但是微服务的管理和开发仍然需要考虑以下这些问题：

1.限流

2.熔断

3.通信

4.服务发现、注册

5.日志

6.分布式Tracing等问题

Service Mesh可以进一步简化开发流程，通过平台抽象，运用代理来解决上述这些问题。

Service Mesh有很多种主流的实现：

1.Istio

2.Linkerd

3.nginx Service Mesh

4.Consul

本期文章只讲Istio, 下图是Istio架构图：

Istio将微服务的通信层抽象到一个Proxy里，大部分的RPC、Tracing、日志、监控可以无侵入式的通过代理完成。Istio用到的Proxy是Envoy，Envoy是基于C++实现的，因此大部分的通信功能可以很稳定的，低内存的允许，不需要占用JVM的内存，减少Full GC的概率。用户只需要开发本地应用，做好分布式锁、分布式事务管理即可，大部分的复杂问题都被抽象到了Proxy。

除此之外, Control Plane是做熔断、限流、服务注册发现的平台，Pilot负责注册和管理各个pod里的proxy, Galley负责管理配置，Citdel负责管理TLS认证、签名，运用Control Plane实现限流、熔断、鉴权等功能。Istio还可以借助Control Plane实现策略的热加载，例如熔断、限流、服务注册等功能可以在不启动控制和服务节点的情况下实施。

随着服务网格越来越成熟，越来越多的中间件例如消息队列、分布式存储、数据库等功能也都会逐渐被抽象到proxy里，Service Mesh逐渐会进化成为真正做到只需要集成业务和接口，大部分的复杂能力都被基于服务网格的平台包掉的平台化能力。

运用Istio之后，可以很轻易的达成不同编程语言的、不同版本的运行环境之间的服务互调，各个微服务、中台、业务可以完全独立自主进行迭代，互不影响。例如Java 16的运行时可以去调用Java 5实现的核心，也可以调用基于Golang、JS、Python、Ruby实现的服务，也可以反过来。他们之间的服务抽象、治理策略都可以是统一、可以配置的，Istio可以很大程度地实现业务间的解耦，让开发和迭代的速度更快。

五、总结

Service Mesh是2018年之后兴起的云原生技术发展方向，与之类似的还有腾讯的Event Mesh, 最近兴起的Serverless Mesh等，其目的都是为了能让业务开发更快，业务与中台、底层的技术间进行充分的解耦，开发、维护更简单，成本更低。

END

金融科技知识 周周学