數人云架構師：微服務體系中的K8S&Mesos調度與服務發現

9月10日在K8S GeekGathering Meetup上，數人云架構師保珠作了關於《K8S&mesos之我見》的主題分享，分別介紹了Kubernetes和Mesos對微服務的支撐，如下是本次分享的實錄——前端

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

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

關於容器你們可能已經理解或者正在實踐使用，因此今天會講一下容器的價值方面內容，而後是目前比較火的微服務相關：將單體應用解構成微服務後它究竟是一個怎樣的概念，然後是Kubernetes和Mesos在微服務方面的支撐，最後是基於以上作一個總結。git

容器的價值

首先來思考一些問題：github

• Docker如今已是容器界的事實標準，緣由是什麼？
• Docker和VM各自都有什麼優點？

2013年，Docker就已經在國內進行發展，2015年本人首次接觸Docker是在客戶現場進行生產應用部署，後來在和客戶分享交流中，被問及的比較多的一點是Docker和VM究竟有什麼區別，以及各自的價值是什麼？Docker如此之火，難道就是由於輕量化、隔離性安全性以及秒級啓動這些緣由嗎？這些特性VM也能夠經過變通的方式作到，那麼Docker的價值究竟是什麼？docker

請帶着這些問題，繼續往下看。數據庫

微服務體系建設

試想下，目前比較火的微服務是否是和Docker或者說容器的經歷很類似？爲何如今你們要用微服務，它都爲咱們帶來了什麼？單體應用時用的MVC架構，金融業會把應用切分紅七層，接入層、服務層等等，微服務是否還要按照這種分層架構，用了它究竟是簡單了，仍是複雜了，是否是用了Spring Cloud、Dubbo便是微服務了？緩存

隨着應用規模的膨脹致使運維規模線性增加，如何解決：有了微服務的概念後，應用能夠按照業務模塊作切分，作了微服務化切割夠，一個小團隊去管理開發一個服務，但隨之而來的問題是，之前10個系統，5個運維就能夠完成任務，使用微服務後可能會變成每一個系統有幾十個服務，部署的複雜度、團隊之間的溝通協調、線上問題追蹤，版本控制這些問題須要一些解決辦法。安全

微服務的全部服務之間都是平等的關係，每一個服務內部還能夠遵循以前的分層架構。服務器

當把系統作了模塊化切分後，用Spring Cloud或者Dubbo框架去構建系統，雖然感受上這就屬於微服務的範疇，但隨着對於這個體系的瞭解，其實會發現還遠遠不夠。網絡

〓 微服務體系建設

爲何說微服務不是一個簡單的框架而是一個體系，由於一個框架並不能解決微服務給咱們帶來的全部問題，如前面所提到的，其實還有不少，下面是在項目中遇到的一些體系方面建設的羅列，供以參考：

服務化框架：要解決的是服務之間調用的多通信協議支持，數據交互的數據結構支持。

服務註冊和發現：完成服務切分後，服務之間完成解耦，經過服務註冊中心對服務統一管理，調用端去調用。

統一配置管理：不一樣環境如開發、生產、測試等環境的配置確定不一樣，若是沒有作出相應的改變，那麼後續帶來的修改以及升級問題是不可想象的。

API網關：服務被拉平後，身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態相應處理。

監控報警：監控報警之因此重要的緣由是由於以前作系統時，以爲開發測試完成後便可上線，但在金融行業並不如此，監控經過提升發現問題的時效性，更早更快地發現問題，從而保證系統穩定性。

文檔管理：不一樣服務作切分後，按直接溝通模式，團隊間的溝通成本會很高，若切分了四五個服務還好，都互相知道，但切分了幾十個甚至上百個服務，所開發的服務可能都不知道水在調用，所以須要經過契約管理接口，經過文檔管理將本身的API開放在一個通用的團裏平臺上，如Swagger，方便調用查閱。

任務調度系統：在系統當中，除了在線實時交易經過服務之間的調用去作，還有一些金融行業裏面跑批的任務，好比日切，凌晨2點要統一跑批，須要任務調度系統去執行，若用其餘系統，隨着服務的膨脹，機器主機數量增長，後續的管理會產生很大問題。

風控平臺：若是有接口是開放的API要被外部調用，不止是在防火牆內部調用，此時若是有人進行攻擊，此係統能夠幫助保持穩定性。

測試平臺：更可能是把微服的整個系統：包括接口測試、單元測試、以及性能測試都在一個平臺統一作好，目的是縮短微服務的發佈週期，後續作持續集成時，才能提升交付效率和時間，更加敏捷。

持續集成/發佈：用了微服務後，一般都會採起敏捷的方法，好比兩週、四周作簡單迭代，中間的版本也很是多，每一個版本的發佈都必不可少要作一次迴歸測試，工做量比較大，若是仍然由人工進行，會很艱難。

經過以上對於微服務體系進行了一些簡單的理解以後，如今就能夠反過來回答前文中所提到的容器（Docker）價值問題——

Docker和VM的區別，結合微服務在作持續集成/發佈時，Docker更具備優點，但這也並非說有了Docker就不必再去採用VM，究竟是將Docker部署在主機上仍是部署在VM裏，其實沒有必定的答案，它們各有千秋，須要根據自身的實際狀況去把控。

Kubernetes對微服務的支撐

〓 編排

單體應用微服務化之後，服務之間必然會有依賴關係，在發佈時，若每一個服務都單獨啓動會很是痛苦，簡單地說包括一些登陸服務、支付服務，若想一次所有啓動，此時必不可少要用到編排的動做，這裏有一個子項目：Kompose將Docker Compose編排文件無痛發佈到Kubernetes上，這是個簡單的Docker Compose文件，發佈到一個Dedis集羣，一個前端。執行kompose convert –f docker-compose.yaml便可。

〓 資源調度

調度是編排工具的核心，上圖能夠看到Kuberenetes在調度方面的框架：

1. 用戶經過Kuberctl提交運行Docker Container（Pod）的請求
2. Api Server把請求存儲在Etcd
3. Scheduler掃描，分配資源
4. Kubelet獲得調度要執行的任務，並在本機執行生成容器（Pod）

後面會對比一下Mesos的調度實現。

〓 Statefulset

以前和客戶提到微服時，都會說到應用微服務化之後，如何遷移上雲的問題，這是很重要的動做，通常會給出的相應的建議：首先要將全部應用無狀態化，規範這樣的要求是由於服務狀態有坑在其中。

Kubernetes的Statefulset能夠發佈有狀態服務，須要知足如下要求：

• Pod的存儲必須經過Persistentvolume Provisioner基於Storeage提供
• 由Headless Service生成Pods的惟一網絡標識
• Statefulset的升級是一個手動的過程

整體來講，它爲了實現有狀態的服務在這些前提下，還會有一些複雜性在其中。

以前有人提問數據庫跑在容器裏仍是用主機服務，包括數據庫裏的分庫，都不是容器所關注的問題，建議數據庫服務先不作容器化，由於數據庫層面，更可能是對IO的分流，在它的查詢，索引都是IP請求比較多。分庫分表，分佈式事務是在應用層面解決的，一樣也不是容器所關注的，Docker接觸的更爲底層，由於是一個OS。

〓 服務發現

關於服務發現，上面提到微服務後，服務數量劇增，端到端的模式已再也不適用，此時就須要作服務發現，有了服務發現和負載均衡，它能夠把服務之間作一個解耦，能夠提高升級方面的相關問題。

Kubernetes的服務發現有兩種模式：

第一種：經過環境變量的方式，Pod建立是在環境變量中寫入Serviceip和Port。

第二種：DNS，Kubernetes集羣內置DNS服務器，Service建立成功後會在DNS服務器裏導入一些記錄，想訪問某個服務，經過DNS服務器解析出對應的IP和Port，從而實現服務訪問。

Sprin Cloud框架下能夠考慮用Kubernetes的服務發現替換Eureka。

Mesos對微服務的支撐

〓 資源調度

數人云以前所作的平臺都是用Mesos，Kubernetes和Mesos各有優點，數人云將產品體系升級爲企業應用架構管理《EAMS》體系後，也已經全面支持Kuberntetes。

從Mesos調度的角度去看分爲兩層：資源調度和應用調度。資源調度主要負責系統資源調度管理，應用調度有Framework管理，Framework能夠自定義，Mesos除了調度容器外經過不一樣Framework的實現，還能夠調度Hadoop等。

資源調度的過程，Master節點經過ZooKeeper實現高可用，Slave同Master Leader交互更新資源變化，調度請求由Framework發起（如Marathon，Swan），Mesos Master把能夠適配的資源Buffer返回給Framework，Framework下發Task到返回的Slave上，Slave執行Task，並跟Master Leader更新資源Buffer。

〓 服務發現

服務發現Mesos自己走不了，同時Marathon也並不提供。

數人云本身作了一個開源項目：Swan（GitHub地址：https://github.com/Dataman-Cl...），能夠經過Swan Proxy作服務發現和負載均衡，Proxy是跑在Slave上，它啓動容器後，註冊的內容是nginx-demo.default.xcm.dataman-mesos.bbklab.net. 0 IN SRV 0 100 31000 0.nginx-demo.default.xcm.dataman-mesos.bbklab.net 裏面會把定義的一個域名，包括權重，端口，的DNS註冊方式，即便不用Swan DNS，用外接的DNS均可以通用，由於註冊內容是SRV標準。

說到這些域名，它和Kubernetes同樣，直接解析的話，能夠具體定義到某一個集羣、應用、用戶都是能夠找到的。

總結

Mesos和Kubernetes在資源調度方面都很優秀，主要矛盾在於容器調度，結合上文提到的微服務，Kuberntes略有優點，由於會作不少負載均衡，集羣管理、有狀態數據的管理，幫助消化不少東西。Mesos的優點在於比較靈活，擴展性強。