传统金融行业要使微服务架构落地 必将面对6个问题

Posted 2021-04-14 twt企业IT社区

原题：金融行业微服务落地经验分享

谈到微服务，大家听的也比较多了，每个人基本上都有自己对微服务架构的理解，相比于在互联网企业的大量落地，微服务在传统金融行业（银行、证券、基金、租赁、期货等）还没有普及，个人认为：一方面和行业的天然属性有关，传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频繁，传统的技术架构能够应对这样的变更频率；一方面和传统金融行业IT系统的建设模式有关，传统金融行业很多IT系统还是基于外包厂商在做，外包厂商的技术能力约束了新技术的落地。另一方面传统金融行业对系统可用性和稳定性要求非常高。

下面我将把自认为微服务架构在传统金融行业落地可能会遇到的一些问题做一个总结，主要包括以下几个方面：

一是微服务架构最简单的理解方式是什么；

二是微服务能够带来什么；

三是微服务架构开发框架选型；

四是微服务与容器技术；

五是微服务落地涉及的部门墙；

六是微服务落地路径。

一，首先来谈一谈微服务架构是什么，如何最简单的理解

如图一所示，应用A由两个服务组成，各个服务之间存在调用依赖，各个服务的配置信息都存在自身的配置文件中，并且很可能公用一个schema，这样就会带来一些问题。

场景一：服务1如果需要调用服务2，那么服务1需要将服务2的服务ip地址写在自己的配置文件里，这样就增加了服务1与服务2的耦合性，当服务2由于某种原因更换ip地址时，服务1的配置文件也要跟着手工进行修改，不但增加劳动量，而且容易出错或者遗漏，导致系统故障；

场景二：该应用A的所有服务都使用同一个schema，那么当由于某个服务的原因需要升级schema配置，那么会同时影响服务2对数据库使用，从而两个服务都不可用。

微服务架构则可以轻松的解决这样的问题，图一中的应用，按照微服务理论拆分后，效果如图二所示：

在图二中，原来应用A的两个服务被拆分成了更细粒度的4个服务（目前业界比较流行的拆分理论是领域模型DDD）。这4个服务每个都独立的提供一种业务功能，4个服务配合实现原来A应用的能力。从图中可以看出，4个服务的配置信息都放在同一的配置中心中，服务启动的时候会从配置中心拉取自身的配置信息，从而实现自身功能代码与配置的分离，服务启动成功后，会向注册中心注册自己的服务ip和端口以及其他信息。

场景二，任何一个服务的schema的升级或者变更都不会影响到其他服务的schema，从而能够将影响降到最小。

结合这个例子，简单总结下，微服务架构就是将一个复杂应用拆分为多个相互独立的服务（基于DDD领域模型拆分），每个服务有自己的portal（如果需要的话）、web 容器和schema，服务将自己的配置信息存放在配置中心，同时将自己的服务信息存放在注册中心供其他服务查询。

二，微服务能够带来什么？

一是能够提升迭代效率。与传统单体应用不同，每个微服务是一个能够独立发布的应用服务，可作为独立组件进行编译和部署；升级代价小，服务与服务之间耦合度降低，一个服务升级不需要其他服务做变更。

二是弹性扩展。单体架构是紧耦合的，而微服务架构强调的是模块化的结构是松耦合的，应用扩展时，仅需扩展有瓶颈的微服务，有利于应用的模块化扩展。

三是容错能力。单体应用所有功能在一个进程能实现，一个功能bug可能导致整体崩溃，而微服务可实现进程级别的隔离；每个微服务是自治的，单个服务的异常通常不会导致整个系统的故障。

四是丰富的技术栈。 根据业务需求，不同的服务可以根据业务特性（如io密集型和计算密集型）实现灵活的技术选型；不同的微服务可以依赖不同的编程语言、开发框架以及数据存储技术，针对不同的服务，采用不同的技术栈。

五是提高组织效率。每个微服务可以由独立的组开发和维护，按照统一的接口规范定义好输入和输出即可，沟通成本低效率高。

三，微服务开发框架选型

如果选择了使用微服务架构进行开发应用程序，接下来要面对的就是微服务开发框架的选型。目前开源的微服务开发框架主要有spring cloud和dubbo。Spring Cloud是一系列已有框架的集合。它基于Spring Boot开发便利性简化了分布式系统基础设施的开发，如配置中心、注册中心、负载均衡、消息总线、断路器等，都可以用Spring Boot的开发模式做到统一的启动和部署。Spring cloud主要由Netflix、Config、Bus、Security、Eureka组成。dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。下面简要的对spring cloud和dubbo做个对比：

	Spring cloud	Dubbo
社区活跃度	较高	较低（截稿时阿里又开始维护）
可参考文档质量	较高	较低
调用方式	http rest api	Rpc
架构完整度	完整	本质上是一个服务治理框架，其他组件比较欠缺
第三方厂商支持	较多	较少

这里特别说下rpc和http两种调用方式带来的影响。

一是在Rpc方式下，服务的调用方和服务提供方依赖太强，每个微服务都定义了服务的service接口，一个服务在持续集成的过程中如果没有做好版本管理，很容易出现服务的调用方和服务提供方接口不一致的问题。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠约定好的标准，不存在代码级别的强依赖；二是在跨平台提供服务这个问题上，基于http的rest方案天然的支持跨平台调用，无需额外的配置，而rpc方式如果要实现跨平台调用，需要实现一层7层的http代理，工作量上会有所增加。

对于传统金融行业而言，其系统开发在一定程度上还是依赖外包第三方厂商来实现的。经过调研，目前市场上支持spring cloud开发的厂商要多于基于dubbo开发的厂商。

小结，基于以上分析，spring cloud框架，具有上手难度低，框架完成度高，社区活跃以及第三方支持厂商多等优点。如果是对于新建的微服务系统，并且开发人员不是充足，并且对性能没有太高要求的建议使用spring cloud这样的微服务框架，否则可以选用dubbo。

四，微服务与容器技术

现在一提到微服务，有很多人会想到容器技术（这里说到的容器技术是指docker）。那么微服务和容器之间到底有什么关系呢，我来简要和大家探讨下。

先抛出结论：微服务和容器其实没有半毛钱关系。微服务理念出现的比容器技术要早很多，其理念是在70年代提出的。而容器技术是2013年才提出的，它最初是由一个叫做dotcloud的项目发展而来，后来改名叫做docker。基于微服务的思想开发应用程序是完全可以不用容器技术的，例如现在很流行的spring cloud和dubbo都是可以不使用容器技术来做开发实现的。从2017年开始很多人喜欢同时提到微服务和容器化，这主要是基于以下几个原因：

（1）按照微服务的理念，如果使用容器作为基础设施，能够实现快速部署，快速迭代；

（2）在云计算浪潮中，容器作为替代vm的基础设施受到大家的关注度更高；

（3）k8s作为几乎实际默认的容器化平台标准，其集成了配置中心和注册中心，相当于天然的帮微服务架构解决了自己开发配置中心和注册中心的问题。

在我看来，以上三个是促使在2017年度很多时候，大家会将微服务和容器技术一起谈论的重要原因，甚至有些公司直接将自己的新建的微服务应用部署在容器平台上。

五，微服务落地涉及的部门墙

微服务架构在落地过程中需要开发和运维有更多的交互，一般而言在传统金融行业it各个部门的划分都比较明确，这样部门墙的问题在传统金融行业就更加明显。

例如严格按照微服务架构每个微服务需要一个数据库实例（原来架构可能是多个服务共享一个数据库实例）；甚至有的微服务自己还要有portal页面；使用基于zk原理的配置和注册中心等，这就在无形中增加了运维的工作量。

另一个角度来看，如果公司的微服务是基于docker容器做的，那么就更考验一个公司的开发和运维之间协作。因为引入容器技术，就意味着增加了很多不确定因素，这对传统金融行业追求稳定的运维工作部门而言是会有一些抵制的。

一个场景，开发团队想尝试容器化的持久化存储，这可能需运维团队对底层资源做更细致的管理，例如划分出容器分区和持久化分区，或者引入portworx容器化存储，这些改变都无疑增加了运维人员的运维成本。还有一种场景就是在微服务架构下配置中心和注册中心选型，是选用spring cloud框架中的组件还是使用k8s中的组件？

这些问题在互联网公司或者devops文化推行较好的公司都不是什么大问题，但是在传统的行业，这确实有很多现实问题。那么想推动开发和运维部门做好合作，我认为需要做到以下几点：

一是上级领导的支持（原因不解释。。。。）；

二是让开发和运维的领导都认识到微服务架构能给大家带来的好处（有时候这就需要主推微服务一方的人格魅力了）；

三是在公司内部宣传devops文化。

其实说到底还是要大家的思想有转变，从传统的合作方式转变为更符合it潮流的合作方式，从而打破部门墙。

六，微服务落地路径

下面我们来聊下如何在传统金融行业对应用系统进行改造，考虑到传统金融行业对高可用、稳定性和容灾的要求较高，将微服务真正落地下来，我认为需要以下几步：

一是在应用的选择上，选择非核心的中低频应用，我们称为应用A。这是因为非核心且中低频应用在改造过程中即使出现稳定性问题，造成的影响也是可控的。

二是将A应用通过领域模型进行拆分（如果不会使用领域模型也可以把A应用进行逻辑拆分），拆分的边界要充分考虑业务的独立性和专业性（例如搜索类、支付类），避免按团队来定义服务边界，同时要避免拆分后的维护成本高于拆分前的维护成本。在这一步中可以优先拆出无状态的模块，进行改造，另外如果有些服务对安全的要求较高，最好也要分离出，作为一个微服务部署；

三是在第二步完成后，该应用的数据库还可能是一个实例，运行一段时间后（半个月到一个月），将一个数据库实例拆分成多个数据库实例（这一步可以根据实际情况进行，如果实际情况是单个实例更好，那么就没有必要进行拆分），然后再观察一段时间；

四是对非核心的高频应用改造，同样是参考应用A的改造方式；

五是对核心低频应用改造；

六是对核心高频应用进行改造。当然，对核心应用是否要进行微服务改造这里还要考虑必要性、可行性（很多传统金融行业的核心系统都是外购的，拆分难度较大）和风险性。所以，建议的方式是对存量的非核心系统改造后，积累经验，然后在后面新系统建设的时候考虑是否微服务架构。

更多相关文章请点击阅读原文