從SOA到微服務

小明畢業後為了戶口，進入了一家大型國企的信息部門工作， 這個國企不差錢， 幾十年來隨著IT系統的發展， 也與時俱進地興建了多個信息系統，只不過自家開發的極少， 從外邊購買的極多， 雖然信息部也有開發能力， 但是當甲方的感覺是最妙的， 何況出了問題還可以把責任推出去。

在這些系統當中， 小一點兒的有自動化辦公系統(OA) , 休假系統，車輛管理系統， 薪水支付系統， 大點兒的有客戶關係管理系統， ERP系統 ..... 等等， 可以說是琳琅滿目，讓人目不暇接，幾十年來IT發展的技術，幾乎都能在公司的IT環境中找到。

小明的工作之一就是維護現在的IT系統博物館， 博物館中大部分都是遺留系統， 能工作，但是非常的老舊。硬體平台， 軟體環境，開發語言各部相同，都是異構的。

就說那個休假系統吧，還是用上個世紀流行的Delphi 寫的。 還有那個OA系統， 也是上個世紀的ASP,運行在IIS上。 雖然界面醜陋，勉強能用。

也有一點新東西，比如上周上線的那個維修系統不就用了最新的前端技術嘛， 小明也著實激動了一陣，看了兩天的React。

有一天有個著名外企的銷售來到了小明的公司，請信息部門的老大吃了飯，K了歌。。。好像還搞了些小明這些小兵不知道的秘密活動。

第二天老大給國企老總做了彙報， 過了一段時間， 公司發文了：

為了提升IT效率，打破各個信息孤島，實現各個信息系統之間的互聯互通， 讓業務和IT進行對齊， 達到業務敏捷性， 公司經慎重研究決定，邀請xxx公司作為諮詢顧問， 從即日起開始實施SOA戰略。

小明看了一遍，愣住了，上面的字全都認識， 但連起來就不知道是什麼意思， 虛頭巴腦的， 唯一確定的是，諮詢顧問要來了，要開始什麼SOA了。

顧問果然來了， 先給小明他們的信息部門洗了一次腦， 小明的腦海中被各種新式的名詞所充斥： SOA, ESB, SCA, BEPL.... 下了課， 小明和同事們討論了很久， 模模糊糊的明白了要做什麼事情。

好像是把這些遺留的異構系統包裝成粗粒度的服務， 還是 Web 服務，可以通過Http來訪問， 然後呢， 讓大家互相調用， 甚至可以把這些服務進行編排，形成一個大的業務流程， 完成更高層次的業務， 聽起來挺有意思的。

外企的銷售非常精明， 趁勢賣了一大批硬體和軟體， 他們的技術團隊還確實幫著做了一個小的驗證系統， 實現了一個業務場景，展示給公司老總看， 老總非常滿意： 不錯， 我們公司又一次站到了IT技術的前沿！

然後就沒有下文了， 領導們似乎忘記了， SOA似乎沒有發生過，互聯互通呢？ 業務敏捷呢？

小明很困惑，周末約著同學張大胖去吃飯。

張大胖在一個互聯網公司工作， 主要是做網上約車系統， 用的都是最前沿的技術， 他說： 聽起來你們要把這些遺留的異構系統做數據/信息的集成啊， 只是沒有做下去而已， 國企嘛可以理解。 你知道我們公司在幹什麼事兒嗎？

小明說：「不會和我們一樣吧？」

「完全不同！ 我們公司才成立幾年啊， 最重要的就是這個約車系統， 當然我們現在發展的很快，這三年以來系統已經快變成一個巨無霸了， 代碼已經達到百萬行級別， 沒人能搞明白了， 代碼庫非常難於管理， 衝突不斷。 系統部署也非常困難， 一點點小改動都需要巨無霸式的整體部署， 你能想像得到嗎， 我們系統重啟一次得15分鐘！」

「我賽， 這麼慢？ 不可思議，我用過你們的打車軟體， 用起來還可以啊？」

「唉， 金玉其外，敗絮其中， 你不知道我們每次發布有多痛苦， 但是競爭激烈， 我們還得頻繁發布。 所以我們做的事情和你們相反， 不是集成， 而是拆分！ 把一個巨無霸變成一些小的組件， 讓這些小組件能完全獨立的開發， 測試和部署。」

「那你們的開發團隊怎麼辦？」小明問。

「我們的組織結構也要隨著這些小組件來重構啊，你看我們分成了「乘客管理」，「司機管理」，「旅程管理」，「支付管理」等好多組，每個組只負責他們特定的一塊兒功能，並且每個組裡邊都有設計，開發，測試，部署等人員，一應俱全， 他們從頭到尾全程負責。」

「有意思啊，這些小組件都是獨立的，每個組件實例都是一個進程吧， 那這些小組件怎麼交互？難道也是通過我們公司所用的Web service ?」

「不不， 我們不用那重量級的Web service , 什麼WSDL, 什麼SOAP, 我們統統不用， 我們只用最輕量級的、基於Http 的Restful 來對外提供介面」

小明突然想到一個問題：「你們每個部門負責一個特定功能，那數據怎麼辦？還用統一的資料庫嗎？」

「這是個老大難問題，我們得做資料庫的拆分啊，唉，一言難盡。」

小明說 ：「可以理解，不過這樣以來確實是更加敏捷了。」

大胖說：「這還不是最厲害的，最厲害的是我們能快速的自動化的部署這些小組件，並且能為他們創建很多實例來運行，有一個掛掉了也沒關係，別人可以調用那些還在運行的。」

「所以關鍵點就是這些小組件對外提供的服務是無狀態的，對吧？」

「沒錯」 大胖說，「這一點和你們的SOA是一樣的， 對了， 告訴你一個小秘密，我們在生產環境會做一些『猴子測試』，通過寫腳本隨機的停掉一些實例，看看我們的系統運行的怎麼樣」

小明說：「厲害啊，你們都玩的可都是心跳啊。」

「木有辦法，只有在生產環境才能發現真正的問題啊」

「難道你們的這種方式沒有缺點嗎？」

「當然有了， 就拿資料庫來說吧， 數據做了分區， 一致性怎麼保證啊？ 選擇分布式事務非常麻煩， 有時候不得不選擇最終一致性來妥協； 還有服務多了， 客戶調用起來非常的麻煩， 所以經常得把多個介面API封裝，對外提供一個簡單的介面 ； 當然這種基於HTTP的調用遠沒有原來的在一個進程內的方式效率高。 還有一個要命的問題就是監控，你想想這麼多運行的實例， 互相之間有調用關係，一個地方出錯了， 怎麼追蹤啊，很麻煩。」

「不管如何， 你們這種把系統拆分，讓一個獨立的組織負責獨立的部分還是很敏捷啊， 對了，你說的小組件，難道沒有一個像SOA這樣的高大上名稱嗎？」

「當然有了， 業界把這種方式叫做微服務！ 雖然這個詞不能完整的表達我們做的事情。 我現在很期望Martin Flower 給它起個更貼切的名稱，就像Dependency Injection 那樣， 比之前的IoC強多了。 」

吃過飯回去的路上，小明心想：天下大勢，真是分久必合，合久必分啊， 我們在零散系統的集成， 大胖他們又在搞巨無霸應用的拆分。

相比而言，小明還是羨慕大胖，羨慕他們公司的朝氣蓬勃。他雖然明白自己所在國企的信息系統和大胖做的不一樣， 但是暮氣沉沉的感覺讓人看不到希望， 再這麼混下去， 熱愛的技術可就真的廢了。

過了年，小明已經在國企服務了3年了，順利的拿到了帝都的戶口， 然後毫不遲疑的跳槽到了大胖的公司，去搞微服務去了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！