這是遠傳電信Kubernetes平臺的架構,最上層是管理主控臺Ku8 Manager,中間是兩個Kubernetes叢集,底部是共用儲存區,以及負責事件記錄接收與儲存的大數據系統、整合系統事件的監控系統。(圖片來源/謝逸凡)

經歷過伺服器虛擬化、雲端服務,以及容器(Container)等浪潮的洗禮,如今我們已開始邁入多雲、混合雲的環境,然而,為何應用系統平臺的發展必須持續追逐這樣的趨勢,而且,每隔幾年就可能需要轉進新的架構?在遠傳電信IT基礎架構轉型的過程當中,我們看到了答案。

而在今年的Kubernetes Summit大會當中,遠傳電信也首度對外透露,他們如何從三層式(3-tier)架構、服務導向架構(SOA)架構,一路轉換到微服務(Microservices)架構。原來,一切的決策考量,都源於「擴展(Expansion)」,尤其對於臺灣的電信業者而言,從逢年過節的車票搶訂、知名品牌智慧型手機的大量預購,到2018年的行動網路499元吃到飽之亂,都造成極大的業務營運挑戰,他們也持續思考IT架構該如何配置,才能因應時間短暫、負載龐大的系統執行需求。

快速、大規模、簡便的擴展,成為企業應用系統架構變革關鍵

關於微服務,以及容器、Kubernetes等新興IT技術的導入,今年,臺灣終於有大型企業公開實際應用的經驗,例如,遠傳電信經理謝逸凡在9月的Kubernetes Summit大會,首度揭露他們IT架構轉型的歷程。

近年來,IT基礎架構的轉型,主要聚焦的部份,在於擴展、可用性、敏捷,而遠傳電信的IT環境,從原有的大型主機,陸續開始採用x86運算架構、伺服器虛擬化、私有雲、容器、公有雲,如今走向混合雲、多雲、雲端原生的架構。

在此同時,他們對於採用雲端服務的態度,也更為積極。因為在這樣大型的業務活動期間,原本資料中心預留10%到20%的系統資源,在那時幾乎全部都用上了,卻仍不夠用,導致許多消費者在申請時,還是得不到門號,他們必須要在一兩天之內,將系統資源擴增到原有的5、6倍之多,才能因應暴增的需求,所以,他們積極評估採用雲端服務的可行性,並且認知到每一朵雲各自的特色,於是,遠傳電信今年開始有混合雲、多雲的解決方案。接著,他們在2012年開始採用伺服器虛擬化的架構,而隨著虛擬機器(VM)部署規模的日益龐大,之後也導入一些自動化管理的機制。到了2017年,遠傳電信開始採用容器架構,原本他們想透過這樣的方式來取代伺服器虛擬化,節省伺服器虛擬化授權,但後來發現容器並不能取代虛擬機器,而在去年499行動通訊方案席捲市場之際,他們也試著用容器架構來支撐暴增的工作負載,雖然當時並沒有成功,但也讓他們意識到需要同時注意其他的環節,例如資料處理的方式(資料庫的分割、資料讀寫負載的分流、快取的配置),才能充分發揮容器架構的特性。在這段期間,他們首先面臨的挑戰,在於大型主機建置成本昂貴,而且只能縱向擴展(Scale up),若要擴展底層IT基礎架構的規模,也需要長時間的預算規畫、提案,後來,隨著x86架構的盛行,改用大量x86伺服器來擴充資源。

回顧這段轉型的歷程,遠傳電信經理謝逸凡表示,這一路走來,他們每天都在做的事情,就是擴展(Expansion),每遇到一個資源瓶頸點,就必須要設法跨到下一步,一關關突破。換言之,IT人員面臨的挑戰在於,如何擴展既有資源,讓上層的應用程式和服務,能夠快速而順利執行,保持可用性與穩定度。

因此,他們持續投入IT基礎架構底層的建置、系統平臺的建置,都是為了承載上層應用程式或服務,做到執行規模的瞬間放大或縮小。

然而,在不同時期所採行的IT基礎架構,皆有其相對的優勢。例如,在採用專屬伺服器架構的時期,從提案到實際部署完成,可能長達幾週,甚至幾個月,而且需同時考量的因素,最為複雜,包含硬體、作業系統、執行時期環境,以及程式碼;到了伺服器虛擬化、私有雲的環境,部署時間可縮短至幾天、幾小時,甚至幾分鐘,而且,不需考量硬體的相依性;而在容器的應用架構裡面,程式碼寫好之後,最快能在幾秒鐘的瞬間,完成應用程式的部署,又進一步擺脫作業系統的影響。

遠傳電信的應用系統架構,經歷了幾次變革,先從大型主機/主從式架構,換到三層式架構,之後,改用服務導向架構,近年來,他們也已經開始導入微服務架構。在這三種架構之下,應用系統的元件有不同的粒度與耦合度,在規模擴展與管理的難度上,都有不同的挑戰。(圖片來源/謝逸凡)

為了擴展規模,將應用程式拆成多個微服務也成考量點

導入伺服器虛擬化、雲端服務的環境,雖然為用戶提供快速擴展IT基礎架構資源規模的方式,再加上虛擬機器、容器的採用,也能帶來快速部署應用程式的成效,但就整體服務而言,若要穩定擴展規模,應用系統架構仍需調整。

以三層式架構而言,應用程式本身是緊密耦合的,以一套系統適用所有需求,程式碼修改較為困難,在應用程式發行、測試的步驟,會耗費許多力氣,若要擴展系統規模,作法也相對複雜。以遠傳電信而言,他們的應用系統在這段期間,已陸續經歷了幾次轉型,從過往的大型主機主從式架構、三層式架構、服務導向架構,如今則是繼續朝微服務架構邁進,而之所以改弦易張的關鍵,仍在於擴展能力的優劣。

到了服務導向架構、企業服務匯流排(ESB),應用程式是鬆散耦合的,拆分為多個元件,粒度較適當,利於服務重複使用,快速支援業務需求。然而,這類架構採用的協定,像是WSDL或是SOAP,效能不太理想。此外,應用程式存取資料來源,仍是同個資料庫。

在近幾年盛行的微服務架構,應用程式拆分粒度更細緻,且是鬆散解耦的(Loosely decoupled),不單將系統拆分、重新安裝多份、重新部署,還要有獨立運作、無狀態(stateless)、自我管理、去中心化(decentralized)等特性。

然而,相較於既有應用系統的單體式架構(Monolithic),雖然體型龐大,不易擴展,但好處是只需要考量單一實體,若把應用系統拆開成多個微服務,因為需要彼此相互呼叫,對於狀態與資料存取的需求也不一樣,將導致管理複雜性和維運難度變高的狀況。

因此,若要將應用系統拆分為多個微服務,該如何切割,執行起來才會順暢、理想,是許多開發人員面臨的重大挑戰。遠傳電信採取的作法,是先針對應用程式的運算部分,接著是處理資料層,此時會遭遇到非同步模式與狀態不一致,或是狀態、功能切分得不夠精細,因此也會涉及事件的處理。

等到應用系統開始建立之後,他們開始處理開發與維運的流程(Pipeline),因為系統完成開發好、進入穩定執行的狀態,接下來,該如何持續修改、調整,使其保持妥善運作,又是個挑戰。

而在上述的工作階段當中,如何擴展需要的資源也很重要,因為當本地端資源不足時,我們要懂得運用多個資料中心的資源,並在這樣的環境布建服務。

建構微服務的要點

要該如何切分微服務?因為資源有限,很難把應用系統的所有功能拆掉,基本上,還是回到原點:我們需要的是擴展性?快速?穩定?可用?謝逸凡以他們本身需求來說明,以門市運作而言,像是確認消費者能否購買、決定用戶是否有續約資格,都是最常使用的核心功能,若將這些改為微服務,效果最為顯著,至於其他功能不一定要在第一時間改成微服務,因為需求量相對少。

基本上,應用系統若切得越細、分割得越多,雖然可以擁有越好的彈性,但是,管理複雜度也會越來越高,導致管理成本可能超過開發成本的狀況。因此,面對微服務的粒度該如何取決的考量,謝逸凡表示,應該要在自身的管理能力與切割程度,找到平衡點,因為,相關的監控機制如果沒有到位,卻硬是切割出來,一旦運作上出問題,就很難復原,等於陷入另一個風險。

所以,他也認為,建構微服務不能想要一步到位,這麼做耗費的資源太大,後來會無法執行下去,應該要謹慎為之、逐漸轉換,可先從應用系統著手切割,再處理資料,再處理後面的事件。

之所以會有這樣考量,謝逸凡坦言,這是他們內部討論出來的作法,因為既有系統太多,需要逐步轉換,但這還是需要很多額外的資源,而且,還要從底層去調整架構。所以,他建議,可以各個擊破,「先建後拆」,把關鍵服務慢慢抽出來,等到看到成效之後,大家才會去想要修改舊的部分;而且,有些舊服務並沒有高速擴展的需求,在原來的架構還是可以執行,因此,企業不用花太多資源去改成微服務。

當應用系統改成微服務架構,執行方式會有哪些改變?會有API呼叫的請求,啟動幾個微服務,由API Gateway做服務管理,進行Service Discovery的程序,了解微服務的狀態與服務等級;而在微服務之間,是透過RESTful API呼叫來互動,也可能有推送或訂閱(Push and Subscribe)的非同步作業,將記錄發布至事件佇列(Event Queue),或從這裡取得記錄,然而各自執行各自的服務;而在資料存取的部分,也可能會用到資料庫或資料庫加上快取的作法。而在這樣的架構下,我們要把應用系統拆成好幾個,當中有執行狀態的轉換(有狀態改為無狀態)、API呼叫、資料流切割的程序。

在實際維運時,原本每個應用系統服務由一個開發單位負責的狀況,如今也可能會有改變。因為,採用微服務架構之後,會面對的是多個開發單位,該如何協調彼此,促進共同的控管、障礙排除、開發,所以,這也會是考驗之一。

微服務架構的組成,不光是容器技術的應用,以及應用系統的切割,在上層還有API管理、Service Discovery,以及應用程式框架,其底層則有Kubernetes平臺、網路、硬體設備的區分。同時,這樣的架構也需要搭配完備的系統監控、事件記錄,以及管理機制。(圖片來源/謝逸凡)

打破單體執行藩籬,轉為彼此協同運作的生態系統

微服務應用系統若由Kubernetes平臺來支撐,謝逸凡認為,從架構來看,最上層是應用程式的管理員,透過API來呼叫服務;接著是Service Discovery,探尋合適的微服務;下層是Spring Cloud這類應用程式框架, 再下層是Container,而Container底下會是Kubernetes平臺;到了最底層,則是網路與硬體設備。

而橫跨上述所有堆疊的功能,則是監控、記錄中心、管理,它們也扮演很重要的角色,因為當應用系統架構拆得如此分散,若要確保系統運作正常,要有很強大的監控、很詳盡的事件記錄,支撐整體架構的維運,如此也能做到集中化管理。謝逸凡表示,如果沒有這些機制,很難同時管理眾多微服務,以及持續更新軟體版本,提供穩定運作環境。

而經歷過這樣的變革,謝逸凡體認到,微服務的運作體系,並非一套獨立的應用系統,而是依靠好幾個部分一起協同運作,轉為生態系統的概念,因此,在這樣的架構之下,一個應用系統無法單獨存在,一定要互相合作。

相對地,若要維運和管理這樣的環境,也會變得很複雜。謝逸凡說,微服務化的應用系統可以執行得很順暢,一旦出問題,恐怕很難快速找到根本原因,因為它不是單一的軟體,若有影響,就會是全面的,所以,我們必須設法觀察資源的瓶頸所在,關注如何建立監控機制及整個維運體系。

當微服務結合K8s平臺

應用系統經過容器化、微服務化,實際運作在Kubernetes平臺,整體架構會變得如何?謝逸凡介紹遠傳電信的作法,他們用社群維護的Kubernetes版本,並在Intranet和DMZ兩個網路區域,建立叢集,共用容器映像登錄。

除了運用Kubernetes本身的API,他們也撰寫工具,協助部署與資源的管理。面對檔案交換的需求,他們也設置了共用儲存池。而在監控的部份,他們用了Kafka來接收事件記錄,然後交給ELK(Elasticsearch, Logstash, Kibana)處理,同時,這裡也運用Prometheus軟體來接收Kubernetes平臺,以及上層系統的重要資訊。

對於容器映像的管理,遠傳電信採取比較嚴謹的作法,他們不允許開發人員隨意到網際網路下載,須使用公司驗證過的容器映像,而他們也將列管的容器映像,根據用途的差異,區分兩大類型——維運(Operation),以及生產(Production),並且檢查當中的安全性,做好存取控制,例如,確認是否潛藏惡意程式,以及開放哪些作業系統層級的使用者存取通道。

此外,為了提升容器映像的適用性,符合開發、維運、測試人員的需求,遠傳電信也對環境變數的設定做了一些處理,當中運用ConfigMap的組態資訊來對應,達到參數化的設計,讓容器映像執行起來更順暢。

在資料處理的部份,也要特別注意,遠傳電信的經驗值得借鏡。他們在因應499行動上網吃到飽的業務暴增需求時,就曾使用微服務與Kubernetes,當時,應用系統已妥當分割為微服務,部署到Kubernetes平臺,Kubernetes系統規模的擴展很順利,容器也順利建立起來,最後卻因資料庫存取方式的限制,而無法承擔負載,還是敗下陣來。

對此,他們採取了3種作法來改善,分別是資料庫分割(Database Partition)、讀寫分流(Read/Write Splitting),以及快取(Cache),以便分散存取的I/O。

結合容器與K8s的開發與維運流程

當應用系統的整體架構建立起來,資料庫的分散存取也導入適合的作法,接著要考量的部分,是規畫可持續運作的DevOps流程,能夠整合、更新應用系統,並且維持系統的穩定運作,協助用戶執行持續交付、持續整合、持續測試、持續維運的所有工作。

遠傳電信DevOps流程是怎麼做的?以部署應用系統的作業為例,他們提供兩種作法,一是將程式碼打包在容器映像當中,一是將程式碼和容器映像分開,程式碼會放在共用的儲存空間,直接掛載到容器,再執行應用系統。

而在應用系統開發過程當中,若要進行持續整合、持續交付,遠傳電信也區隔出系統整合測試(SIT)環境,以及生產環境,分別設立對應的容器映像登錄,以及Kuberenetes叢集,位於系統整合測試階段的應用系統(容器映像),必須經過一定的預先部署、測試、更版等程序,才能將同步到生產環境,進行部署與上線切換的動作。

在容器映像的部署方式上,遠傳電信Kubernetes平臺提供兩種選擇:一種是包含程式碼,另一種是不含程式碼,可用於開發、測試、生產等不同階段的環境當中。(圖片來源/謝逸凡)

 相關報導  企業K8s實戰在臺灣 


Advertisement

更多 iThome相關內容