從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年了，順利的拿到了帝都的戶口， 然后毫不遲疑的跳槽到了大胖的公司，去搞微服務去了。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
