經歷過伺服器虛擬化、雲端服務，以及容器（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實戰在臺灣
.jpg)
