农商行数字化转型的烦恼

Posted 2022-12-01

IT技术日益革新。当我们在给客户分享烟囱式的单体应用如何逐步拆分演变为SOA架构，SOA架构再如何彻底拆分演变成微服务架构的时候，更为新型的技术、架构又在冲击着我们的认知。

互联网行业就像技术赛道上的领跑员，拖着很多老旧应用系统的企业，如资源、金融、交通、银行等行业，也不得不努力跟一下技术的脚步。然而，从哪里起步、如何转型，成为他们最大的烦恼。

微服务相关的工作我们已经搞第四个年头了，“敏态服务运行支撑”在博云的微服务团队经过了N次实践，踩坑淌雷不计其数。从微服务框架、API网关，到服务网格、XX中台，从开源的到自研的，又将自研的开源出去，这么多项目走下来，我们觉得也该认真地记录和认真地回答一下有关“数字化转型”的问题了。正好结合最近我们博云众多的农商行项目，和大家分享一些技术架构的转型经验。

 

 

传说中所谓的“双态IT”

前两年有个流行语叫“双态IT”，是由联想提出的“稳基业、敏突破”和谐共存的发展战略。稳态，通常指因为各种原因无法微服务改造的系统，或单体的或SOA架构的；敏态，自然是指可以微服务架构改造的，也就是我们做项目的主要价值范围。所谓双态和谐共存，其实就是指我们要建设的敏态系统如何与未改造的稳态系统实现互联互通。这其实是企业数字化转型工作中的重点和难点。

 

 

敏态：敏到什么程度

数字化转型项目的核心自然是技术架构的设计。新型的技术架构无外乎容器、微服务等云原生技术。因此，使用微服务的理念，敏捷开发搭载容器技术的快速集成与持续发布，这样的架构就是我们的预期——敏态。

当然，技术架构的设计作为整个项目的核心，必须要仔细研究，诸如架构选型、组件选型、开发规范、日志规范等等。后面有机会我们会再单独写一篇文章来分析具体技术架构的设计，在今天这篇文章里，我们只谈关键目标，只谈企业数字化转型中的整体策略。

微服务的技术应该是早于容器技术的，但是当容器技术走上舞台的时候，大家才发现这样的理念正是微服务最好的载体，因此微服务也跟着火了起来。这导致有很多未接触微服务的人，以为容器和微服务是有“因果关系”的，但实际上并非如此。

其实现在很多开源的微服务技术SpringCloud、Dubbo等与容器调度Kubernetes，多多少少是有点重叠，甚至冲突的，问题主要体现在服务注册发现、网络通信和负载均衡等等。当然，相应的解决方案还是容易找到的，比如舍弃etcd的服务发现，使用微服务注册中心组件，使用underlay网络方式等，还是能找到融合点的。

总的来说，敏态“敏”到什么程度？第一，服务逐步迁入容器中，节省资源、便于调度管理（有这两点好处就够了）；第二，业务系统逐步改造成微服务，拍定一个未来五年内的微服务架构规范，在合适的机会改造每个业务系统。

那么问题来了，需要在业务系统改造成微服务的同时，将业务系统运行在容器平台中吗？经过我们多个项目的经验发现，在项目未启动的时候，这几乎是不言而喻的，但是在项目进行中却往往都是妥协的。因为容器改造和微服务改造大多数情况是在不同项目中启动，容器项目一般由运维部门推动，而微服务项目往往由架构部门推动，在项目时间紧张、各有难点并想突出收益的情况下，这样的对接有点貌合神离。

但这其实也没有关系，数字化转型不只是需要技术架构的转型，更重要的是技术理念的转型，包括运维方式、管理方式、研发模式、团队运行模式等等。所以这需要企业做好“不能一步到位”的心里准备，逐步学习、逐步遇到问题解决问题，才能更好地走好转型之路。

 

 

稳态：稳如绊脚石

微服务转型过程中，最大的绊脚石就是那些非微服务的系统，项目中通常叫做老旧系统。而这些系统往往是银行内的核心系统或关键系统。

技术架构的转型，不能影响现有业务，这是转型最大的原则和底线，所以这些在银行内业务上承担极重角色的老旧系统，在技术架构上要以稳态保留。我们做微服务治理，希望、也假设全都是微服务，接入、规范、治理、检测、展示，然后大功告成。但我们在做微服务改造的项目时，微服务治理这些只是基础，新老系统间的通信才是重点。

技术纷繁复杂，管理往往都在趋向统一。尤其是做数字化转型的时候，开发框架、运行方式、通信协议全部都要统一。为了建设更宏伟的目标，我们首先应该让通信协议统一，在协议没打通的时候，自然就应该做好协议转换工作了。敏态系统多数是七层的协议，HTTP、RPC类的，报文往往是JSON格式，但特点是比较统一，基本上已经被微服务框架所决定了；稳态系统的协议就复杂了，有很多都是独有的协议，报文格式也不同。

复杂是比较复杂的，场景变化也是比较多的，但场景和规划搞清楚了以后倒也不是特别难。原因有两点，一个是我们只考虑敏态与稳态间的通信，其实这是属于通信不频繁的，因此性能要求不会特别高，当然如果有性能要求高的我们要在规划上尽量规避；第二个是我们只考虑实际通信的具体几个接口，逐个做协议的翻译工作，平均每个接口半天时间就翻译好了。那么翻译工作在哪儿做呢，脏活累活扔给API网关。

 

 

API网关-数字化转型的负重者

 

不只是在数字化转型的项目中，在很多新型架构中都有API网关的用武之地。当然我要说一说服务网格，Sidecar其实就是个API网关，例如在Istio的解决方案中使用envoy。那在此处，API网关至少需要担任三种角色了：

• 敏态架构中，应用聚合对外提供服务，需要用到微服务网关，这是最简单的一个网关了，做简单点只要支持配置路由就可以了；做复杂点也可以加一些治理、使用、权限、审批等等。
• ESB的统一对外接口，ESB（或者SOA架构中的别的服务总线）本身就很类似于一种网关，将所有其他系统的不同协议整合、转换、通信。但是从服务总线出来的通常是TCP协议，总之不是微服务框架舒服的协议。所以还是需要再转一下，转成敏态系统可以随意访问使用的协议。这就是API网关的第二种角色，用来对接ESB这类的服务总线。
• 还有一种独立的业务系统，既没被服务总线接管，也没做微服务化改造，但就是想要注册到注册中心，以微服务的通信方式与微服务互访。以前极力不赞成使用Sidecar将老旧系统接入微服务框架中做治理，但是我们在项目中发现，企业也的确是有这样的需求，好在方案也简单。所谓Sidecar就是API网关，依然是做好协议、报文的转换，然后将其以业务服务的方式注册到注册中心。如此一来，之后对该业务系统做了改造，倒是可以更好对接之前的微服务了。
   

所以项目的重点和难点其实是在API网关的建设，为什么说是重点呢？技术架构做的是规范，服务治理做的是运行中的观测，而网关是运行中业务通信的桥梁，直接影响到业务的访问。

 

总结一下，多数金融、证券、中小银行都已经处在做数字化转型的关键阶段了，而转型的真正价值其实在于规范管理和理念学习。这个世界变化太快，等需要的时候再学习就太晚了，现在转型还是尽量把心态放在学习和适应上。那么转型中的关键：新型技术的选型、改造的范围、存量的兼容，在这篇文章里我们都做了简单的介绍，希望能给即将做数字化转型的企业或者正在做数字化转型项目的企业提供一些思路，减少一些忧虑。后续如果有机会，我们会对微服务技术架构每一块都做更深入的探讨。