關注嘉爲科技，獲取運維新知
企業應用系統：從單體應用走向微服務架構；從裸金屬走向容器。
如果在諸多熱門雲計算技術諸如容器、微服務、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/
藍鯨企業版
當然，藍鯨企業版擁有更爲豐富的功能，更適合企業級客戶使用。如您有需要試用或者測試，聯繫嘉爲吧！