淺談微服務架構、容器技術與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的容器平臺是能夠實現哪些方面的管理，以及是如何實現的。

藍鯨平臺試用Tips

藍鯨社群版

如果您想先簡單瞭解藍鯨研發運營一體化平臺，或者企業規模較小但想用更為先進的自動化運維管理方式進行IT運維管理，推薦您先試用藍鯨社群版。

藍鯨社群版已經開源，您可以登入藍鯨智雲官網免費下載。網址：

http：//

bk。tencent。com/download

/

藍鯨企業版

當然，藍鯨企業版擁有更為豐富的功能，更適合企業級客戶使用。如您有需要試用或者測試，聯絡嘉為吧！​​​