共计 2928 个字符，预计需要花费 8 分钟才能阅读完成。
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 网关的建设，为什么说是重点呢？技术架构做的是标准，服务治理做的是运行中的观测，而网关是运行中业务通信的桥梁，间接影响到业务的拜访。
总结一下，少数金融、证券、中小银行都曾经处在做数字化转型的要害阶段了，而转型的真正价值其实在于标准治理和理念学习。这个世界变动太快，等须要的时候再学习就太晚了，当初转型还是尽量把心态放在学习和适应上。那么转型中的要害：新型技术的选型、革新的范畴、存量的兼容，在这篇文章里咱们都做了简略的介绍，心愿能给行将做数字化转型的企业或者正在做数字化转型我的项目的企业提供一些思路，缩小一些忧愁。后续如果有机会，咱们会对微服务技术架构每一块都做更深刻的探讨。
