混合雲場景下金融級中間件自動化運維平臺建設之路

做者介紹：

我先作一下自我介紹，我名字最後一個詞讀lang（倞），我是2000年踏入這個圈子的，很是倒黴，我剛踏入這個圈子遇到了網絡經濟泡沫，在座的有一些同窗的年齡你應該也遇到過，有些也沒有遇到過，不知道這是什麼東西。我作了7-8年的開發，4-5年的架構，我作過不少東西，除了微軟那條線技術棧沒有作過之外，其餘的我都作過。

可能有的人聽到什麼什麼公司，金融一聽以爲好像特別高大上，經過今年一年你們聽到金融會以爲特別懼怕。對不對？並且好像聽金融公司，以爲大家公司好有錢，大家會作不少事情，會大手筆。

可是，我跟你們講的是，不是這樣。由於你們都知道，不少金融類企業的老大，也就是他們的 CEO 和創始人，基本上都是作業務出身的，作業務出身的、作金融的首先第一點就是成本理念很是強。

他特別特別會算賬，因此在這樣的公司作IT是很是辛苦的，爲何辛苦呢？你要常常去跟他談成本，他也會跟你常常談成本，可是那些人民幣不懂。

因此我給你們糾正一下，金融什麼什麼東西，確定用的東西特別牛，安全性特別高，其實不是這樣的。

我今天來說幾個內容，首先來給你們介紹一下，由於不少同窗會說講技術就講技術，作什麼背景介紹，我們這個世界都是由客觀組成的，不是你的技術用在我這邊就能夠的，由於咱們每一個人在公司解決的是業務性問題，或者痛點性問題，若是你的公司一路順風，你的老闆不須要花錢請你來。

咱們不少搞技術的同窗都是完美主義，你到一家公司但願遇到乾乾淨淨的一套系統，作你想作的事情，請問，是這個樣子的嗎？招人的時候以爲怎麼怎麼好，進去了之後發現不少坑。可是你根本不知道當時發生了什麼，咱們進去要面對不少問題，不少客觀環境，案例和解決方案充斥着咱們不少人的平常工做。

1. 背景介紹

簡單介紹一下公司，不少人一聽什麼什麼財富，咱們公司不作P2P，咱們有一個爸爸有一個媽媽，爸爸是騰訊，媽媽是聯想，你們在手機上打開理財通，騰訊也是咱們公司最大的股東，咱們公司幾年前在新三板掛牌上市，咱們如今叫騰訊系的財富公司。咱們不作P2P，咱們是作基金的。

先來講一下咱們爲何要去作中間件。我相信在座不少你們聽過不少大型公司裏聽到一些東西，好比咱們如今的阿里雲，前身就是阿里中間件團隊，只是如今作了技術賦能和技術輸出，把技術變現而後對外輸出。

簡單一句話，當你公司變成多條業務線的時候，從單業務的業務方位變成多維的業務方位的時候，舉一個例子，你又賣食品又賣其餘的東西，有多條業務線，中間須要的業務產品是不同的。

你們都有交易，都有帳戶，因此阿里有一個叫共享業務事業羣，中間又有共同的業務棧，之前咱們的作法，好比說餓了麼，不少的這種互聯網公司，他們的作法就是把緩存做爲應用的一部分，我用了任何一個技術棧，我用就能夠了。

我想給你們陳述一些數據，首先咱們2015年，固然2015年是牛市，2015-2018年咱們公司在業務上進行了變化，先說動向，咱們的接口從百級變成了千級，微服務、服務化，要作拆分，業務要發展，從單一的賣基金，到如今賣不少，我才關心什麼基金，我就要知道什麼業務要賺多少錢，只要安全就好了。在這樣的業務變革下變出來不少組合，個人接口會有變化。第一個是變多了。

還有個人子系統會進行拆分，咱們的研發團隊從測試運維變成的縱向團隊，把運維的部分拆掉，拆到各個團隊裏面去，你這個團隊又有產品經理，又有研發，又有運維，你的目標就是把公募基金交易系統作好，從橫向變成縱向的時候你的數量會變多，你是交易團隊，你這個是帳戶團隊，你是資產清算團隊，都有不一樣的團隊。

你們都要用到一些相關技術怎麼辦？咱們有統一的架構團隊來給你提供標準化的服務，好像你們看到的阿里雲提供不少的技術服務，中間咱們也會用到好多的SDK，適配，穿透等各類技術，爲何？由於你的技術棧不同，接入形態也不同。

咱們業務型也是同樣的，原先咱們賣公募基金的，還有賣私募的，就是百萬起，高端的，像諾亞財富。總而言之你們能看到，咱們好買遇到的技術壁壘和全部的互聯網+團隊都是同樣的，技術棧變複雜了，數量變多了，業務也變多了，可是有同樣沒變多，什麼東西？人。

人仍是那些人，咱們常常說偷偷摸摸作架構，爲何金融不少老闆算成本怎麼算的？我前面作5個接口要用5我的，很正常。什麼是架構？不就是ABC嗎？不就是兩張代碼嗎？沒聽懂，我就給你5我的，怎麼辦？你的架構要去變。

不少人如何看待咱們的運維？第一個就是客戶愈來愈多，速度愈來愈快，需求愈來愈複雜，要麼招不到，招多不划算，招少不夠用。

還有分佈式不少的開發和研發，分佈式對於業務開發來講是很是好的事情，有很是多的優勢，對於運維來講是一場災難。咱們看一個場景，我當時在IOE作架構的時候很簡單，如今呢？因此咱們走的方向是什麼，一句話把能力賦予工具或者平臺，用最低的成本交付與開發，本身玩去吧。

剛纔前面談到了組織結構也變了，不能要求每一個運維都有開放的架構，你也招不到，有人招到就厲害了，你能留得住他嗎？你一共團隊這麼大，你給的空間是5個領導，3個總監，你往哪發展去？發展來發展去，上面的人一直站在上面，你也上不去，除非公司有更快的發展，你們知道這兩年消費在退化，不少團隊不須要特別強的人，包括不少公司作技術輸出，你能夠從那邊用便宜的價格得到好的技術服務。

因此我把東西作成平臺，想哪天發佈就哪天發佈，你想哪天上線就哪天上線，每一個團隊本身作。

2.中間件運維有哪些痛點

中間件運維有哪些痛點？首先問你們一個問題，應用運維和中間件運維有什麼區別？有很大的區別。區別在哪兒？

• 第一點，專業性更強。若是讓你畫一個圖譜，很簡單，咱們不說更大的，咱們從研發的視角。全部的東西都在架構裏，架構是什麼？就是邏輯。一堆的業務算法，就是這些東西，可是它的專業性不須要特別強，爲何？我有這些東西就能夠了。由於大量的技術棧都被中間件所包含了，高可用，你也不可能招到一個運維全部的技術棧都懂。

• 第二點，自主性更弱。中間件獨立存在的價值就沒有了，應用不用你，你是沒有任何價值的。若是訪問量很小，緩存幹什麼呢？我是不須要的，只要流量大了，微服務作的多了，信用負載大了。

  舉一個例子，在咱們系統裏面是否是在座的運維同窗遇到的常見問題就是鏈接池爆了，怎麼管理呢？中間件往什麼方向發展，架構布成什麼樣子，是應用和前端應用系統決定的，不是運維決定的。

• 第三點，重要性更高。咱們公司最近在辦「王者榮耀」的比賽，咱們團隊有一句口號，若是你敢打敗我，我就按一鍵銷燬的功能。

  個人分佈式要作一致性，消息、緩存包括統一的分佈式調度，統一的分佈系統，決定了你的系統是否是好得起來，是否是安全，遇到高流量的時候是否是可以快速拓展，拓展的過程當中會不會引發其餘的故障，這全是中間件決定的。這三點區分了應用運維，我指的應用運維是偏前端的，不是 IaaS。

痛點1：資源信息管理與維護成本高。咱們的虛擬化已經達到95%以上了，也用了超融合的架構，也是用資源池調配，可是上面的中間件轉成分佈式，都是動態的。

對於資源的對應狀況，用了多少資源是不知道的，怎麼辦？天天統計一遍，輸出一個Excel，咱們一個同窗一邊花一兩個小時幹這個事，咱們同窗說了幹這個幹什麼呢？老闆用啊。

痛點2：就是裸用各類開源的監控，沒法精準定位。不少人用 Zabbix，它是幹嗎的？就這幾件事。請問一下，若是你知道這幾件事情，你知道故障的真正來源嗎？你知道應用是哪一個系統引發的嗎？你大部分是不知道的，若是真的是因爲設備和故障引發的話，好解決。

痛點3：還有缺少短鏈路監控與排障手段。什麼叫短鏈路？我舉一個例子，由於咱們如今採用的是運維下沉中間件團隊單獨服務全部的分佈式中間件，這個時候當遇到故障的時，業務端說你很慢。

舉一個例子，如今應用運維跑過來跟你說，下單超時了，你知道嗎？你說我這邊也很慢，這是第一反應。第二個說我不慢，我很快。

就說第一種，是你的代理慢？仍是虛擬機慢，到底哪裏慢？大部分狀況是不知道的。會怎麼辦？打 Zabbix 去查了。咱們做爲一個交易系統是有交易時間的，你下單的時候在2點到3點30之間出現問題了，說3000塊錢不要了，你肯嗎？

餓了麼送外賣丟了一個東西，最多賠你一個，那個東西你能賠嗎？你可能賠不起。咱們經過SDK，包括咱們代理層，包括全部中間件的系統進行短鏈路的監控，當前端出現問題的時候，我能夠很是清楚定位到底哪一個節點出現了問題。

看一個例子，業務說下單報錯了；前臺說，我沒問題，問問服務報錯了嗎？中臺說，是你沒調過來吧，我連日誌都沒打；運維說進程都在，也沒看到ZB報錯；後臺說，胡說什麼，我這有反應，你傳錯了；DBA說，你叫什麼叫，連數據庫都沒連上；運維說，傻X，MQ阻塞了，不知道都在叫啥。

咱們公司是作基金交易，若是系統出問題的話，若是今天交易由於系統的問題沒有交易成功的話，次日基金市值大漲的話，我是要賠錢的。

由於是系統致使的問題，你要賠個人，我買的越多，你賠的越多。咱們公司有一句話，爲何會出問題？由於人品好。此次出問題正好在3 ：05分，交易時間過去了，可是再好的人品也會刷爆的。

3.從‘人肉’到工具，咱們是如何演進的？

咱們先來看一組數據，20個消息隊列，15臺虛擬機，8組緩存分片，2組數據庫。你知道線上幾千幾百的節有點問題嗎？你知道嗎？你不知道。你哪知道有問題？你只知道報錯了，你認爲是好的，可是你的管理是有半徑的，最多在顯示屏上管4-5個節點，另外有沒有問題，你不知道。

怎麼辦？開始建中間件的架構，前臺，先異常彙總—用戶服務—基於短鏈路的監控與排障—小工具。

Zabbix作一些基礎性的，像端口、CPU，它的定位爲何很差？由於它的應用沒有辦法進行關聯。還有ELK，作實時分析。

好比說咱們公司的緩存某一些切片要求很是高，不容許你的抖動在交易24小時大部分時間，包括交易時間，你的抖動每一次訪問不容許超過50毫秒或者30毫秒，或者說20毫秒。

由於你的底層業務，每個用戶登陸這個帳戶信息，包括交易過程中須要帳戶當中的信息，交易要作不少認證，每一個環節都要作認證，我無論是本地緩存，仍是異地緩存都要響應，若是緩存有必定的抖動，你整個應用的長鏈路都要受到影響，最後就會崩潰，你的交易系統沒有辦法進行下去。因此說咱們來解決這樣的問題。

大數據作什麼？作比對。好比說，咱們緩存數據，它哪一個K更新的最多，哪一個K更新的時間最長，哪一個最大，這個要比對，哪一個降低了，哪一個沒有降低，數據的失效狀況，哪一個合理哪一個不合理，這些數據從什麼地方來，都是通過咱們大數據分析得出報表獲得的。
簡單來講，大數據主要處理離線數據。

有的同窗說了，這個傳統運維作不了，對，咱們如今裏面有架構師，有產品，有測試，有開發，有運維。因此咱們如今的運維轉型相對簡單？由於咱們傳統的運維同窗在跟着咱們的架構師學開發，並且個人架構師是能夠給個人運維賦能的，由於我是一個閉環的團隊，我只須要對外輸出，人性化的界面和管理控制檯，而且輸出各類各樣的SDK和接入方式的適配器就能夠解決了，這個東西不須要運維來作，須要開發和架構師來作就能夠了。

這個內容你們看得清楚，當緩存響應慢的時候怎麼辦？一個小夥伴鏈接集羣，查日誌，這是一個平常苦逼的運維在乾的事。

案例2：當消息阻塞時的排查過程，這種狀況是什麼？一下子好一下子很差，業務說我也沒有問題，前端的產品說我就很慢，我爲何這邊的數據就是看不到呢？用戶爲何就是看不到那筆交易呢？最後查下來大部分的鍋確實是中間件的，由於有時候阻塞有時候不阻塞，罪魁禍首是消費方，他消費慢了，它壞了，可是仍是要找你，你能不能不阻塞，我說你能不能消費快一點，他說大家都是技術精英，大家應該在這種爛的狀況下怎麼解決這個問題。你沒有辦法狡辯，我要拿出數據告訴他到底哪裏有問題，而且把界面交給他讓他本身去看。

怎麼演進？第一個，明確的邊界、鬆耦合，咱們幫助他們作邊界的劃清，經過SDK的方式。基於Google Dapper實現的TRACE ID。

經過本身的MQ的切片、緩存的切片本身去查，不要問我，由於ABC消費B節點慢了，致使消費的速度慢了15.84，你本身去看，不要問我，個人MQ慢不慢，不是運維拼命把你拖慢，而是生產和消費不對等致使的，你本身去查。

這裏的內容你們能夠看一下，這個其實沒有什麼內容，無非就是裏面的一些協議，時間、機器、IP、調用類型、節點類型、SDK、服務，這是作短鏈路的時候很是清楚，我100毫秒到底消費在哪裏。

演進以後的狀況是什麼？你們看一下，我一個用戶當很慢的時候看這個界面，這個界面在前臺的閉環當中已經有了。

有的同窗說了，我不知道什麼叫切片，我後邊有一張圖。很簡單，你不用來找我，你找我幹嗎呢，你交易系統慢了，能夠看一下帳戶系統的切片慢不慢。

消息阻塞通例，也是經過下端消費直接狀況，

。這個很簡單，咱們在座若是作研發的同窗很簡單，我無非經過一些命令把MQ中間的數據接口反饋到數據庫當中，這個技術沒有什麼難的點。

4.從單機房到混合雲，咱們作了什麼？

咱們是從去年開始進行混合雲，有的同窗說了，幹嗎不知道作雙活呢？爲何不直接上公共雲呢？首當其衝的是監管不容許。

有的同窗說了，大家這個行業爲何這麼怪？是這樣的，金融行業跟錢有關的是強監管，全部的都是跟錢有關係的，個人交易系統不容許放到個人公共雲上，只能放在本身的私有系統中間，爲何？沒有技術上的任何問題，緣由是什麼，監管不容許，或者監管不明確。

因此能上的是資訊類的，行情類的，或者說其餘的跟金融基金交易牌照沒有任何關係的一些數據，能夠放到雲機房當中去。

遭遇故障或者流量突增的時候，咱們如今是這樣的，根據時間段不同來把咱們的中間件的主機放在雲機房。有的同窗問了，你剛纔不是說不能夠嗎？我說的是應用系統不表明中間件，中間件是能夠的。

我如今保證單機房的控制檯，從一個控制檯登陸能夠管理三個機房，能夠根據需求使用你的私有云和你的託管區，這是咱們的一張圖譜。

後面這幾張圖，這是咱們幾張界面，這是咱們如今用的，應用所屬產品線，咱們如今的雲整個中間件團隊運做模式跟阿里雲是徹底同樣的，說白了是咱們照抄人家的，組織結構也是照抄的，咱們全部的，包括緩存消息，分佈式數據庫，統一分配系統按照產品的規劃方式對外輸出，向全部的FT團隊進行兜售，好比說小張管A系統，小李管B系統，我跑過來賣。這是市場化經濟，有的同窗可能聽不懂，在咱們的公司所有都是CTO強壓的，你必須搞這個動做。

你們看到沒有？這就是一個很是經典的緩存界面，

不用展開，你們都知道。這個是你全部的緩存切片的圖，哪一個佔的最好，哪一個佔的最小。最後一張圖，是混合雲進行漂移的實例，能夠選擇不一樣的切邊。

舉一個例子，個人託管區就是我本身的老機房，我本身的控制檯沒有什麼問題，當我須要進行某一時間點擴容的時候，或者我由於某一些業務或者某一些活動要進行漂移，我把個人分片進行私有云的漂移，漂移到我私有云機房，說白了不叫漂移，就是重裝一套。

有同窗說，容器能夠作的更好，對，容器咱們目前只是嘗試階段，若是在座有同窗對阿里比較瞭解的話，淘寶以前其實不少不少年之前就作了，可是他們一直到這兩年螞蟻金服才作了一部分，或者沒有徹底作完，作金融類全部的技術改造類的東西，中間全部的數據驗證以及技術改變的成本和路徑都慢半拍甚至一拍至兩拍。全部的前臺、中臺，全部的過程全部的數據多少要對帳的，你不對帳是不能往上走的，可是中間件不須要。

同理，同樣的，有的同窗說了，災備區什麼意思？咱們遇到問題的時候，保證全部的機房可以全部用戶正常贖回就能夠了，我是徹底受損的一個服務，有的同窗說了你爲何不作雙活，要錢。

全部的技術，圈內有一句話，全部的優秀架構都不是設計出來的，優秀的架構是迭代和演變過程迭代出來的。你們相信嗎？全是迭代過來的，爲何迭代？由於需求堆出來的，無論是前端仍是後端業務需求。

5.AIOPS-展望將來

最後談一下 AIOps 的展望，我認爲的 AIOps 只是一個理念和方向，能提供什麼？彈性的伸縮。咱們如今作的更可能是人工的。咱們的彈性伸縮能夠作到自動化，其實 AlOps 在研發演進裏面沒有什麼困難，你只要可以抽象出規則，像擴容的這些動做很簡單，只要知足了某些場景，作了某些事情，前提是必定要標準化。

在研發的視角中，或者架構師的眼中並非很難的事情，可是要記得作提早更新。在北京有DevOps學院，裏面說過一句話，不少公司談DevOps，你NG還在調優呢，你還DevOps。那邊小夥伴在作NG調優，你這邊作DevOps，合適嗎？你沒有標準，怎麼作DevOps。

有的同窗說了，大家如今作到哪裏了？還在制定明年的規劃，咱們是騰訊系的，因此八九月份開始作明年的規劃。主要的目的是跟CEO要錢，這是最終目的，這是核心目的。

這是咱們面向PaaS的運維平臺，咱們原先沒有中臺的，沒有流程邏輯這塊的，咱們如今正在增長，因此我把顏色標爲橘黃色，下部分咱們都有了，咱們中間件的部分只包含中間很小一部分，在右側分佈式服務這塊，和預警告警這塊，其餘的部署發佈目前咱們都有。技術棧沒有什麼區別，也沒有什麼難的地方，就是如今外面你們用什麼咱們用什麼。

最後看兩張圖，首先不少人第一次見到我說，你一點都不像搞技術的人。爲何不像呢？體型不像，髮型也不像，我前天寫了一篇文章，技術男爲何那麼不愛乾淨或者穿着不受女孩子歡迎，在咱們圈子內IT男總找IT女，這種狀況多見，爲何？由於我比較喜歡運動，搞了這麼多年，看上去蠻年輕的，其實蠻大了。

這兩張圖能看到什麼不一樣點嗎？一個是運動跑步，一個是機房。在我看來太枯燥，跑步也是枯燥的，太乏味，甚至太難以堅持。

不少人說運動什麼東西都很難，運維也是同樣的，不少人說運維太過於枯燥，如今外面搖旗吶喊的說要幹掉傳統運維，雖然嘴巴沒說，一嘴巴的男女道德，一肚子男盜女娼。搞IT的結什麼婚啊？這是咱們圈內常常互相調侃說的一些段子。

因此我以爲，就是由於這樣的緣由，因此咱們的運維同窗也好，研發同窗，架構同窗你們更應該提升，你們在一塊兒共同解決問題。咱們如今公司如今已經變成純互聯網化。

個人內容就講這麼多，我基本從去年和前年開始，我本身常常會寫一些技術的文章，三年的演變我不可能靠幾分鐘就去講清楚，如今大概一週左右輸出1-2篇原創，是我本身寫的，裏面有技術的故事，有技術的演化包括我在外面參加的活動，你們有興趣的話，能夠一塊兒聊一聊。