小編的話

“品高公開(kāi)課”系列文章意在分享技術(shù)牛人的知識(shí)干貨，每期主題都不一樣喲！期待各位讀者在文后發(fā)表留言，來(lái)一場(chǎng)技術(shù)上的交流和思想上的碰撞！

微服務(wù)以一種全新的架構(gòu)設(shè)計(jì)模式，牽動(dòng)了互聯(lián)網(wǎng)應(yīng)用從設(shè)計(jì)到運(yùn)維整個(gè)流程方法論的變革。 而以Docker為代表的容器技術(shù)則為微服務(wù)理念提供了匹配的實(shí)現(xiàn)機(jī)制。本周五，將由品高軟件工程師陳洪杰帶講述微服務(wù)架構(gòu)的故事。

分享嘉賓

陳洪杰，目前就任品高廣州云架構(gòu)產(chǎn)品部--BingoCloud平臺(tái)的軟件開(kāi)發(fā)工程師，擁有Docker，LXC等多個(gè)容器平臺(tái)的項(xiàng)目經(jīng)驗(yàn)，15年開(kāi)始轉(zhuǎn)向彈性容器服務(wù)（ECS)的研究，主要負(fù)責(zé)彈性容器服務(wù)的規(guī)劃、設(shè)計(jì)和開(kāi)發(fā)。

分享正文

▼

隨著市場(chǎng)的快速發(fā)展，業(yè)務(wù)的不斷擴(kuò)大，傳統(tǒng)的單體應(yīng)用架構(gòu)面臨著越來(lái)越多的挑戰(zhàn)。微服務(wù)架構(gòu)(Microservices Architecture)的誕生，對(duì)軟件架構(gòu)領(lǐng)域所帶來(lái)的影響毋庸置疑。

為什么微服務(wù)架構(gòu)比單體應(yīng)用架構(gòu)，在研發(fā)過(guò)程中更加敏捷和靈活呢？先從單體應(yīng)用的架構(gòu)說(shuō)起。下圖是一個(gè)比較經(jīng)典的單體應(yīng)用架構(gòu)，來(lái)自Chris Richardson的《微服務(wù)系列》：

比較經(jīng)典的單體應(yīng)用架構(gòu)

上圖表示一款與滴滴或者Uber競(jìng)爭(zhēng)的打車軟件，這款新應(yīng)用采用了傳統(tǒng)的六邊形架構(gòu)模式。根據(jù)不同的功能需求，分成了多個(gè)不同的模塊。各個(gè)模塊之間直接通過(guò)API調(diào)用，互相協(xié)同工作。

由于IDE擅長(zhǎng)構(gòu)建單體應(yīng)用，采用這種架構(gòu)的應(yīng)用非常普遍。這類應(yīng)用也可以很輕松下斷點(diǎn)測(cè)試。單體應(yīng)用也便于部署，只需將軟件包復(fù)制到服務(wù)器，簡(jiǎn)單配置后即可良好運(yùn)行。在項(xiàng)目早期這么做非常有效。

但當(dāng)幾年過(guò)去了，隨著功能的擴(kuò)展，項(xiàng)目就變得臃腫，不夠靈活。同時(shí)，開(kāi)發(fā)者必須對(duì)整個(gè)應(yīng)用的架構(gòu)和模塊，有一定程度的了解，才可能對(duì)它進(jìn)行修改。而且項(xiàng)目可靠性差，難以持續(xù)開(kāi)發(fā)、部署，擴(kuò)展困難。

典型的打車軟件微服務(wù)架構(gòu)圖

不同于單體應(yīng)用，微服務(wù)架構(gòu)將各個(gè)功能模塊拆分成獨(dú)立的服務(wù)，服務(wù)與服務(wù)之間通過(guò)REST API交流。不同的服務(wù)有自己的功能、數(shù)據(jù)庫(kù)和REST API。

這種微服務(wù)架構(gòu)有什么特點(diǎn)呢？

1. 業(yè)務(wù)功能驅(qū)動(dòng)設(shè)計(jì)：不同的功能做成不同的服務(wù)，例如根據(jù)用戶界面、用戶管理、司機(jī)界面、司機(jī)管理、賬單管理、賬單支付等不同的功能，做成不同的服務(wù)；

2. 單一職責(zé)原則：每一個(gè)服務(wù)，它的功能應(yīng)該都是單一的，如果有多個(gè)功能，則做成多個(gè)服務(wù)為宜，例如用戶界面和用戶管理就分成單獨(dú)的服務(wù)；

3. 明確發(fā)布接口：接口一旦發(fā)布了，就不要輕易更改，因?yàn)楦牧撕芸赡軙?huì)導(dǎo)致所有服務(wù)都要進(jìn)行相應(yīng)的更改，服務(wù)的消費(fèi)者也只需要關(guān)心接口，無(wú)需關(guān)心服務(wù)的內(nèi)部實(shí)現(xiàn)；

4. 輕量級(jí)通信：服務(wù)與服務(wù)之間，通過(guò)簡(jiǎn)單的、輕量級(jí)的通訊協(xié)議交流即可，例如，同步的REST，異步的AMQP、STOMP、MQTT等；

5. 可以異構(gòu)/采用多種語(yǔ)言棧：每個(gè)服務(wù)的實(shí)現(xiàn)細(xì)節(jié)都與其它服務(wù)無(wú)關(guān)，這使得服務(wù)之間能夠解耦，團(tuán)隊(duì)可以針對(duì)每個(gè)服務(wù)選擇最合適的開(kāi)發(fā)語(yǔ)言、持久化存儲(chǔ)、工具和方法；

6. 獨(dú)立部署、升級(jí)、擴(kuò)展和替換：每個(gè)服務(wù)都可以單獨(dú)部署及重新部署而不影響整個(gè)系統(tǒng)。這使得服務(wù)很容易升級(jí)，擴(kuò)展和替換；

對(duì)應(yīng)的，微服務(wù)架構(gòu)有如下的優(yōu)點(diǎn)：

1. 復(fù)雜度可控，易于開(kāi)發(fā)、理解和維護(hù)；

2. 局部修改很容易部署，有利于持續(xù)集成和持續(xù)交付；

3. 故障隔離，一個(gè)服務(wù)出現(xiàn)問(wèn)題不會(huì)影響整個(gè)應(yīng)用；

4. 彈性伸縮、擴(kuò)展方便，根據(jù)需求分配不同的資源；

5. 技術(shù)選型靈活，可以根據(jù)需求選擇合適的技術(shù)；

同時(shí)，微服務(wù)架構(gòu)也有著它的缺點(diǎn)：

1. 數(shù)據(jù)一致性難以保證；

2. 分布式調(diào)用造成的性能、延遲和可靠性問(wèn)題；

3. 不同服務(wù)之間的依賴問(wèn)題，導(dǎo)致復(fù)雜度增加；

4. 部署復(fù)雜，配置、部署、擴(kuò)展和監(jiān)控難度大；

目前，很多服務(wù)都是單體應(yīng)用架構(gòu)，這些老的應(yīng)用該如何過(guò)渡到微服務(wù)架構(gòu)呢？一般來(lái)說(shuō)，都是采取以下的方式：

1. 為新功能特性創(chuàng)建微服務(wù)，原有的單體應(yīng)用保持不變或僅做必要的修改；

2. 根據(jù)業(yè)務(wù)功能各自剝離為微服務(wù)；

3. 按照業(yè)務(wù)功能價(jià)值和需要安排優(yōu)先級(jí)；

4. 不追求完全消滅單體應(yīng)用；

Docker的誕生

在單體應(yīng)用越來(lái)越難以滿足人們需要的時(shí)候，Docker誕生了。作為一個(gè)在最近這幾年異軍突起的技術(shù)，仿佛就是為了微服務(wù)架構(gòu)而生。每個(gè)Docker容器，只運(yùn)行一個(gè)微服務(wù)。從此，開(kāi)發(fā)人員擺脫了單體應(yīng)用架構(gòu)帶來(lái)的負(fù)擔(dān)，使每天都更新線上項(xiàng)目不再是一個(gè)夢(mèng)想。

Docker容器，是類似JVM但比其更強(qiáng)大的容器，基于Linux內(nèi)核。支持各種語(yǔ)言。它比VM虛擬機(jī)更加輕量，能夠在云計(jì)算IaaS等平臺(tái)上直接運(yùn)行，使用戶的應(yīng)用無(wú)縫地移植到各種運(yùn)行環(huán)境。

一般來(lái)說(shuō)，Docker容器服務(wù)也叫彈性容器服務(wù)（ECS），或者容器云。在Docker越來(lái)越火的今天，在國(guó)內(nèi)外都有很多提供彈性容器服務(wù)的提供商。例如國(guó)外的亞馬遜、Tutum云和CoreOS，國(guó)內(nèi)的DaoCloud、網(wǎng)易蜂巢、時(shí)速云和靈雀云等等。

如果要使用彈性容器服務(wù)，則必須從開(kāi)發(fā)階段開(kāi)始，以微服務(wù)架構(gòu)的形式開(kāi)發(fā)應(yīng)用，或者對(duì)現(xiàn)有的單體應(yīng)用進(jìn)行解耦。

開(kāi)發(fā)、測(cè)試、部署流程示意圖

開(kāi)發(fā)、測(cè)試、部署流程簡(jiǎn)介：

1. 運(yùn)維人員在ECS上搭建私有Docker Registry；

2. 開(kāi)發(fā)人員在開(kāi)發(fā)ECS上從DockerHub或私有DockerRegistry獲取應(yīng)用需要的基礎(chǔ)鏡像；

3. 開(kāi)發(fā)人員開(kāi)發(fā)ECS上構(gòu)造應(yīng)用容器，自測(cè)后提交容器為新的鏡像并推送到私有Docker Registry，通知QA測(cè)試；

4. QA在自己的測(cè)試ECS上啟動(dòng)容器，測(cè)試后，有問(wèn)題則a，沒(méi)問(wèn)題則b：

a. 通知開(kāi)發(fā)修復(fù)，回到步驟3；

b. 提交到私有Docker Registry，準(zhǔn)備發(fā)布；

5. 發(fā)布人員下載最新版本鏡像并在生產(chǎn)ECS上啟動(dòng)容器。

最后再說(shuō)一下，Docker彈性容器服務(wù)的關(guān)鍵點(diǎn)：

1.服務(wù)注冊(cè)、發(fā)現(xiàn)：容器很容易創(chuàng)建，也非常容易被銷毀，新創(chuàng)建的容器需要能夠自動(dòng)注冊(cè)，并被其它服務(wù)發(fā)現(xiàn)。

2. 跨主機(jī)網(wǎng)絡(luò)：容器只會(huì)暴露必要的端口，不同物理主機(jī)之間的容器服務(wù)交換數(shù)據(jù)，一般都是通過(guò)單獨(dú)的、私有的網(wǎng)絡(luò)進(jìn)行交互。

3. 存儲(chǔ)服務(wù)：容器是無(wú)狀態(tài)的，即容器是不能，也不必要保存任何的數(shù)據(jù)，所以一般都是通過(guò)網(wǎng)絡(luò)儲(chǔ)存服務(wù)，例如S3，進(jìn)行數(shù)據(jù)存儲(chǔ)。

4. 健康檢查：一般的微服務(wù)架構(gòu)應(yīng)用，會(huì)運(yùn)行很多個(gè)容器，對(duì)這些容器的狀態(tài)進(jìn)行健康檢查是很有必要的。不健康的容器會(huì)被銷毀，然后再啟動(dòng)一個(gè)新的容器替代。

5. 自動(dòng)彈性伸縮：時(shí)刻檢測(cè)容器的資源情況，當(dāng)某個(gè)服務(wù)訪問(wèn)量增大，資源消耗增多時(shí)，可能導(dǎo)致服務(wù)無(wú)法訪問(wèn)時(shí)，可以自動(dòng)增加同一個(gè)服務(wù)的容器，達(dá)到動(dòng)態(tài)平衡。

6. 監(jiān)控日志：容器隨時(shí)可能因?yàn)槌鲥e(cuò)而被銷毀，銷毀后無(wú)法像普通虛擬機(jī)那樣查看日志，所以一個(gè)良好的日志收集是必須的。

7. 資源隔離：目前容器的隔離性還無(wú)法做到普通VM那樣的程度，所以在彈性容器服務(wù)里，一般會(huì)把容器跑在VM里，盡管性能和直接跑在物理機(jī)上沒(méi)法比，但容器還是擁有啟動(dòng)快，開(kāi)銷小的特點(diǎn)。

8. 灰度升級(jí)：當(dāng)應(yīng)用上線后，服務(wù)是無(wú)法同時(shí)全部關(guān)機(jī)更新的。而灰度更新，可以逐步分批更新服務(wù)，達(dá)到無(wú)縫更新的效果。

9. 私有倉(cāng)庫(kù)：對(duì)企業(yè)來(lái)說(shuō)，應(yīng)用的鏡像保存在私有的倉(cāng)庫(kù)中更適合，而不是分享到Docker官方源，同時(shí)私有倉(cāng)庫(kù)可以搭建在內(nèi)網(wǎng)，速度快。

歡迎大家和我們一起交流！

你想和更多志同道合的技術(shù)大咖一起交流嗎？！你想收聽(tīng)每周的“品高微信群公開(kāi)課”的直播嗎？！加入我們“漫步云端 微信群”吧！

掃描下面二維碼添加“品高云珍珠妹”為好友，輸入“我要入群！”的暗號(hào)，即可得到入群指引噢~