告別爛代碼，一文理解微服務(wù)中的模式和反模式

作者：剛是程序員 2019-11-07 15:07:30

開發(fā) 架構(gòu)

如何部署服務(wù)是微服務(wù)中的一個重要問題，微服務(wù)的部署方式非常靈活，有以下的不同選項(xiàng)可供選擇 (參考 open-open.com/lib/view/)。

[[281615]]

部署模式

如何部署服務(wù)是微服務(wù)中的一個重要問題，微服務(wù)的部署方式非常靈活，有以下的不同選項(xiàng)可供選擇 (參考 open-open.com/lib/view/)

多服務(wù)共享主機(jī)/虛機(jī)

單服務(wù)部署單一主機(jī)/虛機(jī)

單服務(wù)部署單一容器(Docker)

無服務(wù)部署(serverless)，例如AWS Lambda

使用服務(wù)部署平臺 (Kubernetes，Docker Swarm，Mesos， AWS ECS)

不同的部署方式各有優(yōu)缺點(diǎn)，重點(diǎn)推薦使用容器編排系統(tǒng)的服務(wù)部署平臺，能夠提供各種靈活的部署方案。

橫向關(guān)注點(diǎn)

微服務(wù)的開發(fā)過程中常常會花很多時間來處理一些各個服務(wù)都會遇到的問題，例如

如何管理配置信息，例如用戶名和口令，服務(wù)器的網(wǎng)絡(luò)地址，等等
日志管理
健康檢查
業(yè)務(wù)度量數(shù)據(jù)(Metrics)的收集和分析
分布服務(wù)的追蹤
這里推薦使用一個穩(wěn)定的微服務(wù)框架來處理這些問題，例如基于Java的spring boot，基于Golang的Micro等

API網(wǎng)關(guān)

API網(wǎng)關(guān)類似服務(wù)代理，所有的客戶端都通過API網(wǎng)關(guān)提供的統(tǒng)一服務(wù)API來消費(fèi)服務(wù)內(nèi)容。

下面是幾個開源的API Gateway

Kong ( github.com/Mashape/kong )
APIAxle ( http://apiaxle.com/ )
Tyk ( tyk.io/ )
apiGrove ( http://apigrove.net/ )
WSO2 API Manager ( http://wso2.com/products/api-manager/ )

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)是指API網(wǎng)關(guān)或者客戶端如何獲得微服務(wù)的地址，主要有以下幾種發(fā)現(xiàn)方式：

客戶端發(fā)現(xiàn)

服務(wù)器端發(fā)現(xiàn)

這種方案中的Router可以并入API網(wǎng)關(guān)，客戶端直接和網(wǎng)關(guān)通信。

兩種方案需要用到服務(wù)注冊，，區(qū)別在于是否把服務(wù)注冊直接暴露給客戶端使用。常見的提供服務(wù)發(fā)現(xiàn)的注冊開源解決方案有：

Apache Zookeeper
Consul
Etcd

斷路器

當(dāng)微服務(wù)系統(tǒng)中的某個服務(wù)出現(xiàn)問題的時候，或者網(wǎng)絡(luò)出現(xiàn)時延的時候，調(diào)用客戶端會被阻塞，導(dǎo)致大量的調(diào)用占用大量的資源。這時候需要引入類似斷路器效果的代理，當(dāng)出現(xiàn)不健康的服務(wù)的時候，斷路器會返回出錯，阻止更多的客戶端掉用，直至服務(wù)的健康狀態(tài)恢復(fù)。

netflix的hystrix提供了類似的服務(wù) github.com/Netflix/Hyst

數(shù)據(jù)管理

在設(shè)計微服務(wù)的時候要考慮是否每一個服務(wù)擁有自己的數(shù)據(jù)庫或者是共享數(shù)據(jù)庫

每個服務(wù)擁有自己的數(shù)據(jù)庫
共享數(shù)據(jù)庫

這兩種方式各有優(yōu)缺點(diǎn)：

獨(dú)立數(shù)據(jù)庫使得各個服務(wù)完全解耦合，并且可以根據(jù)需要選用不同種類的數(shù)據(jù)庫，但是沒有辦法或者很難在服務(wù)之間共享數(shù)據(jù)
共享數(shù)據(jù)庫能簡化維護(hù)和技術(shù)棧，但是數(shù)據(jù)庫成為所有服務(wù)的依賴，系統(tǒng)更多的耦合，帶來了不靈活，沒有辦法根據(jù)業(yè)務(wù)需要選擇不同的數(shù)據(jù)庫種類。

微服務(wù)中的反模式

相對于《設(shè)計模式》，《反模式》一書可能知道的相對少一點(diǎn)，其實(shí)同樣的道理，反模式歸納總結(jié)了一些常見的容易犯的設(shè)計問題，那么，微服務(wù)中有哪些反模式呢?

聚合混亂

軟件設(shè)計的一個主要思想“高內(nèi)聚，低耦合”同樣適用于微服務(wù)，隨著系統(tǒng)的發(fā)展，應(yīng)該避免某一個服務(wù)變的一場龐大，或者服務(wù)之間不必要的過多依賴。

不認(rèn)真對待自動化

持續(xù)集成和交付和微服務(wù)相輔相成，自動化的測試，集成，交付和部署是微服務(wù)成敗的關(guān)鍵。一個自動化程度不高的微服務(wù)是很難成功的。

層級的軟件架構(gòu)

在設(shè)計微服務(wù)的時候，應(yīng)該盡可能避免分層的架構(gòu)，服務(wù)之間更多應(yīng)該是流式調(diào)用。例如為所有的服務(wù)提供一個數(shù)據(jù)接入層的數(shù)據(jù)服務(wù)，似乎不是一個好的選擇，因?yàn)檫@樣的化就使得所有的服務(wù)依賴該數(shù)據(jù)服務(wù)。微服務(wù)更多應(yīng)該基于業(yè)務(wù)來設(shè)計，每個服務(wù)應(yīng)該自包含。

以下的架構(gòu)雖然是一種層級架構(gòu)，但也是可以采用的，條件是不同的服務(wù)不應(yīng)該共享數(shù)據(jù)。