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

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

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

容器的價值

Markdown

首先來思考一些問題:

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

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

請帶著這些問題,繼續往下看。

微服務體系建設

Markdown

試想下,目前比較火的微服務是不是和Docker或者說容器的經歷很相似?為什麼現在大家要用微服務,它都為我們帶來了什麼?單體應用時用的MVC架構,金融業會把應用切分成七層,接入層、服務層等等,微服務是否還要按照這種分層架構,用了它到底是簡單了,還是複雜了,是不是用了Spring Cloud、Dubbo即是微服務了?

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

微服務的所有服務之間都是平等的關係,每個服務內部還可以遵循之前的分層架構。

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

〓 微服務體系建設

Markdown

為什麼說微服務不是一個簡單的框架而是一個體系,因為一個框架並不能解決微服務給我們帶來的所有問題,如前面所提到的,其實還有很多,下面是在專案中遇到的一些體系方面建設的羅列,供以參考:

服務化框架:要解決的是服務之間呼叫的多通訊協議支援,資料互動的資料結構支援。

服務註冊和發現:完成服務切分後,服務之間完成解耦,通過服務註冊中心對服務統一管理,呼叫端去呼叫。

統一配置管理:不同環境如開發、生產、測試等環境的配置肯定不同,如果沒有做出相應的改變,那麼後續帶來的修改以及升級問題是不可想象的。

API閘道器:服務被拉平後,身份驗證、監控、負載均衡、快取、請求分片與管理、靜態相應處理。

監控報警:監控報警之所以重要的原因是因為之前做系統時,覺得開發測試完成後即可上線,但在金融行業並不如此,監控通過提高發現問題的時效性,更早更快地發現問題,從而保證系統穩定性。

文件管理:不同服務做切分後,按直接溝通模式,團隊間的溝通成本會很高,若切分了四五個服務還好,都互相知道,但切分了幾十個甚至上百個服務,所開發的服務可能都不知道水在呼叫,因此需要通過契約管理介面,通過文件管理將自己的API開放在一個通用的團裡平臺上,如Swagger,方便呼叫查閱。

任務排程系統:在系統當中,除了線上實時交易通過服務之間的呼叫去做,還有一些金融行業裡面跑批的任務,比如日切,凌晨2點要統一跑批,需要任務排程系統去執行,若用其他系統,隨著服務的膨脹,機器主機數量增加,後續的管理會產生很大問題。

風控平臺:如果有介面是開放的API要被外部呼叫,不止是在防火牆內部呼叫,此時如果有人進行攻擊,此係統可以幫助保持穩定性。

測試平臺:更多是把微服的整個系統:包括介面測試、單元測試、以及效能測試都在一個平臺統一做好,目的是縮短微服務的釋出週期,後續做持續整合時,才能提高交付效率和時間,更加敏捷。

持續整合/釋出:用了微服務後,通常都會採取敏捷的方法,比如兩週、四周做簡單迭代,中間的版本也非常多,每個版本的釋出都必不可少要做一次迴歸測試,工作量比較大,如果仍然由人工進行,會很艱難。

通過以上對於微服務體系進行了一些簡單的理解之後,現在就可以反過來回答前文中所提到的容器(Docker)價值問題——

Docker和VM的區別,結合微服務在做持續整合/釋出時,Docker更具有優勢,但這也並不是說有了Docker就沒必要再去採用VM,到底是將Docker部署在主機上還是部署在VM裡,其實沒有一定的答案,它們各有千秋,需要根據自身的實際情況去把控。

Kubernetes對微服務的支撐

Markdown

〓 編排

單體應用微服務化以後,服務之間必然會有依賴關係,在釋出時,若每個服務都單獨啟動會非常痛苦,簡單地說包括一些登入服務、支付服務,若想一次全部啟動,此時必不可少要用到編排的動作,這裡有一個子專案:Kompose將Docker Compose編排檔案無痛釋出到Kubernetes上,這是個簡單的Docker Compose檔案,釋出到一個Dedis叢集,一個前端。執行kompose convert –f docker-compose.yaml即可。

Markdown

〓 資源排程

排程是編排工具的核心,上圖可以看到Kuberenetes在排程方面的框架:

  1. 使用者通過Kuberctl提交執行Docker Container(Pod)的請求
  2. Api Server把請求儲存在Etcd
  3. Scheduler掃描,分配資源
  4. Kubelet得到排程要執行的任務,並在本機執行生成容器(Pod)

後面會對比一下Mesos的排程實現。

Markdown

〓 Statefulset

之前和客戶提到微服時,都會說到應用微服務化以後,如何遷移上雲的問題,這是很重要的動作,一般會給出的相應的建議:首先要將所有應用無狀態化,規範這樣的要求是因為服務狀態有坑在其中。

Kubernetes的Statefulset可以釋出有狀態服務,需要滿足以下要求:

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

總體來說,它為了實現有狀態的服務在這些前提下,還會有一些複雜性在其中。

之前有人提問資料庫跑在容器裡還是用主機服務,包括資料庫裡的分庫,都不是容器所關注的問題,建議資料庫服務先不做容器化,因為資料庫層面,更多是對IO的分流,在它的查詢,索引都是IP請求比較多。分庫分表,分散式事務是在應用層面解決的,同樣也不是容器所關注的,Docker接觸的更為底層,因為是一個OS。

Markdown

〓 服務發現

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

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

第一種:通過環境變數的方式,Pod建立是在環境變數中寫入Serviceip和Port。

第二種:DNS,Kubernetes叢集內建DNS伺服器,Service建立成功後會在DNS伺服器裡匯入一些記錄,想訪問某個服務,通過DNS伺服器解析出對應的IP和Port,從而實現服務訪問。

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

Mesos對微服務的支撐

Markdown

〓 資源排程

數人云之前所做的平臺都是用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。

Markdown

〓 服務發現

服務發現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的優勢在於比較靈活,擴充套件性強。