《為什么一家傳統券商選擇將交易系統容器化？》要點：
本文介紹了為什么一家傳統券商選擇將交易系統容器化？，希望對您有用。如果有疑問，可以聯系我們。

交易系統是命根子,為什么這家傳統券商選擇將其全部容器化?本文根據梁啟鴻在InfoQ舉辦的CNUTCon2016全球容器技術大會上的演講整理而成.

老司機簡介

梁啟鴻,廣發證券研發董事總經理首席架構師.哥倫比亞大學計算機科學系畢業,出道于紐約IBM T.J. Watson研究院,后投身華爾街,分別在紐約Morgan Stanley、Merrill Lynch和JP Morgan等投行參與交易系統研發.本世紀初加入IT界,在Sun Microsystems大中華區專業服務部負責金融行業技術解決方案.此后創建游戲公司并擔任CTO職位5年.后作為雅虎Senior Principal Architect加入雅虎,擔任北京研究院首席架構師角色.

前言

前一段時間中國銀監會在“十三五”規劃當中提到銀行業應該穩步實施架構遷移并逐步過渡到云計算架構平臺,廣發證券在這方面做了很長時間的探索.

廣發證券于2014年Docker等容器技術尚未盛行之時開始投入容器化技術的研究,并于2015年開始大規模投入應用—成交量六百億(2015年)規模的金融電商平臺、消息推送日均數千萬條級別的社會化投顧問答平臺以及日均流經交易量峰值近五十億的交易總線均被容器化；投入生產的容器化云服務包括行情、資訊、消息推送、自選股、統一認證、實時事件處理等.

從《黑天鵝》說起

我們研究和應用云技術的動機,來源于對“黑天鵝”事件的應對.“黑天鵝”這一概念,是在美國學者、風險分析師、前量化交易員、前對沖基金經理塔勒布(Nassim Nicholas Taleb)的《黑天鵝》(The Black Swan – The impact of the highly improbable)一書發表后在全球被得以高度認知.

在發現澳大利亞之前,17世紀之前的歐洲人認為天鵝都是白色的.但隨著第一只黑天鵝的出現,這個不可動搖的信念崩潰了.黑天鵝的存在寓意著不可預測的重大稀有事件,它在意料之外并且后果非常嚴重.

一個黑天鵝事件,具有這三個特點：(1)稀缺、通常史無前例(rarity),(2)影響很極端(extreme impact),(3)雖然它具有意外性,但人的本性促使我們在事后為它的發生找到理由——“事后諸葛亮”,并且或多或少認為它是可解釋和可預測的(introspective).IT系統、尤其是資本市場里的交易系統,所發生的各種重大問題,其實是很符合黑天鵝事件的特點的.

塔勒布用“感恩節的火雞”很形象解釋了黑天鵝的概念——直到被宰掉成為感恩節火雞晚餐前的每一天,火雞都應該是活的很不錯的,它的一生里沒有任何過去的經驗供它預測到自己未來的結果,而后果是致命的.

一套復雜的IT系統,很有可能就是那只火雞,例如就個人近年所遭遇的類似事件最典型的兩次,一是與某機構對接的技術接口,據稱已經存在并穩定使用近10年 – 雖然技術古老但是從未出現問題,然而在過去兩年持續創新高的交易量壓力之下,問題終究以最無法想象到的方式出現并形成系統性風險(因為對接者不僅一兩家)；

另一,則是老舊的系統因對市場可交易股票數目作了假設(而從未被發現),某天新股上市數量超過一定值而導致部分交易功能無法正常進行.

這兩個例子都符合黑天鵝特征,一是“史無前例” (如果以前發生過,問題早就被處理了),二是可以“事后諸葛亮”(所有IT系統問題,最后不都可以歸結為“一個愚蠢的bug” ?因為開發時需求不清楚、因為開發者粗心、因為技術系統所處的生態環境已經發生變化導致原假設無效)；

三是“后果嚴重”(如果技術系統本身是一個廣被采購的第三方的商業軟件,則整個行業都有受災可能；如果是自研發的技術,則最起碼對交易投資者造成災難性損失).

事實上,資本市場乃至金融業整體,可能都是黑天鵝最愛光顧的地方.甚至連普羅大眾都聽過的例子諸如：2010年5月6日的Flash Crash ——在三十分鐘內道瓊斯指數狂瀉近千點、1987年10月19日的Black Monday、國內著名的“烏龍指”事件導致的市場劇動……不一而足.

導致黑天鵝降臨的原因,事后分析五花八門,可能是量化交易導致的、可能是市場流動性不足引起的、也可能是市場心理(例如恐慌拋售)觸發的……無論何者,IT系統幾乎都是最后被壓垮的那只駱駝.正如塔勒布文章中提到,高盛在2007年8月的某天突然經歷的為平常24倍的交易量,如果到了29倍,系統是否就已經坍塌了?

事實上,在這個日益數字化的世界,本身就高度數字化的證券市場,面臨的黑天鵝事件會越來越多,出于但不僅限于以下一些因素：

• 增長的交易規模.
• 更高頻、更復雜的交易算法(《高頻交易員》一書里指出,股票市場已經變成機器人之間的戰爭).
• 更全球化更加波動 – 海內外政治經濟情況引起的突發變化.
• 更快速更先進的技術 – 已經出現數百納秒內完成交易處理的專門性硬件芯片,快到人類根本無法響應.

數字世界,尤其是金融業的數字世界,正好是塔勒布筆下所謂的“極端斯坦”(Extremistan),它完全不受物理世界的規律影響—— 一切極端皆有可能.例如在物理世界常識告訴我們,一個數百斤的超級胖子的體重加到1000人里面比重依然是可以忽略不計的；但在金融世界,一個比爾蓋茨級別的富豪的財產數字,富可敵國.

金融IT,正好生存在這么一個“極端斯坦”——這里復雜系統內部充滿難以察覺的相互依賴關系和非線性關系,這里概率分布、統計學的“預測”往往不再生效.塔勒布稱之為“第四象限”,我們,作為證券交易的IT,剛好在這個象限里謀生.

(塔勒布《黑天鵝》第四象限圖)

上述這一切,和云計算有什么關系呢? 我們覺得非常緊密,邏輯如下：

• 世界越來越數字化、更加“數目字可管理”- 一切效率更高.
• 本來就數字化的金融世界,日益是個“極端斯坦”,只能更快、更復雜,面臨更多黑天鵝事件.
• 應對數字世界的黑天鵝,只能用數字世界的手段(而不是“人肉”手工方法),就像《黑客帝國》,你必須進入Matrix,用其中的武器和手段,去解決里面的問題(并影響外面).
• 云計算,不過是世界數字化進程里的一步 – 把承載數字世界的物理載體也進一步數字化,但是它剛好是我們應對數字黑天鵝的基本工具 – 運算資源本身也是“數目字可管理”,并且正因為如此而可以是自動的和智能的.

即便到了今天,相信很多企業、機構的機房里的運算資源,依然不是“數目字可管理” – 這本身真是一個諷刺.但直到云技術出現,才解決這個問題.結合云計算的技術,交易系統不再是“your grandmother‘s trading system”.

“反脆弱”的技術系統

黑天鵝事件是不可預測的,但是并非不可應對.《黑天鵝》的作者塔勒布,在其另一本有巨大影響力的著作《反脆弱》(Anti-Fragile)里,提到了如何在不確定中獲益.這本閃爍著智慧之光的著作,早已超越了金融而進入到政治、經濟、宗教、社會學的思考范疇,對IT系統技術架構的設計,同樣具有啟發意義.

想想,一個經常被黑天鵝事件光顧的交易系統,如果不僅沒有坍塌、還隨著每一次的考驗而技術上變的越來越周全和強壯,這對于任何開發工程師、運維工程師來說,是不是一個夢想成真?

實際上,這個過程對于任何IT工程師而言都是非常熟悉的,因為我們中很多人每天的工作,可能就是在不斷的以各種應急手段緊急救援不堪重負的生產系統、或者在線彌補技術缺陷,在這過程中我們發現一個又一個在開發和測試時沒有發現的問題、一次又一次推翻自己在開發時的各種假設、不斷解決所遭遇到的此前完全沒有想象過的場景.如果項目、系統活下來了,顯然它變得更加健壯強韌.

只不過,這一切是被動的、低效的、“人肉”的,而且視系統架構和技術而定,變強韌有時是相對容易的、有時則是不可能的 – 正如一艘結構設計有嚴重缺陷的船,打更多的補丁也總會遇到更大的浪把它打沉.

如果基于《反脆弱》的三元論,也許大部分IT系統大致上可以這么看：

• 脆弱類：絕大部分企業IT系統,依賴于大量技術假設與條件,不喜歡無序和不穩定環境,暴露于負面“黑天鵝”中.
• 強韌類：小部分大規模分布式系統(也許通常是互聯網應用),適應互聯網相對不可控的環境(如網絡延遲與穩定性、客戶端設備水平和瀏覽器版本、用戶量及并發請求變化),經受過海量用戶與服務請求的磨練,相對健壯.
• 反脆弱類：能捕捉到正面“黑天鵝”- 系統不僅在沖擊中存活,并且變的更加強韌,甚至在這過程中獲益.

這里所謂的“脆弱”,并不是指系統不可靠、單薄、技術不堪一擊,而是指這類系統厭惡變化、厭惡不穩定不可控環境、本身架設在基于各種穩定性假設前提的精巧設計上,無法對抗突如其來的、此前無法循證的事件(黑天鵝),更無法從中自適應和壯大.就這個角度看,證券行業甚至整個金融業里,大部分的系統可能都是脆弱系統.傳統IT系統有以下一些常見的技術特點,例如：

• 一切以關系型數據庫為中心(RDBMS-centric).
• 很多歷史遺留系統(legacy system)有數以百計的表、數以千計的存儲過程.
• 業務邏輯高度依賴數據庫.
• 中間層與數據層高度緊耦合.
• 多層架構(multi-tiered architecture),層與層之間依賴于高度的約定假設(協議-protocol、接口- API、數據格式 – data format 等),并且這些約定經常來不及同步(例如某個團隊改變了維護的接口而沒有通知其他團隊、或者數據庫的表結構改變了但是中間層的對象庫因為疏忽而沒有及時步調一致的重構),有些約定甚至只存在于協作的開發者腦海中而沒有形成文檔(即便形成文檔也經常因需求變化頻繁而無法及時更新).
• 應用程序依賴于某些第三方的代碼庫,而這些代碼庫很有可能依賴于某個版本的操作系統及補丁包,并且這種依賴關系是傳遞的 – 例如某個第三方代碼庫依賴于另一個第三方代碼庫而該庫依賴于某個版本的操作系統……
• 系統設計,往往沒有考慮足夠的失敗場景(因此可能完全沒有容錯機制),沒有考慮例如不穩定網絡延遲對業務邏輯的影響(例如大部分企業系統都假設了一個穩定的LAN).
• 組件、模塊、代碼庫、操作系統、應用程序、運維工具各版本之間具有各種線性、非線性依賴關系,形成一個巨大的復雜系統.

然而,以下這些變化是任何IT系統所不喜歡卻無法回避的,例如：

• 多層架構里,任何一個環節的約定獨立發生細微改變,必定導致系統出錯(只是嚴重性大小的差別),這幾乎無法很好的避免 – 研發團隊的素質不夠高、軟件工程的水平低、瞬息萬變的市場導致的頻繁更改等,總是客觀存在.
• 因為安全原因,需要對操作系統進行打補丁或者升級,導致應用程序所依賴的代碼庫發生兼容性問題 – 在打補丁或升級后通過測試及時發現兼容問題已經算是幸運的,最怕是在生產環境運行過程中才觸發非線性關系的模塊中的隱患.
• 跨系統(尤其是不同團隊、部門、組織負責的系統)的調用協議與接口發生變化,是一個常態性的客觀事實.
• 互聯網環境、甚至企業內部的網絡環境,并不是一成不變的,網絡拓撲出于安全、合規隔離、性能優化而變化,可能導致延遲、吞吐等性能指標的變化,應用系統本來沒有出現的一些問題,有可能因為運行環境的變化而浮現,而系統內部容錯機制往往沒有考慮到這些問題.
• 業務需求永遠在變,以數據庫為中心的系統,不可避免產生表結構(schema)調整,系統升級需要做數據遷移,而這總是有風險的(例如data integrity需要保證萬無一失).

于是,傳統IT對于這些系統的運維,最佳實踐往往不得不這樣：

• 在使用壓力增大的情況下,最安全的升級手段是停機、換機器、加CPU、加內存,直到硬件升級、垂直擴容(vertical scale、or scale-up)手段用光.
• 維護一個龐大的運維團隊,隨時救火.
• 試圖通過軟件工程的管理,例如制定規章制度,讓協作人員、團隊之間在接口升級前走流程、互相通知,來避免隨意的系統變化導致的風險.
• 加大測試力度 – 通常很有可能是投入更多的人肉測試資源,以保證較高的測試覆蓋率和回歸測試(regression test)能力.
• 強調“紀律”,以犧牲效率為代價,通過“流程”、“審核”設置重重關卡以達到“維穩”效果.
• 重度隔離運維與研發,禁止研發人員觸碰生產環境,減少誤操作 – 例如隨意升級操作系統、對應用邏輯抱著僥幸心理打補丁等.

不可否定,這些“套路”在以往的時代可能是最佳實踐,也體現了一個IT組織的管理水平.但是毫無疑問,這樣研發、運維和管理的系統,是一個典型的“脆弱系統”,它依賴于很多的技術、工具、環境、流程、紀律、管理制度、組織結構,任何一個環節出現問題,都可能導致輕重不一的各種問題.

最重要一點,這樣的系統,厭惡變化、喜好穩定,無法在一個“只有變化才是唯一不變”(并且是變化越來越頻繁)的世界里強韌存活,更無所謂擁抱變化而生長.

強韌類的技術系統,情況要好的多,起碼能“響應”變化(如后文所論述).但是注意,在塔勒布的定義里,“強韌”并非“脆弱”的反面,“強韌系統”只是能相對健壯的對抗更大的壓力、更苛刻的環境,它并不能從變化、不確定中獲益.

“脆弱”的反面,塔勒布在現有語言里找不到一個合適的詞語,所以他發明了一個新概念,“反脆弱”(Anti-Fragile).問題是,接受“變化是一種常態”、擁抱變化并從中獲益的“反脆弱”的技術系統,能被構建出來嗎?

云計算的出現,有利于幫助IT構建強韌系統,并且讓“反脆弱”系統成為可能.其最根本原因在于,云計算本身是機房物理設施數字化的過程,如上文所述,數字世界的黑天鵝 – 微秒、納秒內發生的極端事件,只能通過數字化手段才能高效解決.

伴隨云計算出現的是DCOS(Data Center Operating System)、APM(Application Performance Monitoring)、Infrastructure As Code(基礎設施即代碼、可編程運維、可編程基礎設施……)、DevOps等等技術方案、技術產品、技術理念和方法論.這些都是構建強韌系統的有力武器,而在云計算時代之前,它們嚴格意義上不曾存在過.

云計算也許是目前為止對于證券交易系統、甚至對于更廣義的金融技術系統而言最適合應對黑天鵝的技術手段.監管機構不應該見到“云”字就敏感的與“公有云”、信息安全、交易可監管性等問題聯系起來；金融機構則需要與時俱進的學習掌握“云化”的技術手段、架構思維 – 至于系統是運行在公有云、私有云還是混合云,都已經是另一個故事.

容器技術的救贖

云計算,其中一個最基本目的,是計算資源的集合管理與使用.其實IT界在計算資源的集合使用方面,過去20年起碼嘗試過三次：

• 90年代中后期,出現網格計算(Grid Computing),用于蛋白質折疊、金融模型、地震模擬、氣候模型方面的應用.
• 本世紀初,出現效用計算(Utility Computing)- 推行運算資源按需調用(On-demand)、效用計費(Utility billing)、訂戶模式(Subscription model)的概念.IBM、HP、Sun這些IT公司都嘗試推動過這個領域的解決方案,雖然成效不彰.
• 10年前,亞馬遜AWS發布,算是云計算的標志性事件.云計算覆蓋含義更廣,網格計算可以是云計算平臺上的一類應用,而效用計算則可以被視為云計算服務商所采用的商業模式.

云計算和大數據技術出現后,這些技術逐漸變身“事務型內存數據庫”、“內存網格”(in-memory data-grid)、“流式計算平臺”(stream processing)等,然總體來說變的越來越小眾.

無論如何,這些技術在云計算出現前已經幫助華爾街機構掌握了計算資源集合運用、分布式架構的一些理念和思維.而國內證券界甚至金融業IT總體來說,對這類技術是相當陌生的.

就對標華爾街同行的證券業IT而言,可以說基本上錯過了上述計算資源集合應用的三個浪潮.云計算興起后,OpenStack之類的技術在證券IT甚至金融界的成功落地、大規模采用的案例極其罕有(如果有的話).

即便是近年來互聯網云服務商興起,部分金融機構因為試水互聯網金融而開始使用公有云,很大程度上使用方式也不過是使用了一些虛擬機運行一些互聯網邊緣(Edge)服務.

然而這個時代有趣的地方在于,一些新技術的出現可以讓“彎道超車”、“后發制人”成為可能 – 上一個階段錯過了一些東西,但是也可能下一個階段少了很多歷史包袱從而可以輕易跳進最新的技術世代.容器,恰好就是這么一種技術 – 假如你能把握的話.

在英語里,“容器”、“集裝箱”、“貨柜”都是同一個字 – Container.容器技術之于軟件業,很有可能可以類比集裝箱對運輸業的巨大影響.

實際上,確實有人想過把整個機房放在集裝箱里,例如2006年Sun Microsystems推出的Project Blackbox——剛好是亞馬遜發布AWS的同一年.但這個集裝箱是鋼鐵的、有物理形體的、重量以噸為單位的；而其中的內容,自然也是各種物理的服務器、網絡設備、發電機.那一年,可能誰也沒有想到,10年后有一種“數字化”的虛擬集裝箱大行其道.

技術界不乏認為容器對軟件技術產生革命性影響的觀點,本人傾向于認同這種觀點,因為：

• 容器影響開發者的開發方式、開發習慣,“強迫”他們去思考例如無狀態的服務、業務邏輯粒度的控制、資源的彈性伸縮、應用代碼的發布形態、系統里面每一個細節的可監控性等等.
• 讓真正的DevOps成為可能 – 自動化測試、持續集成(CI)、持續交付(CD)、自動化部署、無人值守的運維… 開發與運維的角色差異進一步縮小,而效率則最大程度提升.
• 讓“不可變基礎設施”(Immutable infrastructure)成為可能——這將顛覆傳統軟件系統的升級發布和維護方式.

為什么作為金融系統、交易平臺的研發者,我們挑容器出現的時候跳進云計算,而在更早階段虛擬機系列相關技術成熟時卻并沒有大的投入.

最根本原因在于,作為研發組織,我們從研發視角,基于具體應用場景去持續、積極尋覓能解決強韌性、健壯性問題的解決方案 – 這是一種“Top-Down Thinking”,例如在交易量波動過程中,我們能否有自動化的技術去可靠的應對、實現計算資源的彈性伸縮并且保持超級高效?

有什么技術可以幫助我們解決復雜交易系統發布、升級、打補丁的危險和痛苦?交易故障出現時系統內部防止雪崩效應保持快速響應的“熔斷”(circuit-breaker、fail-fast)機制有什么更規范的做法?用現有云計算的理論和技術倒著去套,顯然是無解的,因為：

• 虛擬機級別的資源調度,太沉重,可編程接口太弱,無法“融入”到一個高性能運算(HPC – High Performance Computing)的應用中.
• 僅僅為了資源的彈性伸縮,去引入一個第三方解決方案,例如一個PaaS(諸如CloudFoundry、OpenShift等),對于交易系統而言,代價太大、可控性太低、編程模型受入侵程度太高.
• 不是為了云計算而云計算 – 一切“革新”需要合理、充分的應用理由,場景不符合,架構就不合理.

“Bottom-up Thinking”,即從基礎設施的可管理、資源充分共享、運維更高效等角度去看問題,是一個典型的“運維”視角或者所謂CIO的視角,這種思考,關注的是TCO(Total Cost of Ownership)——成本的降低(IT在垂直行業一直被認為是一個成本中心 – 在現在這個時代這是一個錯誤觀點,但這是另一篇文章的討論范圍了)；可是和核心業務應用非常脫節.

對于一個傳統行業尤其是受監管行業的IT而言,技術氛圍往往是保守和審慎的,采用云技術這種在互聯網界以外還很大程度被認為是“新生事物”的東西,并不是一件容易的事情：在行業繁榮、企業賺錢的時候,公司很可能并不關注運維除了穩定以外的事情 – 包括用虛擬機還是用物理機、能否節省一點成本等等；

在市場不景氣、公司虧錢的時候,IT卻又需要以非常充分的數據來證明建立或者采用云平臺能帶來顯著的大幅的成本節省效果,但是這往往首先涉及第三方軟件的采購、機房的改造… 這本身就是一個巨大障礙.

所以,悲觀一點的看,很大一部分傳統行業IT,很可能需要等到云技術成熟為新世代IT系統的標配,就像mainframe時代向client-server時代轉變、client-server時代向多層架構/web技術時代切換,云技術成為一個主流的、企業決策者不再需要加以思索的事物(“no-brainer”)時,才會順利進入企業世界.此時,運維的視角也許才能被充分接受.但是,對于以創新為本業的金融科技,那已經太遲.

早期的云技術,從運維視角去看是自然的,因為虛擬化技術最開始是把基礎設施數字化的一個進程.容器化技術的出現,改變了這一切.容器天然與應用服務結合的更緊密、天然需要程序員的深度介入,“上帝的歸上帝,凱撒的歸凱撒”,容器里面的歸程序猿(code monkey),容器外面的歸運維狗(watchdog)——不一定對,只是作為笑話簡單粗暴的類比一下,但想說明的是容器內外的關注點是不一樣的、而運維與研發的協同則是深度的.

在Docker剛出現的時候,一直帶著前述問題的我們,從其理念已經體會到容器技術對構建一個強韌交易系統的好處.

容器技術的到來,讓我們在觀念上“彎道超車”：

• 在軟件安裝、發布方面,我們還需要去學習、模仿Oracle、IBM們研發什么工具嗎?不需要了 – 采用容器、容器編排技術、容器鏡像管理技術、容器目錄(catalog),我們輕易的“一鍵發布”,而且誰都可以執行.
• 在打補丁方面,我們還要去參考Redhat開發個升級工具嗎?沒必要了,因為我們不打補丁,已經發布的容器里內容永遠不會改變(Immutable),需要修復缺陷或者升級版本,我們就發布新容器 – 發布組件乃至整個全新交易系統,成本都是很低的(并且必須永遠維持那么低).因此,我們也不一定需要什么中心化的、統一的、集中的可視化配置管理工具.
• 灰度發布、在線升級、多版本生產環境、回滾現在都是容器化系統天然自帶的——因為整個系統的發布、部署是低成本的和快速高效的,只要有硬件資源就再發布一套,不行就切換回舊的那套 – 技術界已經在不斷總結最佳實踐,總有一款套路適合你.基于容器的微服務,天然支持多服務版本并存；對于回滾,數據庫可能是個問題,但首先一切以數據庫為中心就是個很有可能是錯誤的觀念(當然,視應用場景而定),在分布式架構里,關系型數據庫有可能不在系統關鍵路徑上、事務有好些辦法可以規避、通過很好的面向對象設計解耦內存與持久層的耦合… 實際上,經驗告訴我們,關系型數據庫被濫用是企業應用軟件的通病.

而比解決運維問題更有趣的,是這幾方面：

• Infrastructure As Code – 現在總算不是口號了,對著容器、容器編排技術進行編碼,讓“無人值守”、“智能運維”真正成為可能.雖然Puppet、Chef、Ansible這些技術早就存在,但是它們基本上僅限于操作基礎設施的物理、虛擬資源,與一個專業應用系統通過API深度結合然后基于業務場景、系統業務指標來自我維護,是非常困難的.而容器,基本上只是一個進程,通過其API可以輕易深度整合到交易系統里.
• 容器技術出現后,也衍生出更多其他新興技術,例如CoreOS、RancherOS、Unikernel.對于無止境追求極速性能的交易系統,交易軟件到底層硬件之間的耗損越少越好,這和我們所遵循的mechanical sympathy技術理念完全一致.類似Unikernel這樣的所謂“library OS”非常有趣,因為整個操作系統萎縮成一系列的基礎庫,由應用軟件直接調用以便運行在裸機(bare metal)上.想象一個超級輕量的交易中間件,無縫(真正意義上)運行在裸機上的毫無羈絆裸奔的“爽”…
• 在廣發證券IT而言的所謂“彎道超車”,其實更包括幾方面的含義：一是觀念上的,顛覆傳統軟件研發的思維,不必要去做追隨者；二是技術成長方面的 – 雖然有些技術如Unikernel并未成熟到可以真正運用,但是兩三年前的Docker不也一樣嗎?重要的是團隊和一個革命性技術的共同成長,前瞻性技術的研發投入終將回報(capitalize)；三是實際效果上的,雖然在云計算發力的前幾年,我們并未投入到IaaS、PaaS的“基建”,但是從容器化入手,忽然間就獲得了一定的“計算資源集合使用”的能力 – 此前只有技術實力較強的科技企業能做Grid Computing.

在證券業,我們不是孤獨者.華爾街投行的表率高盛,今年2月份宣布了他們一年內把90%的運算能力容器化的計劃.

時至今天,在Docker已經被團隊廣為接受、被應用到各種業務系統中去的時候,我們從兩個方向同時繼續推進容器化技術：

• 第一個方向,繼續沿用上文所述的“Top-Down”思路,基于業務場景、具體應用需要,把容器(Docker)、容器編排管理(Rancher)的技術深度整合到交易系統中去,讓其獲得自伸縮(elastic)、自監控(self monitor)、自修復(self-healing)的自動化能力 – 這是“反脆弱”系統的一個必要非充分條件.至于什么時候伸縮、什么時候自修復、如何學習自己的運行行為以作自我調整、如何把低級的系統指標換算成業務級別的性能指標作為自己的健康“血壓計”… 這些是需持續學習挖掘、測試驗證的東西.
• 第二個方向,是上文所述的“Bottom-Up”思路,采用例如Kubernetes建立起一個多租戶的CaaS(容器即服務)平臺,支持非交易的應用系統(例如電商平臺、機器人投顧服務、CRM等等)的跨云(公有云、私有云、傳統機房)容器化.

軟件工程沒有銀彈99年圖靈獎獲得者Fred Brooks(也就是Brooks’ law的發現者：“往一個已經延誤的項目里加人力資源,只能讓那個項目更延誤”)說過,軟件工程沒有銀子彈.

在各種標榜“云”的科技公司層出不窮的今天,其實依然還沒有任何“黑科技”幫閣下把你的脆弱系統瞬間變成一個強韌系統甚至一個具備反脆弱能力的系統.所以,容器技術也不過是一個也許必要但不充分的有用工具而已.

能否釋放云計算的威力,取決于很多因素.到一個公有云上使用幾個虛擬機,也算一個小小的進步,畢竟它可能(1)縮短了一些傳統企業采購硬件、機器上架等等的周期；(2)幫不擅長互聯網技術的傳統企業解決一部分“互聯網最后一公里”問題.然而,這只不過是使用了一些虛擬化基礎服務,如果部署在上面的系統本身是一個脆弱系統,那么它在云上依然是一個脆弱系統.

實現一個強韌甚至反脆弱的技術系統,你首先得有一個恰當的技術架構,而實現這樣的技術架構,你首先需要有研發團隊 – 不錯,個人觀點是,在現階段如果不具備軟件研發能力,那么你的組織其實無法真正利用、享受到云技術帶來的福利.

怎樣的架構才能利用和釋放云計算能力?

首先,架構設計需要遵循Reactive(響應式)原則(根據“響應式宣言”)：

• Elasticity – 彈性響應系統負載變化,基于實時性能監控指標以便通過預測性(predictive)和響應性(reactive)算法來對系統進行擴容.
• Resiliency – 通過復制(replication)、包容(containment)、隔離(isolation)和委托(delegation)等機制,保障在故障發生時系統能繼續高度可用.
• Responsive – 系統及時探測偵察問題并解決問題,保障對外的及時響應.
• Message-driven – 采用消息驅動的、非堵塞的異步通訊機制,降低系統內部組件模塊間的耦合度,提升吞吐量.

其次,在技術研發過程中,我們采用一系列的所謂“Cloud-native patterns”(原生,或者說“天然”的云計算架構模式)來實現我們的系統,以便讓系統達到Cloud-ready(具備云感知能力 – 借用IBM與Intel相關中文版論文的概念).

此外,“云感知”和上述“響應式”原則,是完全一致的,云感知也關注“故障恢復能力”、“延遲恢復能力”、“擴展的靈活性”.事實上,在一流的金融IT團隊里,這些原則、實踐要求,從來都是被遵循的,因為金融的應用系統天然需要這些能力.無論是否在云計算時代,這些原則、要求均非常合理.

那么容器化技術在這其中有什么作用呢?實踐告訴我們,作用很大.最重要一點是,很多pattern的具體技術實現,可以挪到容器層面去處理.例如Circuit-breaker和Fail-fast這類模式,過去的做法,是各個具體的服務,采用自己的技術工具(例如Node.js的守護進程PM2)和辦法,基于開發者自己的理解,各自實現.

容器化的好處,是把復雜系統里一切異構的技術(無論以Go、Java、Python還是Node.js實現)都裝載到一個個的標準集裝箱里,然后通過調度中心基于各種監控對這些集裝箱進行調度處理.也就是說,Cloud-native的架構模式,有不少是可以在容器編排調度與協同的這一層實現的.

DevOps：云計算時代的方法論和文化

南懷瑾在某本著作里舉過一個剃頭匠悟道的例子 – 無論何種行業,技藝追求到極致可能悟到的道理都是共通的.《黑天鵝》和《反脆弱》的作者塔勒布本人也許算的上是這樣的一個觸類旁通的好例子 – 由金融而“悟道”于哲學(起碼被稱之為本世紀有影響力的思想家之一).

IT領域不知道有無類似的人物,諸如面向對象設計、架構設計模式、敏捷開發領域的大師級人物Martin Fowler等,顯然是抽象思維特別強的人,能夠對復雜的技術世界進行“模式識別”而作出一些深刻思考.

在技術世界里,我們一向強調方法論,可是有時候也需要形成“世界觀”、“信仰”.在無數次的項目危機管理、技術故障攻堅、運維救火之后,IT人也許應該對“世間唯一不變的是變化本身”有深刻體會,從而接受“擁抱不確定”的觀念.

IT界面對變化與不確定性的態度,這十多年來看也是一個有趣的演變：

• 直到本世紀初,很多項目管理及軟件工程的方法論,依然強調所謂的“Change management”(變更管理),通過組織(“變更委員會”)、流程來“管理”業務系統需求方不斷提出的需求管理,視需求變化為項目延誤、系統不穩定的根源,以項目“按時”交付為終極目標,可以說這些方法論本質上“厭惡“變更.
• 互聯網風起云涌后,出于應對瞬息萬變的激烈競爭、在線高效運營的剛需,接受“需求變化是常態”、對變更友好的“敏捷”(Agile)方法被自然而然引入到日常項目中,成為過去十年的主流方法論,并且終于把傳統企業IT牽引其中(例如廣發證券IT啟動金融電商系列項目研發前的第一件事就是先把敏捷實踐建立起來 – 對口的方法論才可能帶來對的結果).
• 然而,絕大部分企業的敏捷實踐都局限在垂直業務線的項目團隊里,而運維作為一個維護全企業IT生產資源的橫向平臺型組織,通常被排除在敏捷實踐之外.

  敏捷迭代方法解決得了業務需求變更的問題,解決不了系統上線后各種突發性的變化 – 故障的及時解決、版本的迅速更新(業務部門總是迫不及待的)、在線經營的瞬間生效(運營人員分分秒秒催著)…

  在一切都嫌慢的“互聯網時間”里,運維貌似成為最后掉鏈的一環,以“穩健”為主導的運維團隊與“進取”的研發、運營團隊無可避免產生沖突

• 時至今天,隨著“把基礎設施數字化”的云計算的普及,一個新的方法論 – DevOps,閃亮登場.之所以說這是一個方法論,是因為它絕不僅僅是“Dev + Ops”這樣簡單粗暴的把開發工程師和運維工程師捆在一起,用“同一個項目組”、“同一套KPI”來強迫他們分享“同一個夢想”了事.

  它是在APM(應用性能監控)、Infrastructure As Code(可編程運維)、Virtualization(虛擬化)、Containerization(容器化)等等這些云計算時代的產物出現后,基于新的技術工具、技術理念而自然產生的.

  持續集成(Continuous Integration)、持續交付(Continuous Delivery)、持續運維(Continuous Operation)是DevOps的具體環節和手段,它相當于把一條純數字化鏈路上不同的參與者關聯到一起 – 無論是開發工程師還是運維工程師,最終都不過是身份稍微差異的Information worker.

DevOps可能不僅僅是個概念、方法論、技術新名詞,它是伴隨云計算自然發生的.但它的接受與運用,對于傳統企業的IT,尤其是“維穩”為主導思想的受監管行業的IT,可能是一種文化沖擊.

傳統IT甚至是今天的很多技術相對前沿的互聯網公司,依然把團隊拆分成“運維”、“開發”,在組織結構層面建立相互制衡,以避免開發團隊的“沖動冒進”導致生產系統的不穩定,但運維職能往往變成一種“權力”(privilege)- 系統的迭代更新都需要獲得運維“審批”,這本身顯然就是一個“脆弱系統”,因為對變更是絕不友好的.在技術進步、時代變遷的大環境下,這種過去合理的做法,早晚變成一個將要被顛覆的存在.

無論如何,我們認為割裂的討論一個高性能運算(HPC)的技術系統(如證券交易系統)的容器化、“云化”是不夠的,DevOps是構建“反脆弱”技術系統的方法論(起碼到目前為止.也許將來有新的思維出現),也是我們系統能力的天然一部分.

結語

我們從軟件研發的視角、證券交易的視角來看待云計算,深感把促進基礎設施數字化、運維代碼化的容器化技術,運用到交易系統技術中,是天作之合 – 假如運用得當的話,結合機器學習和智能算法,能幫助我們構建一些“反脆弱”的技術方案(既然有能下圍棋的阿爾法狗,我們是否也可以開始憧憬懂得自救的運維狗?).

可以看到的潮流脈絡是,世界是越來越數字化的、變化是越來越頻繁的、而IT是需要擁抱變化的,云計算則只是這個潮流里完全符合趨勢而自然出現的技術階段.

有一天Oracle、SAP、各種著名與非知名的專業軟件都把它們自身的產品基于容器來構建(例如一個多進程組成的數據庫實例里的進程各自運行在自己的容器中),也許對于行業監管者、企業技術決策者而言,云已經無需概念上的存在,而能被毫無質疑的接受.

但是這一天到來之前,大部分企業也許可以先嘗試調整一個對云服務友好的財務制度 – 項目立項的時候,硬件預算按CPU核數、內存量、存儲量來報算,有形的物理機器不再作為資產稽核到各條業務線各個項目組,一切物理硬件歸IT.制度和文化,往往才是隱形的決定因素,不是嗎?

文章出處：InfoQ

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4407.html