技術(shù)每年都會(huì)有新的概念產(chǎn)生，這也是說為什么it行業(yè)需要終生學(xué)習(xí)的原因。不過如果不出現(xiàn)大的技術(shù)變革，計(jì)算機(jī)的原理沒變，那么學(xué)習(xí)各種技術(shù)相對(duì)還是比較容易，大多還是從設(shè)計(jì)理念上的改進(jìn)。即使是這樣，每年也都有很多新名詞出現(xiàn)，我們不可能每一種都去學(xué)習(xí)，但是該了解還是需要去了解一下。至于用不用，還是看業(yè)務(wù)需要。

什么是微服務(wù)

講微服務(wù)之前，先了解一下什么是服務(wù)化

服務(wù)化

服務(wù)化（SOA）是一種構(gòu)建分布式應(yīng)用的方法，本質(zhì)上是實(shí)現(xiàn)代碼模塊到服務(wù)的轉(zhuǎn)變，以方便同樣的代碼塊在分布式環(huán)境中的重用。

服務(wù)化的優(yōu)點(diǎn)

• 便捷性：屏蔽底層復(fù)雜度，調(diào)用方想函數(shù)一樣調(diào)用，不用關(guān)心內(nèi)部實(shí)現(xiàn)，可以提升代碼效率和協(xié)作效率

• 復(fù)用性，防止代碼拷貝，服務(wù)內(nèi)部更新調(diào)用方不用做更改，做到了調(diào)用服務(wù)方和服務(wù)方的代碼解耦

• 專注性，服務(wù)化以后，和其他的服務(wù)或者調(diào)用方不再有耦合關(guān)系，服務(wù)本身代碼容易更加健壯（比如做數(shù)據(jù)服務(wù)增，可以很好地內(nèi)部控制緩存和sql質(zhì)量）

• 性能提升：不同粒度的服務(wù)化，可以不同程度上增加系統(tǒng)的伸縮性。幫助系統(tǒng)進(jìn)行拆分，比如業(yè)務(wù)垂直拆分，映射到數(shù)據(jù)增就是分庫

服務(wù)化的缺點(diǎn)

• 代碼總體復(fù)雜度提升：服務(wù)化必然引入服務(wù)層，必然會(huì)在原有代碼基礎(chǔ)上提升了復(fù)雜度。
• 依賴關(guān)系容易變復(fù)雜：服務(wù)化如果做的不好，容易出現(xiàn)網(wǎng)狀依賴，甚至循環(huán)依賴
• 運(yùn)維和部署難度增加：多了一層
• 問題定位難度增加：
• 監(jiān)控難度增加：

微服務(wù)和服務(wù)化到底有什么區(qū)別

這里我自己都沒搞懂，我暫時(shí)的理解是，微服務(wù)就是一定細(xì)粒度上的服務(wù)化，具體多細(xì)，對(duì)不起不知道。但是我只需要知道他是服務(wù)化，就必然也有服務(wù)化的優(yōu)點(diǎn)和缺點(diǎn)。

為什么使用微服務(wù)？

那一定是因?yàn)樗膬?yōu)點(diǎn)了，上面那些優(yōu)點(diǎn)都是。尤其是Google的Jeff Dean的觀點(diǎn)：讓Google具備了千人并行協(xié)作開發(fā)的能力。這正好和我最近管理的時(shí)候想起的怎么提高多人協(xié)作效率的問題不謀而合。

如果項(xiàng)目開發(fā)初期，團(tuán)隊(duì)比較小，一個(gè)項(xiàng)目所有代碼都寫在一起三五個(gè)人每個(gè)人負(fù)責(zé)一部分，偶爾發(fā)生git沖突了解決一下，也沒有什么問題，大家整體效率還是很高的。但是當(dāng)項(xiàng)目體量逐漸大了以后，團(tuán)隊(duì)協(xié)作各種問題都會(huì)浮出水面。我簡單舉例

如果商品數(shù)據(jù)層要做緩存，怎么做？

如果不做服務(wù)化，那么一個(gè)項(xiàng)目所涉及到的代碼都要做緩存處理，比如前臺(tái)的接口，后臺(tái)的接口，定時(shí)腳本的接口等。都要在orm系統(tǒng)或者dao文件中寫一遍緩存功能的增刪改查，如果誰那邊代碼寫的不好，緩存加了沒有刪除，刪除了沒有加入，都會(huì)出現(xiàn)數(shù)據(jù)問題，每個(gè)項(xiàng)目組都要進(jìn)行排查。而服務(wù)化以后，只有服務(wù)層做一次就可以，出了問題如果定位為服務(wù)層問題，也只需要這一組去排渣即可。
2. 如果項(xiàng)目組想要增加人數(shù)來增加開發(fā)效率，怎么辦

傳統(tǒng)的如果項(xiàng)目沒有拆分服務(wù)化的時(shí)候，往項(xiàng)目中增加人數(shù)，按照人月神話的理論來說，不僅不會(huì)增加效率，還有可能帶來更多問題。因?yàn)檫@里面涉及到溝通成本和了解成本，還有可能互相影響。而微服務(wù)就是把代碼進(jìn)行細(xì)分成某個(gè)粒度，正好讓大家各司其職，都做自己的事情，只是最終彼此調(diào)用，但是又不用關(guān)心彼此是怎么實(shí)現(xiàn)代碼的。這樣從整體上來說就可以達(dá)到各團(tuán)隊(duì)成員職責(zé)解耦，降低了互相之間干擾和溝通的成本。

其實(shí)在三年前上一個(gè)公司的時(shí)候，和一個(gè)同事談?wù)撨@個(gè)系統(tǒng)拆分的時(shí)候，自己就已經(jīng)有類似的想法，不過那時(shí)候我還只是其中一個(gè)項(xiàng)目的技術(shù)經(jīng)理，并沒有對(duì)此進(jìn)行實(shí)際操作。

要不要使用微服務(wù)？

根據(jù)上面的理解，我們?cè)诳紤]要不要用微服務(wù)的時(shí)候，首先就要知道，如果你目前用不到微服務(wù)的任何優(yōu)點(diǎn)，就不要嘗試去使用微服務(wù)。不要為了使用新技術(shù)而使用新技術(shù)，技術(shù)都是用來解決問題的。

所謂的解耦，都是因?yàn)檎娴牡搅诵枰怦畹臅r(shí)候。對(duì)應(yīng)到技術(shù)使用也是一樣，不使用這個(gè)技術(shù)，已經(jīng)開始造成了明顯的問題，那么就是你該尋求新解決方式的時(shí)候了。

以前創(chuàng)業(yè)的時(shí)候和朋友聊天他說了一句話：當(dāng)你自己就可以搞定的時(shí)候，就自己搞定，因?yàn)樽约阂粋€(gè)人毫無牽掛跑的最快。當(dāng)你發(fā)現(xiàn)你自己解決不了所有問題，需要引入其他合伙人的時(shí)候，盡量選擇哪種和你最匹配的，內(nèi)耗最少的。當(dāng)時(shí)深以為然。映射到技術(shù)上也一樣。在對(duì)的時(shí)候選擇對(duì)的技術(shù)就好，選擇了太超出當(dāng)前體量的技術(shù)，徒然增加了復(fù)雜性反而可能降低效率。

總結(jié)

以上是生活随笔為你收集整理的为什么使用微服务？要不要使用微服务？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。