iUAP雲運維平臺v3.0全面支持基於K8s的微服務架構

什麼是微服務架構？
微服務(MicroServices)架構是當前互聯網業界的一個技術熱點，業內各公司也都紛紛開展微服務化體系建設。微服務架構的本質，是用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。該架構強調的一些準則：單一職責、協議輕量、進程隔離、數據分離、獨立部署、按需伸縮。

什麼是Kubernetes？
Kubernetes是Google開源的容器集羣管理系統，其提供應用部署、維護、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應用，其主要功能：1) 自動化容器的部署和複製，隨時擴展或收縮容器規模。2) 以集羣的方式運行、管理跨機器的容器。3) 將容器組織成組，而且提供容器間的負載均衡。4) 解決Docker跨機器容器之間的通信問題。5) Kubernetes的自我修復機制使得容器集羣保持健康狀態。
微服務架構（MSA）跟SOA架構有何不一樣？
微服務架構是伴隨敏捷迭代開發而興起的，更增強調快速敏捷部署和伸縮，適用於功能拆分比較細的場景，粒度也更小、更獨立。協議上基於更加輕量化的REST API，供內部各子系統及微服務之間調用。適合業務相對獨立、簡單的互聯網場景。強調服務的獨立部署和易伸縮能力。下圖是詳細的對比：

怎麼理解服務註冊和服務發現？
微服務架構下，有大量的微服務須要處理。因爲微服務的快速和敏捷研發，他們的位置可能會動態變化。所以在運行時須要可以發現服務所在的位置，服務發現能夠解決這個問題。
服務註冊：註冊中心有微服務的實例和位置信息，微服務在啓動時向註冊中心註冊本身的信息，關閉時註銷。其它使用者可以經過註冊中心找到可用的微服務和相關信息。
服務發現：爲了能找到可用的服務和他們的位置信息，須要服務發現機制。有兩種發現機制，客戶端發現和服務端發現。WEB應用中，比較經常使用的是服務端發現的方式：客戶端/API網關把請求發送到已知位置信息的組件（好比負載均衡器）。組件去訪問註冊中心，找到微服務的路徑信息，並跳轉到相應的微服務。

雲運維平臺如何基於Kubernetes實施微服務？
基於平臺的微服務部署變得不一樣於傳統模式：可以獨立於其餘微服務發佈或者取消發佈； 微服務能夠水平擴展（某一個服務比其餘的請求量大）；可以實現快速的構建和發佈；各微服務之間的功能不相互影響。使用基於Kubernetes的方式部署微服務，用戶須要的只是定義服務的狀態，而不是部署過程。
先來看一下Kubenetes總體框架，以下圖所示：主要包括kubecfg、Master API Server、Kubelet、Minion以及Proxy。
Master定義了Kubernetes 集羣Master/API Server的主要聲明，包括Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、REST Storage以及Client, 是client(Kubecfg)調用Kubernetes API，管理Kubernetes主要構件Pods、Services、Minions、容器的入口。 Minion負責跟蹤Kubernetes 集羣中有多少臺主機。Pod負責跟蹤集羣中有多少Pod在運行，及跟Minion的映射關係。
下面咱們一塊兒看下，基於Kubernetes是如何進行服務註冊發現的，其詳細的架構以下圖所示：

Kubelet是Kubernetes集羣中每一個Minion和Master API Server的鏈接點，Kubelet運行在每一個Minion上，是Master API Server和Minion之間的橋樑，接收Master API Server分配給它的commands和work，與持久性鍵值存儲etcd、file、server和http進行交互，讀取配置信息。Kubelet的主要工做是管理Pod和容器的生命週期，其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker組件。
部署完畢後的Kubernetes集羣，其各組件和微服務架構所提出的一些準則的對應關係，以下圖所示：

應用以Docker容器的形態，經過Namespace隔離的運行在定義好的Pod當中，各微服務之間的調用變得如此簡單，不再用爲微服務的實施和治理煩惱了。