[[281615]]

部署模式

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

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

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

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

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

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

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

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

微服務(wù)的開(kāi)發(fā)過(guò)程中常常會(huì)花很多時(shí)間來(lái)處理一些各個(gè)服務(wù)都會(huì)遇到的問(wèn)題，例如

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

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

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

下面是幾個(gè)開(kā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)或者客戶(hù)端如何獲得微服務(wù)的地址，主要有以下幾種發(fā)現(xiàn)方式：

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

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

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

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

• Apache Zookeeper
• Consul
• Etcd

斷路器

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

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

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

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

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

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

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

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

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

聚合混亂

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

不認(rèn)真對(duì)待自動(dòng)化

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

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

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

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

依賴(lài)客戶(hù)簽核

當(dāng)服務(wù)有不同的客戶(hù)渠道來(lái)消費(fèi)的時(shí)候，不應(yīng)該依賴(lài)客戶(hù)的簽核，自動(dòng)化的測(cè)試應(yīng)該覆蓋所有的使用場(chǎng)景。

手工化的配置管理

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

避免版本管理

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

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

這個(gè)就不用多說(shuō)了，看著就很傻

參考

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