建站
咨詢
售后
建站咨詢
新聞中心
部署模式
創(chuàng)新互聯(lián)公司是一家專業(yè)從事成都做網(wǎng)站、網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計的品牌網(wǎng)絡(luò)公司。如今是成都地區(qū)具影響力的網(wǎng)站設(shè)計公司,作為專業(yè)的成都網(wǎng)站建設(shè)公司,創(chuàng)新互聯(lián)公司依托強大的技術(shù)實力、以及多年的網(wǎng)站運營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)及網(wǎng)站設(shè)計開發(fā)服務(wù)！
如何部署服務(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
斷路器
當(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)缺點：
- 獨立數(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ù)之間不必要的過多依賴。
不認(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ù)，似乎不是一個好的選擇，因為這樣的化就使得所有的服務(wù)依賴該數(shù)據(jù)服務(wù)。微服務(wù)更多應(yīng)該基于業(yè)務(wù)來設(shè)計，每個服務(wù)應(yīng)該自包含。
以下的架構(gòu)雖然是一種層級架構(gòu)，但也是可以采用的，條件是不同的服務(wù)不應(yīng)該共享數(shù)據(jù)。
依賴客戶簽核
當(dāng)服務(wù)有不同的客戶渠道來消費的時候，不應(yīng)該依賴客戶的簽核，自動化的測試應(yīng)該覆蓋所有的使用場景。
手工化的配置管理
應(yīng)該盡量避免手工化地配置管理，實現(xiàn)自動化
避免版本管理
在微服務(wù)中，如果你的系統(tǒng)只有一個版本，那么這肯定是有問題的。前向兼容是一個需要支持的目標(biāo)，也就是說不同的客戶端版本不應(yīng)該收到服務(wù)升級的影響。這也就意味這API一旦發(fā)布，就不應(yīng)該有不兼容的修改。
為每一個服務(wù)創(chuàng)建網(wǎng)關(guān)
這個就不用多說了，看著就很傻
參考
- microservices.io/patter
- infoq.com/articles/seve
網(wǎng)頁標(biāo)題：告別爛代碼，一文理解微服務(wù)中的模式和反模式
標(biāo)題鏈接：http://www.5511xx.com/article/dhhihhd.html
