9月10日在K8S GeekGathering Meetup上，數(shù)人云架構(gòu)師保珠做了關(guān)于《K8S&mesos之我見》的主題分享，分別介紹了Kubernetes和Mesos對微服務(wù)的支撐，以下是本次分享的實錄——

本次主要分享主要有以下五個方面：

• 容器的價值
• 微服務(wù)體系建設(shè)
• Kubernetes對微服務(wù)的支撐
• Mesos對微服務(wù)的支撐
• 總結(jié)

關(guān)于容器大家可能已經(jīng)理解或者正在實踐使用，所以今天會講一下容器的價值方面內(nèi)容，然后是目前比較火的微服務(wù)相關(guān)：將單體應(yīng)用解構(gòu)成微服務(wù)后它到底是一個怎樣的概念，而后是Kubernetes和Mesos在微服務(wù)方面的支撐，最后是基于以上做一個總結(jié)。

容器的價值

Markdown

首先來思考一些問題：

• Docker現(xiàn)在已經(jīng)是容器界的事實標(biāo)準(zhǔn)，原因是什么？
• Docker和VM各自都有什么優(yōu)勢？

2013年，Docker就已經(jīng)在國內(nèi)進(jìn)行發(fā)展，2015年本人首次接觸Docker是在客戶現(xiàn)場進(jìn)行生產(chǎn)應(yīng)用部署，后來在和客戶分享交流中，被問及的比較多的一點是Docker和VM究竟有什么區(qū)別，以及各自的價值是什么？Docker如此之火，難道就是因為輕量化、隔離性安全性以及秒級啟動這些原因嗎？這些特性VM也可以通過變通的方式做到，那么Docker的價值到底是什么？

請帶著這些問題，繼續(xù)往下看。

微服務(wù)體系建設(shè)

Markdown

試想下，目前比較火的微服務(wù)是不是和Docker或者說容器的經(jīng)歷很相似？為什么現(xiàn)在大家要用微服務(wù)，它都為我們帶來了什么？單體應(yīng)用時用的MVC架構(gòu)，金融業(yè)會把應(yīng)用切分成七層，接入層、服務(wù)層等等，微服務(wù)是否還要按照這種分層架構(gòu)，用了它到底是簡單了，還是復(fù)雜了，是不是用了Spring Cloud、Dubbo即是微服務(wù)了？

隨著應(yīng)用規(guī)模的膨脹導(dǎo)致運維規(guī)模線性增長，如何解決：有了微服務(wù)的概念后，應(yīng)用可以按照業(yè)務(wù)模塊做切分，做了微服務(wù)化切割夠，一個小團(tuán)隊去管理開發(fā)一個服務(wù)，但隨之而來的問題是，以前10個系統(tǒng)，5個運維就可以完成任務(wù)，使用微服務(wù)后可能會變成每個系統(tǒng)有幾十個服務(wù)，部署的復(fù)雜度、團(tuán)隊之間的溝通協(xié)調(diào)、線上問題追蹤，版本控制這些問題需要一些解決辦法。

微服務(wù)的所有服務(wù)之間都是平等的關(guān)系，每個服務(wù)內(nèi)部還可以遵循之前的分層架構(gòu)。

當(dāng)把系統(tǒng)做了模塊化切分后，用Spring Cloud或者Dubbo框架去構(gòu)建系統(tǒng)，雖然感覺上這就屬于微服務(wù)的范疇，但隨著對于這個體系的了解，其實會發(fā)現(xiàn)還遠(yuǎn)遠(yuǎn)不夠。

〓 微服務(wù)體系建設(shè)

Markdown

為什么說微服務(wù)不是一個簡單的框架而是一個體系，因為一個框架并不能解決微服務(wù)給我們帶來的所有問題，如前面所提到的，其實還有很多，下面是在項目中遇到的一些體系方面建設(shè)的羅列，供以參考：

服務(wù)化框架：要解決的是服務(wù)之間調(diào)用的多通訊協(xié)議支持，數(shù)據(jù)交互的數(shù)據(jù)結(jié)構(gòu)支持。

服務(wù)注冊和發(fā)現(xiàn)：完成服務(wù)切分后，服務(wù)之間完成解耦，通過服務(wù)注冊中心對服務(wù)統(tǒng)一管理，調(diào)用端去調(diào)用。

統(tǒng)一配置管理：不同環(huán)境如開發(fā)、生產(chǎn)、測試等環(huán)境的配置肯定不同，如果沒有做出相應(yīng)的改變，那么后續(xù)帶來的修改以及升級問題是不可想象的。

API網(wǎng)關(guān)：服務(wù)被拉平后，身份驗證、監(jiān)控、負(fù)載均衡、緩存、請求分片與管理、靜態(tài)相應(yīng)處理。

監(jiān)控報警：監(jiān)控報警之所以重要的原因是因為之前做系統(tǒng)時，覺得開發(fā)測試完成后即可上線，但在金融行業(yè)并不如此，監(jiān)控通過提高發(fā)現(xiàn)問題的時效性，更早更快地發(fā)現(xiàn)問題，從而保證系統(tǒng)穩(wěn)定性。

文檔管理：不同服務(wù)做切分后，按直接溝通模式，團(tuán)隊間的溝通成本會很高，若切分了四五個服務(wù)還好，都互相知道，但切分了幾十個甚至上百個服務(wù)，所開發(fā)的服務(wù)可能都不知道水在調(diào)用，因此需要通過契約管理接口，通過文檔管理將自己的API開放在一個通用的團(tuán)里平臺上，如Swagger，方便調(diào)用查閱。

任務(wù)調(diào)度系統(tǒng)：在系統(tǒng)當(dāng)中，除了在線實時交易通過服務(wù)之間的調(diào)用去做，還有一些金融行業(yè)里面跑批的任務(wù)，比如日切，凌晨2點要統(tǒng)一跑批，需要任務(wù)調(diào)度系統(tǒng)去執(zhí)行，若用其他系統(tǒng)，隨著服務(wù)的膨脹，機(jī)器主機(jī)數(shù)量增加，后續(xù)的管理會產(chǎn)生很大問題。

風(fēng)控平臺：如果有接口是開放的API要被外部調(diào)用，不止是在防火墻內(nèi)部調(diào)用，此時如果有人進(jìn)行攻擊，此系統(tǒng)可以幫助保持穩(wěn)定性。

測試平臺：更多是把微服的整個系統(tǒng)：包括接口測試、單元測試、以及性能測試都在一個平臺統(tǒng)一做好，目的是縮短微服務(wù)的發(fā)布周期，后續(xù)做持續(xù)集成時，才能提高交付效率和時間，更加敏捷。

持續(xù)集成/發(fā)布：用了微服務(wù)后，通常都會采取敏捷的方法，比如兩周、四周做簡單迭代，中間的版本也非常多，每個版本的發(fā)布都必不可少要做一次回歸測試，工作量比較大，如果仍然由人工進(jìn)行，會很艱難。

通過以上對于微服務(wù)體系進(jìn)行了一些簡單的理解之后，現(xiàn)在就可以反過來回答前文中所提到的容器（Docker）價值問題——

Docker和VM的區(qū)別，結(jié)合微服務(wù)在做持續(xù)集成/發(fā)布時，Docker更具有優(yōu)勢，但這也并不是說有了Docker就沒必要再去采用VM，到底是將Docker部署在主機(jī)上還是部署在VM里，其實沒有一定的答案，它們各有千秋，需要根據(jù)自身的實際情況去把控。

Kubernetes對微服務(wù)的支撐

Markdown

〓 編排

單體應(yīng)用微服務(wù)化以后，服務(wù)之間必然會有依賴關(guān)系，在發(fā)布時，若每個服務(wù)都單獨啟動會非常痛苦，簡單地說包括一些登錄服務(wù)、支付服務(wù)，若想一次全部啟動，此時必不可少要用到編排的動作，這里有一個子項目：Kompose將Docker Compose編排文件無痛發(fā)布到Kubernetes上，這是個簡單的Docker Compose文件，發(fā)布到一個Dedis集群，一個前端。執(zhí)行kompose convert –f docker-compose.yaml即可。

Markdown

〓 資源調(diào)度

調(diào)度是編排工具的核心，上圖可以看到Kuberenetes在調(diào)度方面的框架：

1. 用戶通過Kuberctl提交運行Docker Container（Pod）的請求
2. Api Server把請求存儲在Etcd
3. Scheduler掃描，分配資源
4. Kubelet得到調(diào)度要執(zhí)行的任務(wù)，并在本機(jī)執(zhí)行生成容器（Pod）

后面會對比一下Mesos的調(diào)度實現(xiàn)。

Markdown

〓 Statefulset

之前和客戶提到微服時，都會說到應(yīng)用微服務(wù)化以后，如何遷移上云的問題，這是很重要的動作，一般會給出的相應(yīng)的建議：首先要將所有應(yīng)用無狀態(tài)化，規(guī)范這樣的要求是因為服務(wù)狀態(tài)有坑在其中。

Kubernetes的Statefulset可以發(fā)布有狀態(tài)服務(wù)，需要滿足以下要求：

• Pod的存儲必須通過Persistentvolume Provisioner基于Storeage提供
• 由Headless Service生成Pods的唯一網(wǎng)絡(luò)標(biāo)識
• Statefulset的升級是一個手動的過程

總體來說，它為了實現(xiàn)有狀態(tài)的服務(wù)在這些前提下，還會有一些復(fù)雜性在其中。

之前有人提問數(shù)據(jù)庫跑在容器里還是用主機(jī)服務(wù)，包括數(shù)據(jù)庫里的分庫，都不是容器所關(guān)注的問題，建議數(shù)據(jù)庫服務(wù)先不做容器化，因為數(shù)據(jù)庫層面，更多是對IO的分流，在它的查詢，索引都是IP請求比較多。分庫分表，分布式事務(wù)是在應(yīng)用層面解決的，同樣也不是容器所關(guān)注的，Docker接觸的更為底層，因為是一個OS。

Markdown

〓 服務(wù)發(fā)現(xiàn)

關(guān)于服務(wù)發(fā)現(xiàn)，上面提到微服務(wù)后，服務(wù)數(shù)量劇增，端到端的模式已不再適用，此時就需要做服務(wù)發(fā)現(xiàn)，有了服務(wù)發(fā)現(xiàn)和負(fù)載均衡，它可以把服務(wù)之間做一個解耦，可以提升升級方面的相關(guān)問題。

Kubernetes的服務(wù)發(fā)現(xiàn)有兩種模式：

第一種：通過環(huán)境變量的方式，Pod創(chuàng)建是在環(huán)境變量中寫入Serviceip和Port。

第二種：DNS，Kubernetes集群內(nèi)置DNS服務(wù)器，Service創(chuàng)建成功后會在DNS服務(wù)器里導(dǎo)入一些記錄，想訪問某個服務(wù)，通過DNS服務(wù)器解析出對應(yīng)的IP和Port，從而實現(xiàn)服務(wù)訪問。

Sprin Cloud框架下可以考慮用Kubernetes的服務(wù)發(fā)現(xiàn)替換Eureka。

Mesos對微服務(wù)的支撐

Markdown

〓 資源調(diào)度

數(shù)人云之前所做的平臺都是用Mesos，Kubernetes和Mesos各有優(yōu)勢，數(shù)人云將產(chǎn)品體系升級為企業(yè)應(yīng)用架構(gòu)管理《EAMS》體系后，也已經(jīng)全面支持Kuberntetes。

從Mesos調(diào)度的角度去看分為兩層：資源調(diào)度和應(yīng)用調(diào)度。資源調(diào)度主要負(fù)責(zé)系統(tǒng)資源調(diào)度管理，應(yīng)用調(diào)度有Framework管理，F(xiàn)ramework可以自定義，Mesos除了調(diào)度容器外通過不同F(xiàn)ramework的實現(xiàn)，還可以調(diào)度Hadoop等。

資源調(diào)度的過程，Master節(jié)點通過ZooKeeper實現(xiàn)高可用，Slave同Master Leader交互更新資源變化，調(diào)度請求由Framework發(fā)起（如Marathon，Swan），Mesos Master把可以適配的資源Buffer返回給Framework，F(xiàn)ramework下發(fā)Task到返回的Slave上，Slave執(zhí)行Task，并跟Master Leader更新資源Buffer。

Markdown

〓 服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)Mesos本身走不了，同時Marathon也并不提供。

數(shù)人云自己做了一個開源項目：Swan（GitHub地址：https://github.com/Dataman-Cloud/swan），可以通過Swan Proxy做服務(wù)發(fā)現(xiàn)和負(fù)載均衡，Proxy是跑在Slave上，它啟動容器后，注冊的內(nèi)容是nginx-demo.default.xcm.dataman-mesos.bbklab.net. 0 IN SRV 0 100 31000 0.nginx-demo.default.xcm.dataman-mesos.bbklab.net 里面會把定義的一個域名，包括權(quán)重，端口，的DNS注冊方式，即使不用Swan DNS，用外接的DNS都可以通用，因為注冊內(nèi)容是SRV標(biāo)準(zhǔn)。

說到這些域名，它和Kubernetes一樣，直接解析的話，可以具體定義到某一個集群、應(yīng)用、用戶都是可以找到的。

總結(jié)

Mesos和Kubernetes在資源調(diào)度方面都很優(yōu)秀，主要矛盾在于容器調(diào)度，結(jié)合上文提到的微服務(wù)，Kuberntes略有優(yōu)勢，因為會做很多負(fù)載均衡，集群管理、有狀態(tài)數(shù)據(jù)的管理，幫助消化很多東西。Mesos的優(yōu)勢在于比較靈活，擴(kuò)展性強(qiáng)。