架構演進之「微服務架構」

heishaovvv發表於2019-03-01

“為什麼要搞「微服務架構」”？這也是我們當初討論的聚焦點。現在天天把“微服務”掛在嘴邊的人很多，但是有多少人真正深入思考過“為什麼”，我認為可能不多。
於是我在梳理材料的時候，就決定從源頭入手——即“為什麼”。

架構是演進的，不是一蹴而就。

“架構演進趨勢圖”中的趨勢分析，在業界比較公認。這個圖本身的內容、關於各個架構的描述、優缺點等等，網上簡單搜尋一下有大把大把的，感興趣的同學可以自行搜尋，畢竟這也不是我們文章的重點。

軟體發展的不同時期、階段，對技術的理解、選擇和應用都有著不一樣的訴求。架構的選型，永遠只有“合適與不合適”，永遠沒有“哪個更好”的說法。我們今天來談論微服務，並不是因為它更牛，而是經過謹慎分析，認為微服務的思想更符合我們的目標。
什麼是「微服務架構」？

既然聊的是“為什麼”，那麼首先要明白“什麼是”。
「一解釋就懂，一問就不知，一討論就打架」，這是之前我在網上看到的一句話，笑了好久，太貼切了，就搬了過來。

提到微服務，就沒法不提到這位“大神”——馬丁·福勒，他沒有直接給微服務下一個精準的定義，而是給出了微服務特點的描述，大概從以下四個方面來說：

1.根據業務模組劃分服務種類

2.每個服務可以獨立部署並且互相隔離

3.通過輕量的API呼叫服務

4.服務需要保證良好的高可用性

怎麼理解呢？以下是我的解讀：

第一點，按業務拆分服務，這是“水平拆分”；在技術層面的“前後分離”，屬於“垂直拆分”；橫縱一起切，就把單一的應用拆分成網狀的小塊應用，這是微服務中「微」思想的體現。

第二點，獨立部署與互相隔離，這點充分體現了“我為人人、人人為我”的設計理念，這是微服務中「服務」思想的體現。

第三點，關於輕量API，微服務本身是推薦使用輕量的通訊協議和簡單的資料結構，實際上，實施環節通常採用的都是http+json的方式。這樣做的好處是，服務之間不再需要關心對方的模型，僅通過事先約定好的介面來進行資料流轉即可。這是微服務中「解耦」思想的體現。

最後一點，比較通用了，就是現如今各種設計都必須考慮的事情。

於是，我給微服務下了一個定義（如圖）。

在實際工作中，我們遇到過各式各樣的問題，有些是技術問題，有些是業務問題，還有些是管理問題，這裡拿其中一個案例來說一下。

這種事情說大不大，說小不小。其中最麻煩的事情是“推諉”的發生。每個獨立組織都有自己的考核指標和關注點，而實際情況又不可能把具體的一個任務的界限劃分得特別清晰。例如介面定義，哪怕說的是“雙方坐下來一起商討決定”，最終還是會有一方對此事負責，推諉在所難免。

微服務的指導思想其中一塊就是關於組織機構調整的，這還有個專門的定律叫“康威定律”，感興趣的可以自行搜尋瞭解。

我們的解決辦法也很有效果。在組織機構沒有完全按照微服務的理念重新規劃之前，這類需要跨組織協同完成的任務，直接成立臨時專案組：相關的部門出人的出人、出資源的出資源，指定／選拔一個能hold住的專案經理對整件事情負責，然後大家驚奇的發現：“部門牆”問題不見了，因為所有事情都是組內事情了，整體的完成情況跟全部專案組成員的業績都掛鉤了，事情推進就非常順利。在順利交付之後，專案組解散，各回各家。極大的提升了溝通效率、交付速度，同時使得資源利用率也得到了很大的提升。

其實很多時候，大家解決問題的想法和思路，並不是要有了微服務才這樣做，而是“不謀而合”，微服務就存在於我們日常工作的點點滴滴之中。