淺談微服務架構、容器技術與K8S

時間 2019-12-06

標籤淺談微服架構容器技術 k8s 欄目系統架構简体版

原文原文鏈接

關注嘉爲科技，獲取運維新知編程

企業應用系統：從單體應用走向微服務架構；從裸金屬走向容器。服務器

若是在諸多熱門雲計算技術諸如容器、微服務、DevOps、OpenStack等之中，找出一個最火的方向，那麼可能非微服務莫屬。儘管話題煊赫一時，但對傳統行業來講，微服務落地和方法論目前處於起步階段。網絡

單體架構

對於傳統企業來講，數字化轉型的需求日益迫切，其IT架構面臨着互聯網融合業務中海量用戶和快速迭代的巨大挑戰。當前，咱們所開發的應用，無論是運行在局域網中仍是部署在雲端的，都採用了單體架構、分佈式架構或微服務架構其中的一種。架構

其中，採用單體架構的應用數量最多，咱們將這種應用簡稱爲單體應用。咱們能夠將單體應用理解爲主要的業務邏輯模塊（咱們編寫的代碼模塊，不包括獨立的中間件）運行在一個進程中的應用，最典型的是跑在Tomcat中的Java Web應用，無論這個應用在內部劃分了多少模塊，以及是否採用了MVC的分層架構，它都是一個單體應用，由於全部模塊都運行在一個Tomcat容器中，位於一個進程裏，如圖所示是目前應用最爲普遍的基於Sping Framework的單體應用的架構圖。負載均衡

單機應用有哪些好處和劣勢呢？框架

好處運維

技術門檻低分佈式
編程工做量少微服務
開發簡單快速工具
調試方便
環境容易搭建
容易發佈部署及升級
不管是開發仍是運維，其整體成本都很低且見效快

劣勢

單體應用的系統比較膨脹與臃腫，致使進行可持續開發和運維很困難。

例如：一開始，咱們的系統只有10個模塊，隨着業務的擴展，一年後變成了30個模塊，兩年後達到80個模塊。項目的工程代碼因爲過於龐大，不少代碼被不斷修改，整個系統的源碼已經很難被理解和掌握了。
單體應用在基因上的缺陷致使它很難經過水平擴展、多機部署的方式來提高系統的吞吐量，通常只能經過縱向不斷堆單個機器或者羣集的性能配置來提高。

這樣的結果就是系統難以承載迅速增加的互聯網用戶引起的請求，也就是說，在用戶規模增長後，即便不斷升級服務器硬件並進行各類性能調優，系統也會動不動就「掛了」。
單體應用的多個模塊在代碼級別沒有明確的接口與界限劃分，在修改已有代碼時，常常牽一髮而動全身。在傳統單體架構下，應用若是頻繁升級更新，開發團隊很是痛苦。企業的業務應用通過多年IT建設，系統很是龐大，要改動其中任何一小部分，都須要從新部署整個應用，敏捷開發和快速交付無從談起。
隨着單體應用模塊不斷增長和代碼不斷被修改，面對一個龐然大物的單體應用，新人很難應對，即難以繼續用老技術、老框架去維持這個舊系統，也很難用新技術、新框架來全面升級這個老舊的單體應用。

待應用自己已經難以經過修修補補知足當前業務模式的需求以後，這種老舊的單體應用即被全面拋棄，在推翻和轉型過程當中的陣痛仍然在所不免。

分佈式架構、SOA架構

面對上述的單體應用存在的如此多的問題，怎麼解決呢？咱們天然而然可以想到：拆。

沒錯，確實是這樣。咱們能夠將一個龐大的單體應用拆分紅多個服務模塊，而後再將這些服務模塊按照業務邏輯串起來，對外提供應用服務。這就是SOA（面向服務架構）的思路。

SOA：即面向服務的架構（SOA），是集成多個較大組件（通常是應用）的一種機制，它們將總體構成一個彼此協做的套件。通常來講，每一個組件會從始至終執行一塊完整的業務邏輯，一般包括完成總體大action所需的各類具體任務與功能。組件通常都是鬆耦合的，但這並不是SOA架構模式的要求。

下圖是一個典型的SOA架構的應用。

然而SOA架構也存在一些問題：好比單個拆分出來的模塊可能依然比較大，包含多個服務，沒法實現更小的服務單元的敏捷交付；而且服務與服務之間耦合性依然比較強；再好比，ESB總線很容易成爲整個系統的性能瓶頸等等。

微服務架構

怎麼辦呢？繼續拆，而且在拆的同時改變了所使用的底層承載的技術以及服務之間的關聯方式。

這就是微服務架構+容器技術。

容器和微服務相輔相成，兩大技術成熟的時間點很是契合。容器技術的成熟爲微服務提供了得天獨厚的客觀條件。輕量化的容器是微服務的最佳運行環境，微服務應用只有在容器環境下才能保障運維效率的提高。同時，微服務應用架構對外在組件的管理會變得困難，須要用容器平臺去管理中間件，才能發揮出更大價值。

在分佈式技術發展早期，出現過一個基於RPC技術的「偉大的分佈式平臺」，這個平臺的夢想是實現全部語言、全部平臺、全部廠商的各類IT系統的分佈式互聯互通，這就是CORBA，惋惜這個由IBM、Sun Microsystems、蘋果、微軟等IT公司聯手發起的偉大創舉最終失敗。

以後，一些CORBA技術專家彙集在一塊兒，繼續沿着CORBA的夢想前進，最終打造出一款優秀的分佈式架構基礎平臺——ZeroC ICE。ICE基於高性能的RPC通訊技術，跨語言，跨平臺，擁有傑出的性能。憑藉強大的技術實力，ZeroC公司屹立至今，雖然當年的IT霸主SUN早已不在，但ZeroC公司依然由於擁有不少關鍵領域的大客戶而健康成長。同時，ZeroC公司於2005年發佈的ICE 3.0首次實現了IceGrid。在如今看來，IceGrid具有了微服務架構平臺的全部關鍵特性，可被認爲是第一個公開發行的、支持多語言的、功能完備的微服務架構基礎平臺，如圖所示是IceGrid的完整示意圖。

從圖能夠看到，IceGrid具有微服務架構的核心特性。

服務編排：IceGrid採用XML方式定義服務及服務的部署拓撲，經過命令行工具一鍵發佈。
服務託管：IceGrid中的「微服務」運行於IceBox這個容器中，由容器託管整個服務的生命週期，包括啓動服務、中止服務、升級服務等過程。
服務註冊：Ice Registry實現服務註冊功能，支持靜態配置與動態註冊兩種機制，而且能夠配置一主一從的集羣，避免單點故障。
服務路由與負載均衡：採用客戶端負載均衡機制，在客戶端SDK裏內嵌實現，無須編程，具備基於主機負載、輪詢等多種負載均衡方式。
平臺運維：基於命令行與Java GUI工具，經常使用的運維命令都已經內置實現，用戶也能夠根據ICE提供的管理API來實現定製化的Web運維工具。

整體上，微服務架構平臺的核心組成就是上述組件，下圖所示爲典型的微服務架構平臺的結構示意圖。

在IceGrid以後，比較有影響力的開源微服務架構框架有Dubbo與 Spring Cloud，二者都是Java語言體系內的微服務框架，並不支持其餘語言。與IceGrid相比，其完備性還達不到平臺（Platform）的高度，目前只能被稱爲框架（Framework）。下表給出了Dubbo 與Spring Cloud的主要功能對比。

Spring Cloud相對而言更加全面，開源更有保障，同時開創性地實現了微服務架構框架中諸如斷路器、流量儀表板、服務網關等特性，同時提供了在分佈式開發中所需的不少基礎組件（API），例如配置管理、全局鎖、分佈式會話和集羣狀態管理等。Spring Cloud的核心是原來在 Netflix 公司內部普遍使用、通過實踐考驗、很是成熟的微服務框架——Netflix OSS，因此，Spring Cloud一度吸引了不少人的眼球。

基於K8S的容器平臺

在Spring Cloud以後成功的微服務架構基本都與容器技術掛鉤了，其中最成功、影響也最大的當屬Kubernetes平臺了，與之類似的還有Docker公司推出的Docker Swarm（在2017年年末，Docker Swarm 也支持Kubernetes了）。

對比Kubernetes與IceGrid，咱們會發現二者有不少類似性。

每臺主機上的Kubelet Daemon進程至關於Ice Node守護進程。
Kubernetes API Server進程至關於Ice Registry。
每一個運行的容器至關於一個IceBox進程。
Kubernetes中的微服務Service至關於IceGrid中的Service。
Kubernetes的YAML資源定義文件至關於ICE中的grid.xml。
kubectrl客戶端命令行工具至關於Icegridadmin工具。

Kubernetes與IceGrid在微服務架構基礎設施方面有如下兩個顯著區別。

Kubernetes沒有提供一個用於服務調用的「RPC框架」，這樣的好處是任何語言和網絡協議（只要是TCP/UDP之上的協議）均可以在Kubernetes微服務架構平臺上建模與運行，缺點是缺失的這一層須要應用本身去解決。
Kubernetes裏的服務路由與服務負載均衡是經過「代理」來實現的，便是由位於每一個Node節點上的kube-proxy來完成的，而非客戶端的負載均衡機制。

那麼，在採用微服務架構模式後都有哪些好處呢？以下所述。

經過把巨大的單體應用分解爲多個微服務組件的方式解決了複雜度的問題。在功能不變的狀況下，整個應用被分解爲多個基於接口驅動的可獨立設計、施工的子工程，這樣一來，每一個微服務工程的規模變小、功能內聚，技術相對單一化，更容易去理解和並行開發。
微服務架構使得每一個服務均可以由專門的開發團隊並行獨立設計、開發、升級及運維，開發者能夠自由選擇開發技術甚至開發語言，以更好地實現目標。最爲關鍵的是，這種自由意味着開發者不須要被迫使用該項目在一開始時採用的過期技術（好比3年前的舊框架），能夠選擇如今主流或流行的新技術。甚至，由於服務的功能相對簡單、單一化，代碼量並不複雜，也不難準確理解服務的業務邏輯，即便用如今的技術重寫之前老舊的代碼也不是很困難的事情。
微服務架構模式能夠作到每一個微服務獨立部署，這種改變能夠加快部署。開發者再也不須要協調其餘服務部署對本服務的影響，UI團隊能夠採用A/B測試，快速部署新版本以加速測試。微服務架構模式使得持續化集成與發佈部署成爲可能，所以DevOps的實施在更多的時候須要首先將系統微服務化。

咱們知道，任何技術都有兩面性，即優勢與缺點並存，那麼，微服務架構的最大缺點是什麼呢？

答案是大大增長了開發工做量並帶來了固有的複雜性。好比，開發者須要掌握某種RPC通訊技術，而且在

客戶端的邏輯中增長遠程服務的調用代碼，在某些狀況下，他們必須經過寫代碼來處理RPC速度過慢或者調用失敗等複雜問題。

相對於在單體應用中僅需在編程層面進行方法調用就能夠訪問其餘服務，微服務架構中的服務調用方式則顯得更加複雜和難以捉摸。所以，一個單體應用或者簡單的分佈式系統要想完全微服務化，其代價仍是很大的。

所以企業在判斷本身的應用是否須要微服務化的時候，須要綜合考慮應用的重要性、改造的代價與收益、技術風險等，綜合考慮是否有必要將某個單體應用或者通常的分佈式架構應用改形成微服務架構的應用。畢竟，改造是有成本的，並且改造完畢以後，也沒法保證可以解決全部問題。

咱們知道，在當下而言，微服務基本上是和容器綁定在一塊兒的，微服務化以後的應用通常而言是須要運行在容器上的。而一個具備必定規模的單體應用，微服務化以後，可能對應成百上千個微服務，這些微服務的資源調度、更新發布、運維管理、銷燬回收、自動擴縮容等等綜合起來會變成一個很龐大的工做量，如何應對呢？

答案是使用K8S爲核心的構建的容器平臺，來進行總體的用來支撐微服務化應用的容器的管理。這裏面涉及到資源的管理，例如計算資源、網絡資源、存儲資源、鏡像資源；同時還涉及到微服務應用層面的管理，例如應用的建立、應用的部署管理、應用的彈性伸縮管理、應用的日誌管理和監控管理；另外，還包括與其餘流程或者工具鏈的打通，好比與DevOps流程的集成和打通，與企業現有日誌管理平臺的集成與打通，與企業監控和告警平臺的集成與打通，與企業備份系統的集成和打通，以及與企業的大數據、數據挖掘等平臺的集成與打通。

事實上，在騰訊藍鯨研發運營一體化平臺中，已經集成了基於K8S深度定製的容器管理平臺，而且該平臺與藍鯨總體PaaS平臺的其餘功能模塊，好比CMDB、做業平臺、編排引擎、大數據平臺、管控平臺、DevOps工具鏈等原生集成，構建了針對容器和微服務應用生命週期管理的完整工具箱，助力企業實現容器和微服務應用的全方位管理。

在後面的文章中，將與各位討論，基於K8S的容器平臺是可以實現哪些方面的管理，以及是如何實現的。