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

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

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

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

容器的價值

Markdown

首先來思考一些問題：

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

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

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

微服務體系建設

Markdown

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

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

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

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

〓 微服務體系建設

Markdown

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

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

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

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

API網(wǎng)關：服務被拉平后，身份驗證瀑梗、監(jiān)控烹笔、負載均衡、緩存抛丽、請求分片與管理谤职、靜態(tài)相應處理。

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

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

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

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

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

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

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

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

Kubernetes對微服務的支撐

Markdown

〓 編排

單體應用微服務化以后巾陕，服務之間必然會有依賴關系讨跟，在發(fā)布時，若每個服務都單獨啟動會非常痛苦鄙煤，簡單地說包括一些登錄服務晾匠、支付服務，若想一次全部啟動梯刚，此時必不可少要用到編排的動作凉馆，這里有一個子項目：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í)行的任務旷太，并在本機執(zhí)行生成容器（Pod）

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

Markdown

〓 Statefulset

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

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

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

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

之前有人提問數(shù)據(jù)庫跑在容器里還是用主機服務钠至，包括數(shù)據(jù)庫里的分庫，都不是容器所關注的問題胎源，建議數(shù)據(jù)庫服務先不做容器化棉钧，因為數(shù)據(jù)庫層面，更多是對IO的分流涕蚤，在它的查詢宪卿，索引都是IP請求比較多。分庫分表万栅，分布式事務是在應用層面解決的佑钾，同樣也不是容器所關注的，Docker接觸的更為底層烦粒，因為是一個OS休溶。

Markdown

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

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

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

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

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

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

Mesos對微服務的支撐

Markdown

〓 資源調(diào)度

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

從Mesos調(diào)度的角度去看分為兩層：資源調(diào)度和應用調(diào)度院溺。資源調(diào)度主要負責系統(tǒng)資源調(diào)度管理，應用調(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

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

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

數(shù)人云自己做了一個開源項目：Swan（GitHub地址：https://github.com/Dataman-Cloud/swan）型雳，可以通過Swan Proxy做服務發(fā)現(xiàn)和負載均衡当凡，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標準乌妒。

說到這些域名汹想，它和Kubernetes一樣，直接解析的話撤蚊，可以具體定義到某一個集群古掏、應用、用戶都是可以找到的侦啸。

總結(jié)

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