IBM邵萍：數字化重構傳統企業IT架構

【IT168&ITPUB專稿】本文根據邵萍老師在2018年10月17日第十屆中國系統架構師大會(SACC2018)現場演講內容整理而成。

講師簡介：

邵萍，2003年加入IBM中國軟體研發中心，先後擔任工程師，開發經理及產品經理等職務，專注領域包括應用伺服器、Java EE技術及雲端計算。

正文：

隨著企業資訊化的深入發展，雲已成為諸多企業的核心戰略。尤其是私有云，已佔據企業重要位置。

根據Gartner以及IDC的資料顯示，傳統IT市場的增長率正在逐年下降，而以雲IT和認知技術為代表的新興市場，增長率則非常高。從IT形態來看，傳統的IT架構正逐步被雲架構、微服務模式取代。我們無需再去解釋什麼是雲，很多客戶都已經有了上雲的規劃，有的甚至已經有了長時間的雲運營經驗。所以，雲一定是IT的未來。另外，雲還會和一些新技術掛鉤，包括認知計算、智慧化解決方案等。只有這樣，才能讓技術引領業務創新。

雲時代的IT架構變化

那麼，雲時代的IT架構有哪些變化?雙態IT模式，是現階段的典型特徵。

經過幾十年的發展，傳統IT已經積累到一定的量級，我們不可能一下子全部拋掉，完全轉入新的應用。如何在保護已有投資的前提下，重構過去的IT架構，向雲端遷移?如何把認知計算、區塊鏈、物聯網等新技術納入現有IT體系?如何透過技術發展，去推動企業業務的轉型?如何透過小而美的微服務，透過雲原生應用，以及DevOps流程，實現快速迭代?這些都是我們必須要考慮的新課題。

雙態IT模式，即混合IT架構。以某銀行客戶為例，System of Records是企業的心臟，是最核心的業務架構，確保所有交易可靠、穩定和高效。但是，只做到這一步還不夠，如何透過提升使用者體驗，透過更理想的互動形式，讓業務更敏捷?我們要去構建企業的神經和大腦，讓所有資料互聯互通。

如今，很多銀行都在做AI，透過認知計算技術，我們可以給客戶畫像，做智慧的貸款分析等。這其實就是在構建企業大腦，透過技術手段去思考業務邏輯。

當然，企業要想實現敏態IT，實現數字化轉型，只改變架構還不夠，整個企業都要進行調整。以IBM軟體開發轉型的十年曆程為例。2013年，IBM有 Product Manager產品經理職位;現在改為Offering Manager。為什麼會有這樣的變化?

以前產品的經理，看的是產品的生命週期，每個版本要做什麼，如何向前推進。現在，只管產品還不夠，產品要包含服務、實施以及市場等等內容，是一整套的解決方案。另外，就是軟體的交付週期，由之前的3個月/半年/1年，轉為現在每月/每週/每日，並且要有持續整合的能力。開發模式由最早的模敏開發捷式，轉為現在的Design Thinking 設計思維。這種模式比敏捷方式更先進，會使用者畫像、頭腦風暴等方式，去思考和設計我產品。並且，能快速釋出，快速試錯，快速跟進和演進。還有軟體開發角色、技術能力的培養、組織結構以及員工績效考核等，都發生了巨大的變化。

應用上雲的策略與考量

那麼，針對具體應用的雲化，該從何處入手?

從很多客戶的轉型歷程來看，其實上雲過程基本經歷了三個階段：

第一階段：1.0 Efficient Infrastructure基礎架構平臺。

第二階段：2.0 Modern Applications。所有應用都在雲上，有著非常成熟的PaaS平臺的支援。但是，依然從IT視角考慮問題。

第三階段：應該是從業務視角來考慮問題。即3.0 Re-imagined Processes階段。要藉助新技術手段重構以往的業務價值，比如：把認知能力納入企業業務當中。此時，雲平臺已經具備足夠的技術支撐能力，能打破企業邊界，重構一個生態。

其實，企業上雲的時候，會把所有應用進行分類。因為，並不是所有應用都適合上雲。有些應用執行得很好，很穩定，目前企業也沒新的業務需求，那就不必做什麼更改，保持當前執行狀態就好。一個企業大概會有20~30%這樣的應用。對於這類現存應用，企業一般不做修改，重點是平臺標準化與自動化，降本增效。另外，企業有70~80%的應用，需要繼續往前走，需要藉助現代化技術，實現遷移改造，利用新型平臺與技術實現雲化。 比如：遷移到容器雲平臺，對整個架構做一個微服務化的改造。最後，就是所有新應用，必須透過新技術、新架構去開發。

如何上雲?

那麼，傳統Web應用到底如何上雲?以IBM某大客戶為例，這家企業基於IBM中介軟體上的傳統開發，已經有十三、四年的歷史了。應用體系龐大，整個架構更是盤根錯節。他們希望繼續透過IBM的技術去做一些改造，幫助他們上雲。

這家企業原來的產品執行在傳統的WEB伺服器上，體量相對較大，有很多應用更適合透過雲平臺去解決一些問題。比如：負載均衡、資源池化、動態的擴充等等。但是，企業一旦上雲，整個架構就要重新做切分。如何把傳統的應用伺服器做容器化的一個改造?這是企業發展的必然之旅!

首先，我們為什麼要轉向新型的應用伺服器?企業進行了綜合評估。由於架構龐大，當系統加入一些新的功能的時候，幾個G的一個應用要經過長時間的測試，才能夠穩定下來。因為，每次新加的程式碼，都有可能要替代之前的程式碼，程式碼演進效率很低。

其次，企業的應用要承載一些新型的、類似於網際網路業務的壓力。比如：雙11，銀行要在背後提供快捷支付功能，來保證雙11交易。企業發現：雙11的時候，尤其是12點鐘一到，交易量開始呈爆發趨勢，迅速上升。如何透過敏捷應用進行彈性管理?傳統的中介軟體顯然無法滿足需求。

以2017年為例，這家銀行的快捷交易峰值壓力達到了1萬筆，需要大規模的叢集去支援峰值。傳統應用伺服器，很難快速擴充套件為幾百個節點。並且峰值結束後，還要收縮回來。所以，IBM當時推薦了WebSphere Application Server新一代應用伺服器，後來演化到Liberty。

在轉型期間，這家企業對不同應用進行了試用，最終發現Liberty的好處。Liberty是一個企業級應用器，不管是從效能來講，還是從支援力度來看，都比開源要好很多。對於傳統伺服器來說，Liberty無疑帶來了顛覆式革命，等於把原來的架構全部打散、重寫，是一個可熱插拔的結構。

我們都知道，一個Web應用，用到的只是其中的幾條，比如一個Servers的應用。但是如果我用傳統伺服器，可能我所有的功能都要記起來。但是Liberty不是。如果我是一個很簡單的Web應用，我只需要支援它的功能集就可以了。一個簡單的Web應用，包含我們的Web應用伺服器，大概六七十兆就可以執行起來。它的安裝包也很小，可以根據你的需求，再決定要不要去增加更多新模組支援。這樣的業務場景和雲平臺天然適配，尤其是企業級業務平臺，如何去支援這種小而美的快速迭代、快速伸縮需求?需要我們重新來審視。我們需要用雲平臺來管理整個應用的全生命週期，不再透過伺服器本身去做這種負載均衡、彈性伸縮等等工作。

Kubernetes帶來哪些價值?

上了容器化的一個新型的雲伺服器後，我們要考慮去用容器化的方式去部署應用。提到上雲，我們首先想到的都是 IAAS層。但是，因為虛機技術有其特殊性：涉及Hypervisor，有Host os這一層，資源消耗非常高。容器更具輕量級的特點，不管是系統啟動速度，系統資源消耗，還是效能、併發性等，都有更出色的表現，Liberty on Docker成為必然發展趨勢。

容器是用來管理微服務，需要對之前的應用做一個更細粒度的拆分。之前，一個應用拆成20個、30個微服務很正常。每個微服務還要牽扯它自己的彈性伸縮，有的可能達到幾百個幾千個。這樣的微服務如何去管理?一定要有一個容器編排平臺，比如：Mesos、Swarm。其實，我們之前有很多技術選擇，但是今年態勢非常明朗，基本上就是Kubernetes，不管是從客戶角度看，還是從友商角度看，Kubernetes都是一個主導性的技術方向。

Kubernetes能幫企業做什麼呢?

首先，大量的容器怎麼去管理?比如：我要釋出一個應用，這個應用應該如何在上千個容器的資源中去放置?放在哪裡?哪個是最合適的資源?放了之後如何去做負載均衡?一旦一個容器壞掉，不接受請求了，如何能夠快速替換?以及我有一些應用釋出，應該怎樣進行回滾?還有，其他的服務治理的一些功能，應該如何處理?Kubernetes的技術發展得非常快，IBM推出了自己的基於容器的一個技術，基本上各大廠商都在推出自己相關的PaaS的容器雲平臺。

有了Kubernetes，如何去支援企業的生產環境?其實這是一個值得探討的問題。因為畢竟Kubernetes是一個開源的架構，在生產環境裡有很多企業級的運維需求。IBM容器雲平臺會去支撐這種異構硬體系統。但是我們發現，不是所有的客戶都已經到了容器就緒的狀態，它可能有一些傳統的應用，會在虛機上執行很多時間，或者說不會只選擇一家雲廠商，可能還會有很多雲廠商，以及其他的雲平臺。我們需要把它整合管理起來，所以我們還有一個多雲管理元件，能把其他雲代管進來。我們還做了很多企業級的增強，去幫助客戶去在企業的環境裡面去執行容器雲。我們說的Pass級雲平臺，不僅僅只是中介軟體這層，還包括相關的服務。IBM把之前的傳統配件去做容器化，放在雲平臺上，作為開箱即用的中介軟體服務，提供給客戶。

在雲端如何實現DevOps ?

另外，IBM在支援新型的雲應用的時候，希望能夠用DevOps的方式來做微服務應用的構建、釋出、測試、上線、回滾等等這一系列流程，IBM會提供與DevOps相關的工具。

總體來說，其實企業級的生產環境需要很多額外的技術支撐能力。比如：日誌能力。每一個容器都會產生自己的日誌，當體量達到上千個節點的時候，這些日誌如何去管理?如何快速檢索、排查，生成意義的資訊?這些都是關鍵點。還有監控，企業需要實時地看到所有容器當前的執行狀況，是不是處於一個健康的狀態，有沒有出現什麼問題?針對這些問題，IBM做了很多工作，鋪設了更強大的企業級監控、運維工具。

再比如：計費計量問題。傳統軟體產品的買賣方式就是賣許可，買了就是永久性的。但是雲平臺計價模式不一樣。我們可以按小時的方式去進行計費，透過計量功能區評估客戶用了多少資源。

還有，容器雲平臺上會有大量的Image產生。有容器產生的，還有客戶自己的、第三方的、有官方的等等。這些Image可能會有一些安全漏洞，所以IBM會提供一個Image掃描的工具，來保證你的Image在雲端的安全性。

另外，很多傳統客戶用傳統應用上雲的時候，有很多挑戰。首先，這個應用適不適合上雲，上雲的難度有多大，能不能根據現有應用給出一些建議?所以在IBM雲平臺上，能透過應用工具去掃描客戶的應用。比如：傳統的Web應用，我可以看到你現在所有的Code裡面用到了哪些架構，我會告訴你，上雲的技術匹配度是什麼樣，這裡面有多少原始碼能繼續使用，哪些程式碼需要做一些更改。IBM雲平臺整合了大量的專家經驗，幫客戶去做程式碼的匹配，能給使用者提供一些輔助的更改經驗。並且生成一個評估報告，告訴你雲遷移的難度是高、中、還是低，可能遇到的風險有哪些。

最重要的是，IBM有非常豐富的雲端的Paas服務。安裝了IBM的雲平臺之後，就會有幾百個這樣的一個雲端服務，包括：Web應用伺服器、資料庫、訊息中介軟體等等，都可以去在上面去進行安裝，就是容器化模式。在雲端，需要有更簡單的模式幫助使用者去安裝部署自動化，尤其是自動化的安裝部署，甚至回滾它的應用。IBM可以把幾十個微服務組成一個應用，以微服務的方式來進行管理。

IBM還提供了多餘管理功能，因為客戶上雲之旅不是一蹴而就的工程，需要一箇中間段的過度，容器和虛擬化技術可以幫助客戶走過共存階段。IBM還提供了完整的DevOps開發運維一體化流水線工作的支援。

如何看待開源技術?

其實，IBM雲平臺底層很多技術都是開源的技術，不管是Docker，還是Kubernetes，甚至是多雲管理，他要用一個開放的介面去整合第三方語言，都是一些開源的平臺。所以很多技術實力很強的客戶會問，為什麼不能用開源的架構去打造自己的雲平臺?IBM的答案是：可以。但是開源架構有很多坑。

我們看到有幾個大的客戶，尤其是一些大的銀行客戶，他是用這種買服務的方式，請第三方的廠商來幫他去建立的Paas雲。之後，由他自己去維護Paas雲的生命週期。第一個坑是，這些客戶不會長期關注開源社群，如果你要選一個第三方幫你去做的話，那一定需要第三方對這種開源社群有影響力，有一定的技術路線的掌控能力，保證你不會偏離這樣一個技術路線。開源現在發展得非常快，幾年前很火的框架，可能很快就不存在了。第二，如何才能有一個端到端的實施。因為上雲，不像傳統的賣軟體，簡單安裝一下，把應用部署完，就可以了。在沒有想清楚為啥要上雲，如何上雲這個問題之前，使用者是不會付諸行動的。所以，上雲是個複雜的過程。第三，開源的另外一大挑戰是，整合開源中介軟體也有難度。因為，搭一個Paas雲平臺，不是一兩種開源軟體就能搭起來，有時候需要7、8個開源軟體，甚至20多種開源技術。這些開源技術都有自己的社群，都以不同的步調在往前演進，如何在保證這些技術在演進之後還能跟得上?並且和其他的開源元件不衝突?需要不斷去做測試。很多客戶在兩、三年之前自己去建Paas雲，但是現在已經很難支撐了，因為更新換代是很麻煩的事情。