部署模式

創(chuàng)新互聯(lián)公司是一家專業(yè)從事成都做網(wǎng)站、網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)的品牌網(wǎng)絡(luò)公司。如今是成都地區(qū)具影響力的網(wǎng)站設(shè)計(jì)公司,作為專業(yè)的成都網(wǎng)站建設(shè)公司,創(chuàng)新互聯(lián)公司依托強(qiáng)大的技術(shù)實(shí)力、以及多年的網(wǎng)站運(yùn)營經(jīng)驗(yàn),為您提供專業(yè)的成都網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)及網(wǎng)站設(shè)計(jì)開發(fā)服務(wù)！

如何部署服務(wù)是微服務(wù)中的一個(gè)重要問題，微服務(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ā)過程中常常會花很多時(shí)間來處理一些各個(gè)服務(wù)都會遇到的問題，例如

• 如何管理配置信息，例如用戶名和口令，服務(wù)器的網(wǎng)絡(luò)地址，等等
• 日志管理
• 健康檢查
• 業(yè)務(wù)度量數(shù)據(jù)(Metrics)的收集和分析
• 分布服務(wù)的追蹤
• 這里推薦使用一個(gè)穩(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)容。

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

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

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

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

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

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

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

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

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

聚合混亂

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

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

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

層級的軟件架構(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ù)依賴該數(shù)據(jù)服務(wù)。微服務(wù)更多應(yīng)該基于業(yè)務(wù)來設(shè)計(jì)，每個(gè)服務(wù)應(yīng)該自包含。

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

依賴客戶簽核

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

手工化的配置管理

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

避免版本管理

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

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

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

參考

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

分享文章：告別爛代碼，一文理解微服務(wù)中的模式和反模式
本文地址：http://uogjgqi.cn/article/dhhihhd.html