2千萬行開源專案為何用微服務，OpenStack工程副總裁談微服務架構難題

開源IaaS OpenStack在今年高峰會上，OpenStack基金會營運長Mark Collier就強調組合式開放基礎架構與原生雲端應用的重要性，重新定位OpenStack，擺脫過去只是提供VM運算服務開源IaaS的既定印象，更要升級變成綜合各類開源元件的創意平臺。

這樣的架構新主張，其實與微服務所強調雲端原生、元件可重複性等特性不謀而合。架構日漸複雜的OpenStack，已從最基本的運算、網路及儲存元件向外發展，推出更多樣化的功能模組，支援大數據、容器調度及機器學習等應用。而OpenStack本身就是個複雜結構的應用程式，也導入了微服務開發的概念，由許多功能相異、各自可獨立水平擴充的服務。而這些模組再往下劃分，亦是由更基本的元件組成，彼此可以互相調度、溝通。

目前OpenStack基金會在開放原始碼平臺GitHub專頁中，其管理的專案儲存庫超過1,500個，從2010年誕生至今7年，程式碼規模已經超過2千萬行，背後支援OpenStack專案的企業也有666家。在正式環境導入OpenStack專案的組織，除了知名企業PayPal、Walmart及福斯汽車外，也不乏公立機關如歐洲核子研究組織（CERN）及英國稅務海關總署。

主導OpenStack技術發展走向的OpenStack基金會工程副總裁Thierry Carrez，分別在基金會內擔任過工程總監、技術委員會主席。在進入OpenStack基金會前，除了任職輪胎大廠固特異IT經理，更在Linux作業系統廠商Canonical擔任Ubuntu伺服器團隊技術總監。我們也訪問了Thierry Carrez，請他分享究竟OpenStack的專案開發如何導入微服務，以及他對微服務的看法。

 Q  企業要如何利用微服務進行架構轉型？

 A  導入雲端科技只是一部分，轉型還包含了企業文化的改變，不單只有技術而已。像保險、銀行業內部有許多老舊IT系統，但這些系統不能停止運作，例如薪資系統、報稅系統，它們由一層一層規則所堆疊，還有一堆例外條件要處理，全部替換除了技術上困難，成本也很高。

因為金融業是高度管制的行業，某家法國銀行利用OpenStack，一併整合新舊IT系統，除了能存取大型主機應用程式，也可以連接外部的雲端服務。如此一來，不僅讓既有內部IT架構維持完整，也不需要改變現有的網路、資安架構。在微服務轉型上，我們看見企業會保有老舊的單套式（Monolithic）系統，同時利用微服務建構新興網頁應用程式，並且讓兩方建立溝通。單套式架構未必需要很敏捷，因為它太老舊，很難釐清該系統的運作方式，只有推新服務才很講求速度。因此，前端系統往往是最先支援雲端技術。

 Q  未來OpenStack也會擁抱微服務或雲端原生的IT架構嗎？

 A  OpenStack本身是一個很複雜的應用程式，由許多不同的服務組合成，像是Nova（運算）、Neutron（網路）、Cinder（儲存），各自也可以水平擴充。而這些模組，也是由許多可互相溝通的小元件組成，彼此可以互相調度。

所以，OpenStack本身就是一個微服務架構，也因此，可使用一些容器調度工具如Kubernetes調度這些服務。

現今有些企業想要讓這些元件在非OpenStack環境執行，例如，讓Cinder、Neutron、Keystone等元件在Kubernetes環境執行，所以OpenStack基金會也必須提高這些模組在基礎架構層中的可重複使用性。

談到雲端原生應用程式的開發，OpenStack的目標是給予開發者多重選擇，例如使用VM、容器交付服務，或是支援Kubernetes、Mesos等容器調度框架，讓企業選擇最適合自己的技術。

就如OpenStack基金會營運長Mark Collier所說，OpenStack是開放基礎架構，新興技術會不停地推出，OpenStack必須支援不同的技術，才能滿足應用程式開發者。例如，當今容器技術的使用需求火熱，但是未來可能又朝Unikernel、Microkernel發展。

 Q  OpenStack專案開發也有導入微服務架構的想法？

 A  沒錯，OpenStack的專案開發都有導入微服務的想法。不過我們也有碰上一些困難。舉例來說，要讓OpenStack雲運作，必須要有資料庫、訊息佇列（Message Queue）這些基本服務。但是如果要想擴大規模或調度分散式服務，這些元件的功能還不足提供某些功能，像是跨節點的網路路由任務。因此，OpenStack需要一些元件，可以負責調度任務，或是橫跨系統執行組態設定。

但是我們發現，OpenStack專案開發犯了重新打造輪子的錯誤，想要重新解決一些他人過去曾碰上的問題。這也讓OpenStack基金會開始思考，如果OpenStack要變成一個雲端原生應用平臺，究竟還缺乏哪些技術。

過去OpenStack基金會並不認為這些事情很重要，但最近我們開始想納入一些開源工具，也把此需求上呈到OpenStack技術委員會。例如，在5月時，OpenStack就決定把ectd整併至其架構中。

透過etcd，Cinder模組有相當大幅度的升級，像是不同的VM可以同時存取一個儲存元件，未來Nova元件也會整合etcd。

 Q  用微服務有什麼代價？

 A  其中一個代價就是複雜度。以單套式架構而言，當所有系統都部署在同一個資料中心時，開發者很清楚系統的運作機制。但是微服務是由許多互相溝通、彼此牽連的服務組合而成。

雖然微服務讓開發單一元件更簡單，但是開發者最終得面對一個極其複雜的IT系統。因此，必須要有一個監控平臺或機制處理複雜度的挑戰。以自身經驗出發，我以前相當熟悉網路架構的機制，但現在Neutron模組變得非常複雜，連我也必須很努力，才能弄清楚它的運作。

複雜度的挑戰永遠都在，分散式系統的本質就是如此。現在也陸續有開源專案在解決這些問題，像是Kubernetes除了可以調度、部署微服務外，也能讓它們水平擴充。但我認為，現在還需要一個應用程式層，用於除錯、分析及監控這些微服務應用程式的運作。因此，有些組織會選擇一併使用單套式及微服務，因為它們知道單套式架構結構簡單帶來的好處，但同時，這些企業也想有能力建置各類功能單一的元件，用於架構複雜的微服務應用程式。

 Q  OpenStack跟其他微服務平臺定位上的差異？

 A  以OpenStack的角度出發，開發者永遠都需要IaaS，相比其他人比較專注於應用程式開發者，OpenStack的定位是基礎架構提供者，以此為基礎，讓應用程式開發者可以架構其他解決方案。

OpenStack並不會與Kubernetes或OpenShift競爭。反之，這些廠商也不想與我們競爭，因為它們並非鎖定解決基礎架構的問題。例如，Kubernetes的運作，仍然得靠公有雲AWS、Google等，或是私有基礎架構VMware或OpenStack。

因此，OpenStack的任務在於，簡化Kubernetes在OpenStack上部署的困難，讓開發者進一步能打造機器學習應用程式、無伺服器平臺，或是利用容器建立多租戶架構。

 Q  微服務有什麼好處？

 A  微服務的主要好處是讓開發者自行決定IT架構的規模，無論是大規模部署，或是小規模部署都可以，這是它的重要優點。

開發者也能針對特定服務，獨自水平擴充，或是獨立更新某些系統元件，讓開發流程變得更加敏捷。

不僅如此，微服務也適合用於邊緣運算的小規模應用情境上，讓應用程式可以部署在規格普通的硬體裝置上執行。但邊緣運算應用需要高度客製化的開源軟體才能解決這些問題，不太可能仰賴VMware、AWS這類廠商的龐大解決方案。所以我認為，OpenStack在邊緣運算有新機會，現在我們也有專門的邊緣運算工作小組在規畫相關事宜。