最近使用微服務和觸發器的場景較多，想著結合一些理論知識和實踐做一些梳理和總結，從最開始的雲裡霧裡，到現在的使用倒也經歷了一段時間。剛接觸這兩個概念的時候感覺很亂，觸發器和微服務有什麼區別呢，好像都是起個過濾器的作用，在程式碼執行到一定邏輯的時候來呼叫，如果非要說區別，可能就是：

• 觸發器粒度大一些？微服務粒度小一些？
• 微服務通過url呼叫，觸發器通過指令碼呼叫

通過後來查閱資料學習到的一些東西發現，上述區別並不盡然，甚至有些謬誤，首先粒度大小並不絕對，其次呼叫方式並不能從根本上區分二者關係。

在接下來分析之前，先說個自我總結髮言性的結論：微服務的主要作用就是解耦合，將服務拆分，易於維護和擴充套件。觸發器的作用就是由操作行為自動觸發的資料變化

初一接觸微服務，感覺莫名其妙，要在類的頭上加標籤，要在方法的頭上加標籤，和介面類似，但又不是介面，然後上線的時候還要各種操作ESB，不過最後能操作成功，所以到頭來只是會用而已，不知道為什麼這樣用，只知道微服務怎麼呼叫，部署，不知道為什麼要呼叫、部署，於是決定探究探究。

微服務是幹嘛的

我對於微服務最大的體會就是：對於雲平臺來說，如果元資料驅動的平臺元件是骨骼，那麼微服務和觸發器就是串聯骨骼的經絡和血脈沒有經絡和血脈，一堆元件僅僅是靜態的，不能變化，沒有反饋，更何談互動。而一個PaaS平臺可以孵化無數個SaaS應用，每個應用都需要使用一套小服務來開發，而為了防止應用搭建複雜化和避免後期難以維護，所以每個服務執行在自己的程序中，並使用輕量級機制通訊，通常是HTTP AP（Rest的方式，這就是為什麼我能看到那些標籤的存在）

• 這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署（體現在平臺就是微服務站點部署和獨立微服務站點部署）
• 這些服務可以使用不同的程式語言實現（只要實現結果，無所謂程式語言，這是我認為現在平臺沒有充分使用到微服務的地方，也可能是我平時使用其它語言的業務場景較少）
• 這些服務可以使用不同資料儲存技術（“非結構化資料和結構化資料都可以按需儲存”）
• 這些服務可以保持最低限度的集中式管理（這個厲害了，相當於介面不僅可以在一個專案裡複用，甚至在不同專案間複用）

官方有個2pizza理論很有趣: 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務，一定要區別於系統，服務一個或者一組相對較小且獨立的功能單元，是使用者可以感知最小功能集。

為什麼用微服務

在談這一塊兒的時候，我決定用一個故事作為先導，增加部落格的可讀性。

一個開店的故事

怎麼解釋微服務的使用由來呢，我準備講個故事：森林裡有隻大老虎一開始開了一家水果攤，用來對外售賣水果，並且為水果攤投資瞭如下幾個部分（水果店鋪租賃（小兔子負責），水果進貨及運輸（從小鹿子負責），水果銷售（僱傭了一個土撥鼠）），注意，現在大老虎的投資都是點對點的服務（租賃，進貨及運輸，水果銷售）。生意特別好，過了段時間，有些顧客向大老虎提出了買肉的需求，於是大老虎看到了商機又開了一家肉鋪，同樣進行投資（肉鋪租賃（考拉負責），肉類進貨及運輸（倉鼠負責），肉類銷售（僱傭了猴子）），同樣生意火爆，接下來大老虎開了一家海鮮店，又消耗了一套投資，再之後是蔬菜鋪，文具店等等，每開一個店鋪，就消耗一套投資，維護一撥點對點的服務，大老虎發現自己的機構開始臃腫了，出現了以下問題：

1. 肉的價格怎麼定，蔬菜的價格怎麼定，各個店鋪獨立為政，難以統計
2. 哪個店鋪到期，哪個店鋪沒到期；水果的淡季，肉類的旺季的時候，土撥鼠沒事兒幹，猴子忙不過來；運輸的時候有時候運菜忙，有時候運肉忙，運輸車輛不能複用。
3. 主管進貨的小鹿子突然離職，這樣，一段時間，水果都供應不上，很多事情都是小鹿子自己維護的，走的時候也沒好好交接

思考了問題後，大老虎做出如下調整，將所有單獨的店鋪整合為一個超市，中間有一根ESB的資料匯流排來對接訊息（肉價漲了，菜價該怎麼調之類的訊息互動），前邊是各類店鋪（應用），後臺則是一堆服務（所有關於定價的整合為定價服務，所有關於運輸的整合為運輸服務，所有關於租賃的整合為倉儲服務），這樣整合之後，產生了以下好處：

1. 各類服務可複用了，例如運輸車輛可以依據哪個地方忙閒靈活調配，小鹿子離職也不怕，誰都懂運輸業務。
2. 不必去單獨維護獨立應用去耗費大量精力，擴充套件性大大增加，再開多少個店也木有問題
3. 之前水果的標價是精確到小數點後2位，肉是3位，之前菜鋪通過電話溝通，價格記錄在紙上，肉鋪通過電子錄入，雜七雜八的，很難結算，現在通過ESB統一控制，財務結算的時候不再混亂。

到了這裡其實就完成了面向服務的SOA架構，後端封裝了一系列自治的服務，前端是一系列應用，中間通過資料匯流排互動資訊，統一格式配置和管理，讓大老虎的店擴充套件起來越來越容易，越來越方便。但是在超市運營了一段時間後，大老虎又發現瞭如下問題：

1. 運輸服務部分越來越龐大，有的需要及時運送，有的需要加保鮮膜，各種不同場景的運輸衍生出來。
2. 倉庫中心越來越龐大，集中在一個越來越大的倉庫裡，存取貨都很不方便，各種食品需要儲存條件又不一樣，溫度高了不行（肉類要腐爛），溫度低了也不行（鮮花要被凍死）。
3. 原來的定價服務是用野狗財務公司提供的標準，但現在收費越來越高，想換又不能換。

這個時候大老虎召集超市的高管們商量了下，決定採用如下措施：

1. 將運輸服務拆成一個個小的獨立服務，例如為了方便肉菜蛋奶的新鮮，拆分了一個宅急送服務，對於不著急的水果，零食等拆分了一個普通運輸服務，這些微小的服務不依賴於一個應用，但能保證提供更好的更有針對性的服務。
2. 倉庫拆分為冷鮮庫（mysql），溫室（redis）等，依據需求做更多的拆分（SOA雖然也能保證，但沒有更細化的處理）
3. 定價服務有的用野狗公司的，有的用豺狼公司的，實現最大化的隨意

到了這裡其實就完成了簡單的微服務架構微服務架構裡，服務拆分的更細，不僅能達到服務自治，還能實現團隊自治，即一個服務模組可以拆分的更細，由不同團隊去維護。自治服務內部的耦合更加鬆了。

以上這個瞎編的故事就是我對微服務的一些理解，從傳統軟體的開發，到面向服務的SOA+ESB匯流排模式，再到微服務架構，這個故事可能表述不清楚所有的概念，但能有個大概瞭解吧。

談談這個故事

首先大老虎的開店模式是傳統的IT軟體開發流程，在傳統的IT行業軟體大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴充套件性差，可靠性不高，維護成本高。一間間店鋪各自獨立為政，擴充套件性極差。體現在：

• 複雜性逐漸變高，比如有的專案有幾十萬行程式碼，各個模組之間區別比較模糊，邏輯比較混亂，程式碼越多複雜性越高，越難解決遇到的問題。（肉鋪急速擴充套件，豬肉，牛肉，狗肉，亂七八糟肉越來越難維護）
• 技術債務逐漸上升，公司的人員流動是再正常不過的事情，有的員工在離職之前，疏於程式碼質量的自我管束，導致留下來很多坑，由於單體專案程式碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。（肉鋪主管運輸的小鹿子離職，整個肉類運輸癱瘓）
• 部署速度逐漸變慢，這個就很好理解了，單體架構模組非常多，程式碼量非常龐大，導致部署專案所花費的時間越來越多，曾經有的專案啟動就要一二十分鐘，這是多麼恐怖的事情啊，啟動幾次專案一天的時間就過去了，留給開發者開發的時間就非常少了。（每天菜譜營業前都要集合所有員工，分配任務，應對新的顧客需求場景）
• 阻礙技術創新，比如以前的某個專案使用struts2寫的，由於各個模組之間有著千絲萬縷的聯絡，程式碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個專案將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。（以前用斧子切牛肉，現在想換菜刀，換了菜刀發現豬肉需要斧子）
• 無法按需伸縮，比如說電影模組是CPU密集型的模組，而訂單模組是IO密集型的模組，假如我們要提升訂單模組的效能，比如加大記憶體、增加硬碟，但是由於所有的模組都在一個架構下，因此我們在擴充套件訂單模組的效能時不得不考慮其它模組的因素，因為我們不能因為擴充套件某個模組的效能而損害其它模組的效能，從而無法按需進行伸縮。（總共就那麼點兒員工，加個銷售，就少個運輸）

到後來大老虎引入了SOA模式，這種模式解決了相當一部分問題，但隨著規模的龐大，由於 SOA 早期均使用了匯流排模式，這種匯流排模式是與某種技術棧強繫結的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。這個時候就需要加點兒微服務啦。微服務相對於SOA架構的區別是：

• 不與某種技術棧強繫結，這是最大的區別（定價服務使用了野狗公司，這個就很惱火，完全可以用其它公司更便宜的。）
• 服務可以更加細化拆分和部署（有點兒像docker啊）（將運輸服務拆成一個個小的獨立服務，例如為了方便肉菜蛋奶的新鮮，拆分了一個宅急送服務，對於不著急的水果，零食等拆分了一個普通運輸服務，這些微小的服務不依賴於一個應用，但能保證提供更好的更有針對性的服務。）

微服務的特性

• 每個微服務可獨立執行在自己的程序裡，一系列獨立執行的微服務共同構建起了整個系統
• 每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，使用者管理等（我用於圖書管理系統和工單中心）
• 微服務之間通過一些輕量級的通訊機制進行通訊，例如通過REST API或者RPC的方式進行呼叫**（這就是Rest標籤的由來吧，是一種通訊機制）。**

微服務的特點

• 易於開發和維護。由於微服務單個模組就相當於一個專案，開發這個模組我們就只需關心這個模組的邏輯即可，程式碼量和邏輯複雜度都會降低，從而易於開發和維護。（部署獨立mrest站點，啟動迅速，程式碼量小）
• 啟動較快，這是相對單個微服務來講的，相比於啟動單體架構的整個專案，啟動某個模組的服務速度明顯是要快很多的。（回收應用程式池即可，不到1分鐘搞定）
• 區域性修改容易部署,在開發中發現了一個問題，如果是單體架構的話，就需要重新發布並啟動整個專案，非常耗時間，但是微服務則不同，哪個模組出現了bug只需要解決那個模組的bug就可以了，解決完bug之後，只需要重啟這個模組的服務即可，部署相對簡單，不必重啟整個專案從而大大節約時間。（有了bug直接hotfix這部分的ESB的interface）
• 技術棧不受限，比如訂單微服務和電影微服務原來都是用java寫的，現在我們想把電影微服務改成nodeJs技術，這是完全可以的，而且由於所關注的只是電影的邏輯而已，因此技術更換的成本也就會少很多。（雖然目前還沒有接觸到多語言技術擴充套件，但感覺這個很強）
• 按需伸縮，單體架構在想擴充套件某個模組的效能時不得不考慮到其它模組的效能會不會受影響，對於微服務來講，完全不是問題，電影模組通過什麼方式來提升效能不必考慮其它模組的情況。

今天這篇就大概聊聊微服務是幹嘛的，以及軟體開發如何由IT獨立單體架構到SOA架構再到微服務架構，之後實踐多了，繼續這個系列的跟進吧，希望能在更多業務場景裡使用到微服務，對它的部署、呼叫，編寫，維護等有更深刻的理解。PS：最近部落格產出量較少，是得繼續多學學啦。