[[281615]]

部署模式

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

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

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

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

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

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

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

橫向關(guā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來消費服務(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

斷路器

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

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

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

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

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

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

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

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

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

聚合混亂

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

不認真對待自動化

持續(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ù)，似乎不是一個好的選擇，因為這樣的化就使得所有的服務(wù)依賴該數(shù)據(jù)服務(wù)。微服務(wù)更多應(yīng)該基于業(yè)務(wù)來設(shè)計，每個服務(wù)應(yīng)該自包含。

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

依賴客戶簽核

當服務(wù)有不同的客戶渠道來消費的時候，不應(yīng)該依賴客戶的簽核，自動化的測試應(yīng)該覆蓋所有的使用場景。

手工化的配置管理

應(yīng)該盡量避免手工化地配置管理，實現(xiàn)自動化

避免版本管理

在微服務(wù)中，如果你的系統(tǒng)只有一個版本，那么這肯定是有問題的。前向兼容是一個需要支持的目標，也就是說不同的客戶端版本不應(yīng)該收到服務(wù)升級的影響。這也就意味這API一旦發(fā)布，就不應(yīng)該有不兼容的修改。

為每一個服務(wù)創(chuàng)建網(wǎng)關(guān)

這個就不用多說了，看著就很傻

參考

• microservices.io/patter
• infoq.com/articles/seve