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

本次主要分享主要有以下五個方面：
– 容器的價值
– 微服務體系建設
– Kubernetes對微服務的支撐
– Mesos對微服務的支撐
– 總結

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

容器的價值

首先來思考一些問題：

• Docker現在已經是容器界的事實標準，原因是什麼？
• Docker和VM各自都有什麼優勢？

2013年，Docker就已經在國內進行發展，2015年本人首次接觸Docker是在客戶現場進行生產應用部署，後來在和客戶分享交流中，被問及的比較多的一點是Docker和VM究竟有什麼區別，以及各自的價值是什麼？Docker如此之火，難道就是因為輕量化、隔離性安全性以及秒級啟動這些原因嗎？這些特性VM也可以通過變通的方式做到，那麼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-Cloud/swan），可以通過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的優勢在於比較靈活，擴充套件性強。