摘要：平臺上的微服務(wù)架構(gòu)應(yīng)用再來看一下我眼中的基于當(dāng)前最流行的微服務(wù)架構(gòu)的設(shè)計是什么樣的，即我們平臺上要運行的典型應(yīng)用是什么樣的。

8月19日的數(shù)人云Container Meetup上，張龍老師做了《基于Kubernetes的PaaS平臺的設(shè)計和思考》的精彩分享，分別介紹了PaaS平臺的意義，為什么選擇Kubernetes，PaaS平臺上的微服務(wù)架構(gòu)應(yīng)用，如何設(shè)計和快速構(gòu)建PaaS平臺，PaaS平臺的功能組件這幾個內(nèi)容。

以下為現(xiàn)場實錄內(nèi)容——

今天跟大家分享下基于Kubernetes的PaaS平臺設(shè)計和思考，主要分為五個部分：

PaaS平臺的意義

為什么選擇Kubernetes

PaaS平臺上的微服務(wù)架構(gòu)應(yīng)用

PaaS平臺架構(gòu)設(shè)計

PaaS平臺功能組件

很多公司技術(shù)支持崗位的工作，如配置域名，部署環(huán)境，修改復(fù)位配置，服務(wù)重啟，擴容縮容，梳理和完善監(jiān)控，根據(jù)開發(fā)的需要查找日志等工作，需要和開發(fā)進行大量的溝通，如什么是外網(wǎng)域名，什么是內(nèi)網(wǎng)域名、A name、C name，防火墻規(guī)則該如何設(shè)定，操作系統(tǒng)等基礎(chǔ)環(huán)境需要什么依賴。因為很多研發(fā)不了解運維的術(shù)語和知識點，導(dǎo)致溝通困難，效率很低。而且這樣的需求還很多，把運維壓的喘不過氣，占用了幾乎所有的時間，但是開發(fā)的需求可能還是遲遲不能滿足。

這樣的公司可能遇到了以下問題：

系統(tǒng)架構(gòu)過于陳舊，性能、可靠性無法滿足現(xiàn)有的需求；

原有IT架構(gòu)不靈活，業(yè)務(wù)模塊新增或變更帶來巨大成本壓力；

系統(tǒng)功能繁雜，結(jié)構(gòu)紊亂，定制的代碼與系統(tǒng)耦合性極高；

服務(wù)種類繁多，各種技術(shù)棧橫行；

人員流動交接不充分，新接手的團隊對部署環(huán)境不了解，只能做周邊的修補，不敢遷移 。

如何才能解決？答案是流程化、標(biāo)準(zhǔn)化、自動化、平臺化。

流程化

即主動梳理運維工作任務(wù)，形成標(biāo)準(zhǔn)化的操作流程，尤其是針對需要多人協(xié)作完成的任務(wù)，比如應(yīng)用的發(fā)布部署，把流程固化到流程平臺系統(tǒng)中，保證每個人執(zhí)行都能按照流程嚴(yán)格執(zhí)行，不會有哪些環(huán)節(jié)遺漏，而且當(dāng)前的流程狀態(tài)對所有人都可見，能清晰的看到誰正在處理，處理人也會更主動盡快的完成該任務(wù)。

標(biāo)準(zhǔn)化

從架構(gòu)角度按照應(yīng)用類別制定應(yīng)用的部署標(biāo)準(zhǔn)，比如Web類型的應(yīng)用，服務(wù)化的應(yīng)用（我們內(nèi)部用的JSF），或者是比較新的微服務(wù)的應(yīng)用（Springboot等），部署腳本和工具平臺按照約定好的規(guī)范進行設(shè)計開發(fā)，減少了因為應(yīng)用種類繁多導(dǎo)致工具和平臺的復(fù)雜。

自動化

早期寫了非常多的腳本，任務(wù)執(zhí)行機到要執(zhí)行任務(wù)的服務(wù)器之間通過SSH免密鑰認(rèn)證，再根據(jù)需要批量執(zhí)行命令。隨著服務(wù)器規(guī)模和應(yīng)用數(shù)量的擴張，很快腳本執(zhí)行的方式無法滿足業(yè)務(wù)發(fā)展，難以理解，同一個類型的任務(wù)多個腳本并存，存在誤操作，缺乏清晰的操作歷史記錄和回滾機制，即使后續(xù)替換了如Puppet，Saltstack，Ansible這樣的配置管理工具，但根本問題并沒有解決。

※ 平臺化

平臺化是這次分享的重點，一定要在前面三條的基礎(chǔ)上進行建設(shè)，如果沒有清晰的流程，明確的標(biāo)準(zhǔn)，平臺建設(shè)起來也只是自動化工具的集成，解決不了公司核心問題。

以下說的平臺化內(nèi)容主要是PaaS平臺化，即主要從應(yīng)用和中間件的角度，這里不討論IaaS的內(nèi)容。

PasS平臺化將問題的關(guān)注點從基礎(chǔ)資源上升到了應(yīng)用層面，目標(biāo)是提供一個幫助開發(fā)人員運行、管理應(yīng)用的平臺，讓使用者更關(guān)注運行的代碼（業(yè)務(wù)邏輯）。

PaaS能解決的問題：

應(yīng)用聚合：如開發(fā)需要一個Redis，直接啟動一個Redis容器即可

服務(wù)發(fā)現(xiàn)、快速伸縮、狀態(tài)管理等

服務(wù)監(jiān)控、恢復(fù)、容災(zāi)

費用統(tǒng)計：提供計算資源信息匯總，針對不同項目收費

安全管控：不管什么平臺，安全都非常重要，例如A應(yīng)用可以訪問B,B不允許訪問A以及安全審計等。

快速部署。

隨著Docker容器技術(shù)的出現(xiàn)，讓我們有了更合適的工具建設(shè)PaaS平臺，具備了基于應(yīng)用構(gòu)建服務(wù)的能力。

在Docker容器調(diào)度框架上，我們又選擇了Kubernetes平臺。

先列一下目前三大主流的容器調(diào)度框架的功能和特點：

〓 Kubernetes

資源調(diào)度、服務(wù)發(fā)現(xiàn)、服務(wù)編排、資源邏輯隔離、服務(wù)自愈、安全配置管理、Job任務(wù)支持、自動回滾、內(nèi)部域名服務(wù)、健康檢查、有狀態(tài)支持、運行監(jiān)控/日志、擴容縮容、負(fù)載均衡、灰度升級、容災(zāi)恢復(fù)、應(yīng)用HA。

〓 Mesos

Mesos是一個分布式內(nèi)核，目前的發(fā)展方向是數(shù)據(jù)中心操作系統(tǒng)（DCOS），它同時支持 Marathon、 Kubernetes 和 Swarm 等多種框架，Mesosphere 也是 Kubernetes 生態(tài)的一員。

注意Marathon的技術(shù)棧是Scala語言，而Docker和Kubernetes的技術(shù)棧都是Go語言。

〓 Swarm

從Docker1.12版本開始，Swarm 隨Docker一起默認(rèn)安裝發(fā)布，也由于隨Docker引擎一起發(fā)布，無需額外安裝，配置簡單。

支持服務(wù)注冊、服務(wù)發(fā)現(xiàn)，內(nèi)置Overlay Network以及Load Balancer。

與Docker CLI非常類似的操作命令，對熟悉Docker的人非常容易上手學(xué)習(xí)。

每一種工具都有自己的核心理念。

Mesos理念是數(shù)據(jù)中心操作系統(tǒng)（DCOS），為了解決IaaS層的網(wǎng)絡(luò)、計算和存儲問題，所以Mesos的核心是解決物理資源層的問題。

Kubernetes的核心是如何解決自動部署，擴展和管理容器化（containerized）應(yīng)用程序。

所以，個人認(rèn)為Mesos和Kubernetes是兩種維度，對于我們的場景來說，關(guān)心應(yīng)用的狀態(tài)多于物理資源層管理，因此更關(guān)心的是容器化應(yīng)用程序管理，這是我們選擇Kubernetes的主要原因。

另外選擇Kubernetes還考慮了其它優(yōu)勢，如：

出身名門Google，其開發(fā)和設(shè)計受到了Google著名的Borg系統(tǒng)的影響；

GitHub上關(guān)注Kubernetes項目和提交代碼的開發(fā)者非常多，社區(qū)活躍，如果遇到問題，通過社區(qū)咨詢和解決 問題速度也會比較快。

Kubernetes可以很好的支持有狀態(tài)的服務(wù)。

再來看一下我眼中的基于當(dāng)前最流行的微服務(wù)架構(gòu)的設(shè)計是什么樣的，即我們PaaS平臺上要運行的典型應(yīng)用是什么樣的。

用戶端的請求進來以后，首先進入前端的Nginx服務(wù)器，再進入Zuul代理網(wǎng)管上，由Zuul將這些任務(wù)下發(fā)到不同的服務(wù)上去。Eureka集群作為注冊中心服務(wù)，提供服務(wù)的發(fā)現(xiàn)和注冊的功能。服務(wù)后端再去調(diào)用依賴的其他服務(wù)，數(shù)據(jù)庫集群，Redis集群等服務(wù)。

微服務(wù)架構(gòu)因為有注冊中心自動解決了服務(wù)注冊發(fā)現(xiàn)的問題，所以對內(nèi)部服務(wù)來講就不用依賴傳統(tǒng)的負(fù)載均衡器等工具，很容易將各個服務(wù)Docker化，遷移到PaaS平臺里統(tǒng)一管理。

在建設(shè)PaaS平臺之前，參考《高效人士的七個習(xí)慣》設(shè)定了PaaS平臺建設(shè)的原則：

以終為始：做一件事情要知道想達(dá)成什么樣的目的，知道這個目的之后，就能夠圍繞這個目標(biāo)采取一些措施。

知己解彼：作為一個運維人員，需要有一個比較大的知識面。只有如此才能夠去制定一些適合自己的方案和產(chǎn)品。

積極主動：因為要做PaaS所以要把自己的主觀能動性都調(diào)起來。

要事第一：上面說了很多PaaS相關(guān)的內(nèi)容，由于時間、人員的限制。如何從眾多的基礎(chǔ)組建中挑選出來最重要的一些事情，著手建設(shè)。

雙贏：做出來的系統(tǒng)最好是能夠達(dá)到對開發(fā)、運維、公司都有利。

統(tǒng)合綜效：對待同樣的一件事，每個人都會有自己的見解。同時也要問同伴，要把所有的觀點都收集起來做一個綜合分析對比，以收到更好的效果。

持續(xù)更新：時刻提醒自己持續(xù)學(xué)習(xí)，擁抱變化，這樣才能看到平臺的不足。持續(xù)迭代出更好的產(chǎn)品。

基于以上的原則，我們團隊勾勒了一個最小化的PaaS圖：

最上面的Ingress服務(wù)跟傳統(tǒng)的負(fù)載均衡器的功能類似，提供請求分發(fā)的功能。

Service相當(dāng)于后端Pod的一個代理服務(wù)器，Service需要通過Ingress服務(wù)才能被外部Client訪問。

Pod則相當(dāng)于我們傳統(tǒng)的一個服務(wù)。

最小化PaaS平臺還用到了DNS組件，在內(nèi)部服務(wù)運行起來之后，我們會通過DNS組件分配一個內(nèi)部域名供訪問時使用。

Kubernetes對外提供服務(wù)，用的是Lvs+Ingress，每次添加一個新的服務(wù)之后會調(diào)用一次DNS的API，按照規(guī)則生成一個內(nèi)部域名供訪問使用。

應(yīng)用持續(xù)部署

平臺實現(xiàn)快速、可視化自動部署功能。支持對應(yīng)用的快速、可視化部署。用戶僅需在界面中選擇相應(yīng)的鏡像和組件，并填寫簡單的配置信息，點擊部署按鈕，即可完成整個應(yīng)用的安裝或者升級。在測試環(huán)境可通過Jenkins，可實現(xiàn)應(yīng)用的持續(xù)集成和全自動化升級，同時支持一鍵回滾和恢復(fù)發(fā)布功能。

應(yīng)用彈性伸縮

構(gòu)建具有需求預(yù)測和容器按需供給能力的彈性伸縮子系統(tǒng)，具有基于應(yīng)用的負(fù)載和資源情況進行彈性伸縮能力，以應(yīng)對互聯(lián)網(wǎng)用戶高并發(fā)的特點，應(yīng)對流量沖擊。其中，包括容器彈性伸縮、物理機彈性伸縮功能。

容器和組件的統(tǒng)一管理

從整體應(yīng)用的角度出發(fā)，平臺不僅管理鏡像和容器，而是將一個應(yīng)用涉及的所有組件均做了統(tǒng)一管理，比如對前端的DNS、負(fù)載均衡（F5/Nginx），后端數(shù)據(jù)庫等的管理。通過對系統(tǒng)相關(guān)組件和容器統(tǒng)一管理，平臺將可以實現(xiàn)系統(tǒng)的全局統(tǒng)一部署、配置、升級/回滾、監(jiān)控、故障處理等功能。

高可靠性

容器的故障恢復(fù)，當(dāng)服務(wù)器宕機時，平臺系統(tǒng)會自動在其它服務(wù)器上重新啟動容器并為其分配資源，從而達(dá)到秒級啟動，恢復(fù)業(yè)務(wù)。保障業(yè)務(wù)不掉線，高可靠運行；鏡像倉庫的可靠性，通過將單機版的鏡像倉庫擴展成鏡像倉庫集群，從而提升性能，實現(xiàn)Registry的無狀態(tài)化，便于實現(xiàn)服務(wù)的高可用性。

應(yīng)用docker化封裝

系統(tǒng)支持如下幾類常見應(yīng)用：Tomcat、Jboss、Nginx、Redis、Zookeeper等。

具體實施時，主要有幾個基礎(chǔ)組件需要開發(fā)：

〓 鏡像管理

實際運行的應(yīng)用鏡像由 “基礎(chǔ)中間件鏡像”+“應(yīng)用包”+“配置” 自動構(gòu)建，無需開發(fā)人員理解鏡像概念和手動制作鏡像；

〓 DNS管理

定制化公司內(nèi)部使用的DNS管理平臺，對公司的DNS進行統(tǒng)一管理；

〓 服務(wù)管理

需要定制化一套Kubernetes的Deployment模板，從Ingress到Service再到RC都定義在這套模板里面，方便對容器進行擴容、縮容、刪除操作；

〓 服務(wù)內(nèi)pod管理

屬于Kubernetes自有范疇，查看Service內(nèi)的Pod運行情況、Pod日志輸出等功能；

〓 日志管理

將日志輸出到公司的日志平臺（如ELK平臺），對接研發(fā)人員排查問題、數(shù)據(jù)埋點使用。

〓 監(jiān)控管理

參考方案cadvisor+influxdb+grafana/ heapster+influxdb+grafana/Prometheus/zabbix.

一個中小企業(yè)做成這樣后，日常運維的工作量即可大量減少，兩三個人就能完成日常的應(yīng)用運維工作，有興趣地話可以去挑戰(zhàn)一下。當(dāng)然做完這些后，還只是一個小型的PaaS平臺。

如果是再復(fù)雜一點的PaaS平臺，應(yīng)該還有哪些要繼續(xù)做的呢？

環(huán)境管理：即一套平臺管理多套不同的Kubernetes集群。安全管理、流程管理、計費管理等功能模塊。

還有因為規(guī)模增加和更高的可靠性要求，對應(yīng)的網(wǎng)絡(luò)，IO等各種優(yōu)化。

其實還有很多功能就不一一列舉了，可以根據(jù)自己的實際情況添加功能模塊，設(shè)計有自己公司特色的PaaS平臺。