[[197924]]

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

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

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

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

軟件發(fā)展的不同時(shí)期、階段，對(duì)技術(shù)的理解、選擇和應(yīng)用都有著不一樣的訴求。架構(gòu)的選型，永遠(yuǎn)只有“合適與不合適”，永遠(yuǎn)沒(méi)有“哪個(gè)更好”的說(shuō)法。我們今天來(lái)談?wù)撐⒎?wù)，并不是因?yàn)樗＃墙?jīng)過(guò)謹(jǐn)慎分析，認(rèn)為微服務(wù)的思想更符合我們的目標(biāo)。

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

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

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

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

大概從以下四個(gè)方面來(lái)說(shuō)：

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

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

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

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

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

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

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

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

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

例如接口定義，哪怕說(shuō)的是“雙方坐下來(lái)一起商討決定”，最終還是會(huì)有一方對(duì)此事負(fù)責(zé)，推諉在所難免。

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

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

然后大家驚奇的發(fā)現(xiàn)：“部門墻”問(wèn)題不見(jiàn)了，因?yàn)樗惺虑槎际墙M內(nèi)事情了，整體的完成情況跟全部項(xiàng)目組成員的業(yè)績(jī)都掛鉤了，事情推進(jìn)就非常順利。

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

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

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

從五個(gè)具體的方面來(lái)談：

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

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

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

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

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

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