從源頭入手，一分鐘秒懂為什么要搞微服務架構？

現在天天把“微服務”掛在嘴邊的人很多，為什么要搞微服務架構?有多少人真正深入思考過“為什么”，我認為可能不多。

于是我在梳理材料的時候，就決定從源頭入手——即“為什么”。

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

“架構演進趨勢圖”中的趨勢分析，在業界比較公認。這個圖本身的內容、關于各個架構的描述、優缺點等等，網上簡單搜索一下有大把大把的。

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

什么是微服務架構?

既然聊的是“為什么”，那么首先要明白“什么是”。

“一解釋就懂，一問就不知，一討論就打架”，這是之前我在網上看到的一句話，笑了好久，太貼切了，就搬了過來。

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

大概從以下四個方面來說：

• 根據業務模塊劃分服務種類。
• 每個服務可以獨立部署并且互相隔離。
• 通過輕量的 API 調用服務。
• 服務需要保證良好的高可用性。

怎么理解呢?以下是我的解讀：

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

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

關于輕量 API， 微服務本身是推薦使用輕量的通訊協議和簡單的數據結構，實際上，實施環節通常采用的都是 http+json 的方式。

這樣做的好處是，服務之間不再需要關心對方的模型，僅通過事先約定好的接口來進行數據流轉即可。這是微服務中“解耦”思想的體現。

最后一點，比較通用了，就是現如今各種設計都必須考慮的事情。于是，我給微服務下了一個定義，如下圖：

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

這種事情說大不大，說小不小，其中最麻煩的事情是“推諉”的發生。每個獨立組織都有自己的考核指標和關注點，而實際情況又不可能把具體的一個任務的界限劃分得特別清晰。

例如接口定義，哪怕說的是“雙方坐下來一起商討決定”，最終還是會有一方對此事負責，推諉在所難免。

微服務的指導思想其中一塊就是關于組織機構調整的，這還有個專門的定律叫“康威定律”。

我們的解決辦法也很有效果，在組織機構沒有完全按照微服務的理念重新規劃之前，這類需要跨組織協同完成的任務，直接成立臨時項目組：相關的部門出人的出人、出資源的出資源，指定/選拔一個能 hold 住的項目經理對整件事情負責。

然后大家驚奇的發現：“部門墻”問題不見了，因為所有事情都是組內事情了，整體的完成情況跟全部項目組成員的業績都掛鉤了，事情推進就非常順利。

在順利交付之后，項目組解散，各回各家。極大的提升了溝通效率、交付速度，同時使得資源利用率也得到了很大的提升。

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

要搞微服務了，有啥建議么?通過我們不斷的摸索和總結，要做好微服務，就要做好一定的準備工作。

從五個具體的方面來談：

業務拆分，體現在設計環節： 在設計的時候，要有足夠的判斷力來合理的規劃服務之間的界限。

服務治理，底層技術的支持： 首先要選一款適合自己實際情況的分布式服務基礎框架，對于服務的發現、治理、熔斷、降級，都要做好相應的技術準備。

自動測試，一定要自動化。 微服務一個明顯的表象就是隨著服務的增多，如果繼續沿用傳統的測試模式就會遇到瓶頸，為了保證高效的迭代，盡量做到更多的環節實現自動化。

自動運維 ： 微服務拆分之后，每個服務都可以獨立部署，進而言之應該是隨時隨地可以升級。尤其當互聯網發展到今天，業務要保持對市場變化的一個高效響應，自動化運維就是提升交付速度的一個重要環節。

監控： 包括硬件環境、服務狀態、系統健康度、接口調用情況、異常的實時告警以及潛在問題的事先預警等等。監控在實施微服務過程中會重要到什么程度呢?一句話：沒準備好監控，就不要搞微服務。

最后，微服務不是銀彈，軟件領域沒有銀彈，微服務以其特有的優勢在解決一些問題的同時，也引入了其他問題，以下這幾點，必須要深刻的思考，三思而后行。

 

來自：http://developer.51cto.com/art/201707/545735.htm