戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！

作者 |?奎哥

來(lái)源?| 不止思考

微服務(wù)這幾年不可謂不火，很多技術(shù)團(tuán)隊(duì)都開(kāi)始在自己的項(xiàng)目上引入了微服務(wù)。一方面這些團(tuán)隊(duì)確實(shí)很好的推動(dòng)了微服務(wù)的應(yīng)用和發(fā)展，另一方面也可以看到一些盲目追技術(shù)熱點(diǎn)的行為所帶來(lái)的危害，比如很多中小團(tuán)隊(duì)對(duì)微服務(wù)的基礎(chǔ)知識(shí)只是做了很淺顯的了解就開(kāi)始盲目的推動(dòng)微服務(wù)的實(shí)施，最后導(dǎo)致了項(xiàng)目的失敗。

微服務(wù)要想做好是一個(gè)非常復(fù)雜的架構(gòu)，今天就先只聊一聊微服務(wù)的一些基礎(chǔ)架構(gòu)，算是入門(mén)篇。

一、什么是「 微服務(wù) 」？

「 微服務(wù) 」由 Martin Fowler 提出，它是指一種軟件架構(gòu)風(fēng)格。一個(gè)大型的系統(tǒng)可以由多個(gè)微服務(wù)組成，每個(gè)微服務(wù)是被獨(dú)立部署，獨(dú)立完成自己的任務(wù)單元，微服務(wù)之間是通過(guò)API方式進(jìn)行通信調(diào)用，是松耦合的。

這個(gè)模式聽(tīng)著是不是很熟悉的感覺(jué)？

因?yàn)樵谔岢觥?微服務(wù) 」概念之前，很多互聯(lián)網(wǎng)公司的中大型項(xiàng)目早就是按照將業(yè)務(wù)拆分成獨(dú)立單元的形式在部署和架構(gòu)的，這與微服務(wù)的思路是一脈相通的，只不過(guò)實(shí)現(xiàn)方式?jīng)]有現(xiàn)在這么規(guī)范與體系。

那「 微服務(wù) 」到底是怎么演變過(guò)來(lái)的呢？

在做一個(gè)新項(xiàng)目的時(shí)候，一開(kāi)始項(xiàng)目大多數(shù)都很小，都是「 單體應(yīng)用 」，這是很常見(jiàn)的做法。在項(xiàng)目規(guī)模小的時(shí)候，這種方式開(kāi)發(fā)效率和運(yùn)維效率都最高，符合互聯(lián)網(wǎng)公司快速響應(yīng)的要求。

但是隨著業(yè)務(wù)量越來(lái)越大，項(xiàng)目也越來(lái)越復(fù)雜，開(kāi)發(fā)團(tuán)隊(duì)人員也越來(lái)越多。這個(gè)時(shí)候還采用單體應(yīng)用，問(wèn)題就會(huì)很明顯了。下面挑選兩個(gè)最為常見(jiàn)的問(wèn)題來(lái)舉例：

• 協(xié)同問(wèn)題：多個(gè)人同時(shí)開(kāi)發(fā)一份代碼，在工作協(xié)同上就會(huì)經(jīng)常遇到代碼沖突問(wèn)題。

• 可用性問(wèn)題：因?yàn)槭菃误w應(yīng)用，即使改個(gè)最小的功能，也需要整體發(fā)布，不僅直接影響了線上可用性，還可能會(huì)對(duì)正常功能帶來(lái)風(fēng)險(xiǎn)。

為了解決這些問(wèn)題，大家就開(kāi)始考慮將「 單體應(yīng)用 」進(jìn)行拆分，進(jìn)行服務(wù)化部署。然后又隨著 Martin Fowler對(duì)「 微服務(wù) 」概念的提出，加上 DevOps 的流行，進(jìn)一步促進(jìn)了微服務(wù)的火熱發(fā)展。

「 微服務(wù) 」的理念提倡每個(gè)服務(wù)都是單一職責(zé)，且每一個(gè)服務(wù)都能實(shí)現(xiàn)自治，因此可以帶來(lái)一些明顯好處：

• 部署簡(jiǎn)單：每個(gè)微服務(wù)都可以獨(dú)立去部署，方便快捷。

• 邏輯清晰：將一個(gè)獨(dú)立功能邏輯封裝在單一微服務(wù)里面，實(shí)現(xiàn)整體項(xiàng)目的邏輯清晰。

• 可擴(kuò)展：因?yàn)榭梢噪S時(shí)增加和減少微服務(wù)，可以很方便的擴(kuò)展功能。

• 可靠性高：某一個(gè)功能的異常可以隔離在單一微服務(wù)里面，可以提高整體可靠性。

二、「 微服務(wù) 」的架構(gòu)是什么樣？

我們先來(lái)看一下「 微服務(wù) 」的架構(gòu)圖：

（圖片來(lái)源網(wǎng)絡(luò)，粉絲太少就懶得畫(huà)圖了，大家發(fā)揮一下想象力將就的看看，哈哈）

看起來(lái)挺復(fù)雜對(duì)不對(duì)，事實(shí)上也確實(shí)很復(fù)雜。

所以微服務(wù)并不是適用于所有項(xiàng)目、所有團(tuán)隊(duì)的。在應(yīng)用之前一定要搞清楚是否適合自己。

要保證這么一套微服務(wù)架構(gòu)能成功運(yùn)行起來(lái)，我們起碼需要以下這些?微服務(wù)的基礎(chǔ)組件：

• 服務(wù)注冊(cè)

  部署了一個(gè)微服務(wù)節(jié)點(diǎn)，得讓調(diào)用者知道啊，當(dāng)微服務(wù)節(jié)點(diǎn)有增加或減少的時(shí)候，也得讓調(diào)用者及時(shí)知曉啊。這些問(wèn)題都是通過(guò)“服務(wù)注冊(cè)”組件來(lái)實(shí)現(xiàn)的，服務(wù)提供者將自己的服務(wù)地址等信息登記到“服務(wù)注冊(cè)”組件中，調(diào)用者需要的時(shí)候，每次都先去查詢“服務(wù)注冊(cè)”即可。免去人工維護(hù)微服務(wù)節(jié)點(diǎn)的信息同步問(wèn)題。

• 服務(wù)網(wǎng)關(guān)

  是指提供給外部系統(tǒng)調(diào)用的是統(tǒng)一網(wǎng)關(guān)。主要做安全和權(quán)限控制等。

• 配置中心

  微服務(wù)的配置中心是用來(lái)統(tǒng)一管理所有微服務(wù)節(jié)點(diǎn)的配置信息的。因?yàn)橥粋€(gè)程序可能要適用于多個(gè)環(huán)境，所以在微服務(wù)實(shí)踐中要盡量做到程序與配置分離，將配置進(jìn)行集中管理。包括微服務(wù)節(jié)點(diǎn)信息、程序運(yùn)行時(shí)配置、變量配置、數(shù)據(jù)源配置、日志配置、版本配置等。

• 服務(wù)框架

  是指用來(lái)規(guī)范各個(gè)微服務(wù)節(jié)點(diǎn)之間通信標(biāo)準(zhǔn)的。服務(wù)間通信采用什么協(xié)議、數(shù)據(jù)是如何傳輸?shù)摹?shù)據(jù)格式是什么樣的。有了這個(gè)統(tǒng)一的“服務(wù)框架”就能保證各個(gè)微服務(wù)節(jié)點(diǎn)之間高效率的協(xié)同。

• 服務(wù)監(jiān)控

  微服務(wù)運(yùn)行起來(lái)之后，為了能夠監(jiān)控節(jié)點(diǎn)的健康情況，保障節(jié)點(diǎn)的高可行，需要對(duì)各個(gè)服務(wù)節(jié)點(diǎn)進(jìn)行收集數(shù)據(jù)指標(biāo)、然后對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)處理和分析，形成監(jiān)控報(bào)表和預(yù)警。

• 服務(wù)追蹤

  一旦使用了微服務(wù)架構(gòu)，那么當(dāng)有請(qǐng)求過(guò)來(lái)時(shí)，就會(huì)經(jīng)過(guò)多個(gè)微服務(wù)節(jié)點(diǎn)的處理，形成了一個(gè)調(diào)用鏈。為了進(jìn)行問(wèn)題追蹤和故障的定位，需要對(duì)請(qǐng)求的完整調(diào)用鏈進(jìn)行記錄。

  這里的服務(wù)追蹤與上面的服務(wù)監(jiān)控是不同維度的，一個(gè)是全局的，一個(gè)是微觀的，發(fā)揮的作用也不一樣。

• 服務(wù)治理

  就是指需要通過(guò)準(zhǔn)備一些策略和方案，來(lái)保障整個(gè)微服務(wù)架構(gòu)在生產(chǎn)環(huán)境遇到極端情況下也能正常提供服務(wù)的措施。比如 熔斷、限流、隔離等等。

當(dāng)然，上述只是一個(gè)微服務(wù)架構(gòu)最為核心的基礎(chǔ)組件，一旦微服務(wù)體系過(guò)大，例如有幾十上百個(gè)微服務(wù)節(jié)點(diǎn)，那么開(kāi)發(fā)、維護(hù)、測(cè)試的成本就會(huì)非常大。因此一般還會(huì)引入 自動(dòng)化部署 和 自動(dòng)化測(cè)試 來(lái)提高協(xié)同效率。

三、「 微服務(wù) 」入門(mén)如何避免踩坑？

你以為微服務(wù)架構(gòu)都是下面這樣的嗎？

事實(shí)上，更能是下面這樣的，哈哈。

（圖片來(lái)源網(wǎng)絡(luò)）

大家都在宣揚(yáng)「 微服務(wù) 」多么多么的好，例如：易擴(kuò)展、松耦合、服務(wù)簡(jiǎn)單、獨(dú)立開(kāi)發(fā)、易維護(hù)、輕量級(jí)等等。雖然這些優(yōu)勢(shì)也是事實(shí)，但是「 微服務(wù) 」帶來(lái)的問(wèn)題也很多，尤其是對(duì)于剛?cè)腴T(mén)的團(tuán)隊(duì)而言，應(yīng)用微服務(wù)后，趟坑真的可以趟到你崩潰。下面就普及一些常見(jiàn)的問(wèn)題來(lái)給大家打個(gè)預(yù)防針：

• 不是所有項(xiàng)目都適用微服務(wù)

  有些項(xiàng)目規(guī)模還比較小，或者項(xiàng)目才剛立項(xiàng)啟動(dòng)，也只有三四個(gè)人負(fù)責(zé)開(kāi)發(fā)維護(hù)，這時(shí)候是不建議一上來(lái)就搞微服務(wù)架構(gòu)的。這種情況下搞微服務(wù)，不僅是“殺雞用牛刀”，而且還無(wú)謂的增加了項(xiàng)目的復(fù)雜度，本身一個(gè)單體結(jié)構(gòu)就可以搞定的事情，非得拆分N多節(jié)點(diǎn)，人員又不足以支撐這么多節(jié)點(diǎn)的開(kāi)發(fā)維護(hù)，這完全是自找苦吃。反而是等項(xiàng)目成熟了、規(guī)模大了之后，再開(kāi)始慢慢將原有結(jié)構(gòu)拆為微服務(wù)才是正確的做法。

• 不要拆分過(guò)多過(guò)細(xì)的服務(wù)

  即使項(xiàng)目經(jīng)過(guò)評(píng)估后適合拆為微服務(wù)架構(gòu)，但也不要過(guò)度拆解。有的團(tuán)隊(duì)喜歡將項(xiàng)目拆成很細(xì)很細(xì)的顆粒，最后把項(xiàng)目搞的特別復(fù)雜，整個(gè)團(tuán)隊(duì)都陷進(jìn)去了。

  拆分服務(wù)的顆粒度應(yīng)該根據(jù)業(yè)務(wù)發(fā)展和團(tuán)隊(duì)現(xiàn)狀綜合去考慮。這里可以參考一個(gè)很火的理論「 康威定律 」。什么樣的團(tuán)隊(duì)，就產(chǎn)生什么樣的架構(gòu)，微服務(wù)拆分的顆粒度是需要和團(tuán)隊(duì)結(jié)構(gòu)相匹配的。當(dāng)你著手拆微服務(wù)的時(shí)候，得先評(píng)估一下團(tuán)隊(duì)人員和素質(zhì)，一般在開(kāi)發(fā)期，2-3個(gè)人開(kāi)發(fā)一個(gè)服務(wù)是合理的，在維護(hù)期，1個(gè)人維護(hù)2-3個(gè)服務(wù)也是合理的。

  如果拆分過(guò)細(xì)，開(kāi)發(fā)人員跟不上，會(huì)嚴(yán)重降低大家的工作效率。并且過(guò)細(xì)的服務(wù)，會(huì)導(dǎo)致一個(gè)請(qǐng)求的調(diào)用鏈條很長(zhǎng)，不僅會(huì)影響請(qǐng)求的響應(yīng)時(shí)間，也會(huì)對(duì)線上問(wèn)題排查帶來(lái)增加難度。

• 沒(méi)有DevOps就不要急于微服務(wù)

  一個(gè)穩(wěn)定的微服務(wù)架構(gòu)，是需要 持續(xù)集成、自動(dòng)化部署、自動(dòng)化測(cè)試、健全的監(jiān)控體系來(lái)保障的。如果團(tuán)隊(duì)還不具備DevOps，這些基礎(chǔ)的建設(shè)都沒(méi)有做好，一上來(lái)就搞微服務(wù)的話，就會(huì)導(dǎo)致實(shí)施過(guò)程中問(wèn)題百出，微服務(wù)的優(yōu)勢(shì)不能發(fā)揮。

以上，就是對(duì)架構(gòu)設(shè)計(jì)中「 微服務(wù)基礎(chǔ) 」的一些思考。

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計(jì)算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！

推薦閱讀：

• 屢試不爽的互聯(lián)網(wǎng)架構(gòu)三大馬車！
  

• 抖音微博等短視頻千萬(wàn)級(jí)高可用、高并發(fā)架構(gòu)如何設(shè)計(jì)？

• 20大5G關(guān)鍵技術(shù)

• Fast.ai：從零開(kāi)始學(xué)深度學(xué)習(xí) | 資源帖

• 10個(gè)簡(jiǎn)單小竅門(mén)帶你提高Python數(shù)據(jù)分析速度（附代碼）

• 程序員爬取 3 萬(wàn)條評(píng)論，《長(zhǎng)安十二時(shí)辰》槽點(diǎn)大揭秘！

• 暗網(wǎng)竟成比特幣最大用戶? 上半年5.15億美元被用于非法活動(dòng)
  

真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的架构设计之「 微服务入门 」的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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