[[197924]]

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

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

架構(gòu)是演進的，不是一蹴而就

“架構(gòu)演進趨勢圖”中的趨勢分析，在業(yè)界比較公認。這個圖本身的內(nèi)容、關(guān)于各個架構(gòu)的描述、優(yōu)缺點等等，網(wǎng)上簡單搜索一下有大把大把的。

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

什么是微服務(wù)架構(gòu)?

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

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

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

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

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

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

按業(yè)務(wù)拆分服務(wù)，這是“水平拆分”;在技術(shù)層面的“前后分離”，屬于“垂直拆分”;橫縱一起切，就把單一的應(yīng)用拆分成網(wǎng)狀的小塊應(yīng)用，這是微服務(wù)中“微”思想的體現(xiàn)。

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

關(guān)于輕量 API，微服務(wù)本身是推薦使用輕量的通訊協(xié)議和簡單的數(shù)據(jù)結(jié)構(gòu)，實際上，實施環(huán)節(jié)通常采用的都是 http+json 的方式。

這樣做的好處是，服務(wù)之間不再需要關(guān)心對方的模型，僅通過事先約定好的接口來進行數(shù)據(jù)流轉(zhuǎn)即可。這是微服務(wù)中“解耦”思想的體現(xiàn)。

***一點，比較通用了，就是現(xiàn)如今各種設(shè)計都必須考慮的事情。于是，我給微服務(wù)下了一個定義，如下圖：

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

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

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

微服務(wù)的指導(dǎo)思想其中一塊就是關(guān)于組織機構(gòu)調(diào)整的，這還有個專門的定律叫“康威定律”。

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

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

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

其實很多時候，大家解決問題的想法和思路，并不是要有了微服務(wù)才這樣做，而是“不謀而合”，微服務(wù)就存在于我們?nèi)粘９ぷ鞯狞c點滴滴之中。

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

從五個具體的方面來談：

業(yè)務(wù)拆分，體現(xiàn)在設(shè)計環(huán)節(jié)：在設(shè)計的時候，要有足夠的判斷力來合理的規(guī)劃服務(wù)之間的界限。

服務(wù)治理，底層技術(shù)的支持：首先要選一款適合自己實際情況的分布式服務(wù)基礎(chǔ)框架，對于服務(wù)的發(fā)現(xiàn)、治理、熔斷、降級，都要做好相應(yīng)的技術(shù)準備。

自動測試，一定要自動化。微服務(wù)一個明顯的表象就是隨著服務(wù)的增多，如果繼續(xù)沿用傳統(tǒng)的測試模式就會遇到瓶頸，為了保證高效的迭代，盡量做到更多的環(huán)節(jié)實現(xiàn)自動化。

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

監(jiān)控：包括硬件環(huán)境、服務(wù)狀態(tài)、系統(tǒng)健康度、接口調(diào)用情況、異常的實時告警以及潛在問題的事先預(yù)警等等。監(jiān)控在實施微服務(wù)過程中會重要到什么程度呢?一句話：沒準備好監(jiān)控，就不要搞微服務(wù)。

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