大家好，歡迎來(lái)到萬(wàn)貓學(xué)社，跟我一起學(xué)，你也能成為微服務(wù)專(zhuān)家。
微服務(wù)架構(gòu)被技術(shù)大牛們總結(jié)出了以下九個(gè)特點(diǎn)：
- 服務(wù)組件化
- 圍繞業(yè)務(wù)功能
- 產(chǎn)品而不是項(xiàng)目
- 強(qiáng)終端弱管道
- 去中心化管理
- 去中心化數(shù)據(jù)管理
- 基礎(chǔ)設(shè)施自動(dòng)化
- 容錯(cuò)性設(shè)計(jì)
- 演進(jìn)式設(shè)計(jì)
下面我們來(lái)逐個(gè)詳細(xì)了解一下。
服務(wù)組件化
當(dāng)我們談到組件的時(shí)候，一般是指可以獨(dú)立替換、可以獨(dú)立升級(jí)的功能單元。在以往的架構(gòu)中，我們引入組件時(shí)，使用動(dòng)態(tài)鏈接庫(kù)或jar包，甚至是一組代碼。在微服務(wù)架構(gòu)中，是把服務(wù)作為了組件，使用輕量級(jí)的HTTP進(jìn)行遠(yuǎn)程調(diào)用。
這樣做有什么好處呢？動(dòng)態(tài)鏈接庫(kù)或jar包的引入是不安全的，可以使用反射等技術(shù)手段對(duì)模塊進(jìn)行修改。而在微服務(wù)中服務(wù)作為組件時(shí)，不在同一個(gè)線(xiàn)程中，根本不能對(duì)其進(jìn)行任何修改。
圍繞業(yè)務(wù)功能
在以往的單體架構(gòu)中，所有代碼、所有邏輯、所有模塊都集中在一個(gè)項(xiàng)目里。根據(jù)康威定理，技術(shù)團(tuán)隊(duì)的組織結(jié)構(gòu)應(yīng)該被分為：前端研發(fā)人員、后端研發(fā)人員、數(shù)據(jù)庫(kù)運(yùn)維人員，如下圖：
微服務(wù)是傾向于圍繞業(yè)務(wù)功能進(jìn)行服務(wù)的劃分的，所以每個(gè)服務(wù)的團(tuán)隊(duì)是跨職能的，可能包括所有職能的人員，如下圖：
這里隨便提一嘴康威定理，它是馬爾文·康威（Melvin Edward Conway）在1968年4月發(fā)表論文而提出的。
其核心論點(diǎn)是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。
通俗的來(lái)講：系統(tǒng)設(shè)計(jì)本質(zhì)上反映了企業(yè)的組織機(jī)構(gòu)，系統(tǒng)各個(gè)模塊間的接口也反映了企業(yè)各個(gè)部門(mén)之間的信息流動(dòng)和合作方式。
產(chǎn)品而不是項(xiàng)目
在一般情況下，項(xiàng)目是以交付為目的，當(dāng)項(xiàng)目完成以后就交付給甲方或者運(yùn)維團(tuán)隊(duì)，甚至該項(xiàng)目的開(kāi)發(fā)團(tuán)隊(duì)就此解散了。
而在微服務(wù)架構(gòu)中，產(chǎn)出的是產(chǎn)品。所謂的產(chǎn)品就是需要不斷演進(jìn)、不斷迭代，一個(gè)團(tuán)段負(fù)責(zé)產(chǎn)品的整個(gè)生命周期。
強(qiáng)終端弱管道
在SOA架構(gòu)中，使用了企業(yè)服務(wù)總線(xiàn)（ESB）這一強(qiáng)管道，因?yàn)槠髽I(yè)服務(wù)總線(xiàn)承擔(dān)了傳輸協(xié)議轉(zhuǎn)換、數(shù)據(jù)格式轉(zhuǎn)換、服務(wù)路由、監(jiān)控告警等多種功能。如下圖：
在微服務(wù)中，服務(wù)之間使用輕量級(jí)的HTTP進(jìn)行遠(yuǎn)程調(diào)用，也就是弱管道。而在服務(wù)自身內(nèi)部需要實(shí)現(xiàn)一些傳輸協(xié)議轉(zhuǎn)換、數(shù)據(jù)格式轉(zhuǎn)換等功能，也就是強(qiáng)終端。如下圖：
去中心化管理
在團(tuán)隊(duì)管理方面，微服務(wù)是去中心化的。負(fù)責(zé)每一個(gè)服務(wù)的團(tuán)隊(duì)一般都是自治的，包括開(kāi)發(fā)、測(cè)試、運(yùn)維和實(shí)施等各個(gè)方面，而不是傳統(tǒng)的集中式的管理。
去中心化數(shù)據(jù)管理
這個(gè)特點(diǎn)和上一個(gè)特點(diǎn)很類(lèi)似，它是在數(shù)據(jù)管理方面是去中心化的。在以往的單體架構(gòu)中，使用的是一個(gè)中心數(shù)據(jù)，如下圖;
在微服務(wù)架構(gòu)中，每個(gè)服務(wù)鏈接的數(shù)據(jù)庫(kù)是可以是不同的，甚至數(shù)據(jù)庫(kù)的類(lèi)型可以可以是不同的，如下圖：
基礎(chǔ)設(shè)施自動(dòng)化
一個(gè)單體系統(tǒng)可以十分方便地通過(guò)這些環(huán)境被構(gòu)建、測(cè)試和推送。
由于服務(wù)被拆分的粒度比較細(xì)，所以就會(huì)產(chǎn)生數(shù)量眾多的服務(wù)，使用自動(dòng)化的基礎(chǔ)設(shè)施是非常必要的。也就是我們經(jīng)常提及的CI/CD（Continuous Integration，持續(xù)集成，Continuous Delivery，持續(xù)交付）。
目前的DevOps實(shí)踐涉及軟件應(yīng)用程序在整個(gè)開(kāi)發(fā)生命周期內(nèi)的持續(xù)開(kāi)發(fā)、持續(xù)測(cè)試、持續(xù)集成、持續(xù)部署和持續(xù)監(jiān)控。
容錯(cuò)性設(shè)計(jì)
在數(shù)量眾多的服務(wù)之間進(jìn)行遠(yuǎn)程調(diào)用，難免會(huì)因?yàn)榈讓佑布蚓W(wǎng)絡(luò)的不可靠而造成失敗。所以在服務(wù)被設(shè)計(jì)時(shí)就能夠容忍錯(cuò)誤，比如：超時(shí)、重試、失效轉(zhuǎn)移、冪等性、熔斷、限流等機(jī)制。
演進(jìn)式設(shè)計(jì)
因?yàn)槊總€(gè)服務(wù)的獨(dú)立開(kāi)發(fā)、獨(dú)立部署的，所以對(duì)服務(wù)的變更、升級(jí)、替換就變得相對(duì)容易。
要對(duì)一個(gè)大型單體應(yīng)用進(jìn)行微服務(wù)轉(zhuǎn)型，肯定不是把這個(gè)大的單體應(yīng)用直接干掉，建一個(gè)新的微服務(wù)系統(tǒng)出來(lái)，而是要以增量的、非破壞的方式把某項(xiàng)業(yè)務(wù)一步步抽離形成新的服務(wù)。
更深入了解
以上是對(duì)微服務(wù)的九個(gè)特點(diǎn)通俗易懂的介紹，如果你不滿(mǎn)足于此，可以閱讀Microservices（https://martinfowler.com/articles/microservices.html）進(jìn)行更深入的了解。
