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閘道器的建設，為什麼說是重點呢？技術架構做的是規範，服務治理做的是執行中的觀測，而閘道器是執行中業務通訊的橋樑，直接影響到業務的訪問。