金融全產品交易模式下，技術中臺應該是怎樣的？

點擊觀看大咖分享

抗擊疫情，騰訊雲在行動。科技步伐在向產業互聯網邁進的大趨勢下，互聯網體驗和傳統金融行業正在相互觸碰及深度交融。企業數字化轉型如火如荼，各類中臺戰略及相應互聯網架構的演進或重構正是當前IT的建設重點。本文是對TVP王曄倞老師的直播演講整理，爲你們介紹介紹整個技術中臺的演化過程，說明在實踐過程當中遇到的問題與條件，並帶領你們瞭解技術中臺的價值與將來發展。

本次騰訊雲大學大咖分享課程邀請 騰訊雲最具價值專家TVP 王曄倞 分享關於「金融全產品交易模式下，技術中臺應該是怎樣的？」課程的內容。

做者簡介：王曄倞， 騰訊雲最具價值專家TVP，好買財富架構總監。負責好買中間件及平臺化的研發及運營，團隊管理和實施重大技術決策。19年IT從業經驗，經歷過2000年網絡經濟泡沫的程序員，2011 年加入大智慧擔任測試總監，在2年內帶領團隊自研了「大智慧雲測試平臺」，經過平臺化將金融數據服務業務從瀑布式逐漸轉型爲DevOps。2013 年加入好買財富，在4年內親身經歷了公司面向互聯網的業務轉型與技術變遷，展轉過不一樣的業務團隊，對技術與業務都有必定的深刻了解。

本次分享內容：

一、什麼狀況下，技術中臺纔會有價值
二、技術中臺實踐過程當中的問題與挑戰
三、Q&A環節

相信不少人都聽過這樣一句話：脫離了整個業務場景談架構或者談技術，其實就是耍流氓。技術中臺最近這段時間很是火熱，在各樣的大會、文章裏面都出現過相關的話題。

不少人腦海中就會認爲：只要公司作大了，個人業務就要去作中臺，若是不作中臺好像我就活不下去，這種話題外界流傳的也很是多。

在我看來，中臺其實並無什麼標準，由於每家公司都會基於自身的業務場景來進行實踐，好比我這邊分享的是金融全產品交易模式，有的人可能基於公司的電商場景，有的多是遊戲平臺的場景，或者是其餘什麼場景。

我歷來不認爲中颱是一個什麼標準，由於每家公司都有本身的一些特性，這中間摻雜到人、組織結構、流程，SOP等等各樣的事務，全部摻和起來的總體更像是一個公司經營的戰略。 

因此，我認爲中颱不是一種技術實現，而是一種技術戰略。包括微服務，以前的SOA也都同樣， 它根本就不是一種技術。

若是你說它是一種技術，那麼它用的是什麼？它該用什麼語言仍是用什麼語言。服務又要怎麼拆呢？因此它實際上是一種業務模型，跟你的技術沒有多大關係。

我我的更贊同這句話：中臺它不是一種實現，它實際上是一種戰略或者佈局。

在這個佈局中間，會包含4個元素，除了技術、業務，還包括數據和組織結構。中臺的實現都是基於本身的業務去作的，有些公司本身只有一條單一的業務線，沒有複用，也就沒有必要去作中臺。

因此爲何咱們要去作中臺？無論是業務狀態的，仍是技術狀態的，簡單來講就是一句話：咱們須要複用！

由於當咱們的業務線開始變多，並逐漸造成了事業部，這時咱們就須要有這樣的一些技術手段，包括調整組織結構等等，用比較低的成本去支撐多條業務線的實現，這樣纔是一個划算的買賣。

什麼狀況下，技術中臺纔會有價值

1. 業務系統的演進過程

在談技術中臺以前，先簡單爲你們介紹一下咱們業務系統的演進過程，方便你們瞭解背景。 

咱們的發展歷程跟不少公司差很少，基本上都是從單體架構單產品開始，而後發展到單體架構須要去支撐多產品，再到從新定義。

咱們公司之前是作線下金融交易業務，從12年餘額寶出來以後，開始作線上。最開始實現的就是一個簡單的買賣交易，隨着產品線的增多和渠道商的增多，在2014-2016年咱們有重複建設的過程，在2017-2018年咱們造成了事業部，這時就須要對個人服務和架構以及業務條線進行重構結構的調整，這是很正常。

如上圖所示的1.0發展階段，由於咱們是基於基金來作理財的，有公募基金、私募基金。對於前端咱們有APP、網站、外部渠道的合做櫃檯等。交易的實現很簡單，就是作交易的服務模式和交易體系，包括咱們的支付，以及後臺的運營都很簡單，鏈接數據庫就能夠解決。

到了2.0時代，就須要一個單體架構去支撐多產品。咱們的軟件架構仍是同樣，可是隨着交易量的上升，可能要用到一些基礎組件，好比上圖左下角顯示的Redis、memcache等，這些也都是你們經常使用的。

同時咱們也開始有了本身的帳戶體系，從支付中間分離出咱們的帳戶中心，包括咱們也用到了不少MQ。

從後面的基礎組建中間，能夠發現一個頗有意思的問題，我相信不少公司都遇到這樣問題。

你用的任何一個技術或者選型一般都是根據你團隊的老大，好比你公司的CTO，或者一些技術債而決定的。

爲何要用這些技術？是由於以前有人用了，換你接手，短期內財力、物力、人力都解決不了，因此你只能沿用先前的技術。或者是你的老闆以爲某個東西好用，叫你也用。

因此你們可以發現咱們進化到2.0，各類技術選型和技術手段可謂五花八門，這是由於業務部門給到的壓力，只能快速的去應對。

這時就會產生如下4個問題：前臺負責部分業務拼裝、缺乏分層，系統相互調用、基礎組件五花八門、多套運營後臺。

舉個例子，假如你的前端團隊如今在作一個東西很忙，你的後臺團隊正在作一個東西，但並不那麼忙。這時公司須要上一個很急的項目，該怎麼辦？

從架構分層來講，應該是由前臺來作的。可是前臺如今很忙，讓項目排隊等候？對於不少的中小型企業，這是不可能的。

既而後臺團隊正空着，能夠先在上面開始作，這樣子看上去好像全部的人都很飽和。

但時間一長，也會帶來一個問題，就是在你快速發展的過程當中，會產生不少的技術債。

到最後你會發現，明明應該在後臺邏輯層去實現的東西，你卻在前臺實現了。前臺應該實現的東西，這些邏輯判斷卻在後臺實現。

這就致使了前臺負責部分業務拼裝的現象，尤爲是在業務發展速度很快的前提下。缺乏分層系統互相調用，也是由這個緣由致使的。

什麼基礎組建五花八門，多套運營後臺重複建設的問題不用多說，像這種階段相信你們都經歷過。

進入3.0階段，上圖顯示的是咱們的多業務線，在中間部位有機構、零售、高端、儲蓄罐、產品中心、帳戶中心、批量、後臺，支付後臺、報表後臺、交易後臺......

很明顯的看到，其實咱們已經開始把不一樣的產品放到不一樣的事業線裏面去了。

2. 技術中臺的前提

技術中臺實際上是一個技術戰略，這個戰略中間它包含了業務、數據、技術以及組織結構，甚至還有文化。

要作技術中臺，我我的認爲首先要具有兩個大前提：

（1）技術組織結構必定要垂直化

如前面所介紹的咱們公司的組織結構，這個系統的發育過程經歷了1.0、2.0、3.0等階段，到3.0時代以後，咱們纔開始有意識說咱們要去作一個所謂的技術中臺。

在1.0 和 2.0 的時代，咱們是按照職能來劃分的，以下圖所示，相信不少公司基本上都是按這樣來劃分的。

圖中用紅框標出來的就是咱們的研發團隊，研發團隊中間只包含研發，他們只作開發。後面還有兩個團隊，質量管理部，其實就是測試團隊和QA團隊，包括咱們的系統運維團隊。

這個組織結構是按職能來劃分的，測試和測試在一塊兒，研發和研發在一塊兒。那麼，對於這種結構，你們是否以爲有問題？

爲了解決這個問題，咱們須要從自身業務特性出發。做爲一家強業務驅動型的公司，通常看你的技術團隊、成本中心、產品中心這三樣東西。

有人可能好奇什麼是強業務驅動？能夠這樣理解，就是你賣出去賺錢的產品，是由於你業務的產品。好比咱們怎麼賺錢？就是賣咱們的金融產品，給客戶帶來收益，客戶分給咱們錢，咱們是靠這個活着的。

用最低的成本達到最高的產能效率來幫助你的業務得到更多的收益和流量，這個就是你成本中心的價值。質量更不用說，那爲何我把效率提高上來了？

對於一個正在快速發展的公司，哪個最重要？必定是效率！我能夠不惜成本，質量也不要緊，只要在交易的主鏈路中間不出現任何問題，就能夠在犧牲質量的前提下上線。

爲何這樣說？由於假如我有的東西缺失了，但只要服務化切得好，某一個東西壞了，可讓它下線，作服務降級也沒有問題，可是你的效率必定要快，由於要搶時間。

而在咱們1.0、2.0 時代，當時的按職能劃分的組織結構是頗有問題的，達不到提升效率的結果。

爲何這樣說呢？由於咱們當時存在一個痛點：因屁股決定腦殼而引起的多種多樣的中間件！每一個團隊獨立選型中間件，沒有統一的維護，沒有統一的知識積累，沒法獲得統一的保障。

在快速交付的過程當中，確定也會遇到各類障礙，開發、測試、運維團隊的目標不一致。好比測試A君，開發要求你只作功能測試，快上線，但測試老大卻要求你作非功能測試，保障質量，避免背鍋……到底聽誰的？從而陷入無休止的爭論。

基於1.0、2.0 階段的這種野蠻生長過程以後，咱們爲了解決每一個團隊的目標從而提升交付速度，決定把技術服務下沉，快速試錯，小步快跑。

最後把整個測試團隊以及運維團隊作了拆分，成了如今這個結構，也便是說把每一個測試、研發、運維分到了這些以功能爲目標團隊裏。

（2）業務線又多又複雜

再次以咱們自身爲例，以下圖所示，底部的7個紅色字塊，表明了咱們公司作的全品類產品。

將這些產品全整在一塊兒，不只對自身的資質、牌照提出了很高的要求，還伴生有技術性和業務性的許多問題，最可怕的是還有合規上的問題。

好比證監會跟保監會的東西就不能放在一塊兒，可是對於客戶來講，下100萬的單子，各買50萬的保險和股票型基金是一件很正常的事情，可是合規上就是不能夠。

這就是我所講的在系統建設過程當中出現的又多又複雜，還有一些合規上的問題。由於產品繁多，系統就顯得亂七八糟。

而業務創新比較多，須要先後臺系統定製開發，邏輯兼容難度增長。再加上業務邏輯分散，缺乏統一適配層，因此每次測試工做都須要 ALL IN。

以下圖所示，基於前面這些內容，咱們如今的整個技術前中後臺就是按這麼劃分的。

前臺主要是作功能，也是如今整個研發團隊中間人數最多的，大概佔到整體的60~70%。

中臺主要解決的就是中間件自動化運維以及集中自動化。

技術後臺是什麼？其實就是整個的基礎架構，網絡安全、存儲虛擬化，包括咱們的服務器，雲廠商這方面的一些問題。

技術中臺的做用，有點像編程時的適配層。適配層從上啓下，將整個公司的技術能力與業務能力分離。

中間咱們把整個團隊，包括總體的KPI、戰略所有分離了，作到技術能力和業務能力分離，並以產品化的方式向前臺提供技術賦能，造成強力的支撐。

至於把測試運維打散到產品線還可否高效跑起來，就看你技術中臺資源整合的能力了。

技術中臺實踐過程當中的問題與挑戰

在技術中臺的演進過程當中，咱們還面臨着三個挑戰：

1. 「屁股決定腦殼」

前面提到咱們技術前臺的團隊佔到全體人員的百分之六七十。顯而易見，假設個人前臺團隊有100我的的話，可能技術中臺只有20個到30我的。

在這樣的前提下，一個團隊要來應付前端這麼多人，勢必會遇到下面這些問題。

因爲理念、職責和節奏以及使命不一樣，再外加屁股決定腦殼的立場，前臺和中臺的矛盾是不少的。

從職責的角度，前臺他要的是快速應變，中臺要的是穩定高效提供服務。一個追求效率，一個追求質量，矛盾是自然存在的。

2. 「該死的技術債」

那麼前臺追求效率，中臺追求質量，兩邊的目標不一致，因此你前臺的需求中臺要怎樣去實現呢？

咱們來看一個場景示例，下圖展現的是咱們公司的技術中臺的一個產品，這個產品是A團隊和B團隊同時須要接入分佈式緩存。

A團隊、B團隊指的就是前臺的團隊，前臺A團隊因爲業務須要，同時向技術中臺提出了要求接入緩存的需求（技術中臺的中間件產品線中有一個基於代理的資源）。

由於A團隊和B團隊的技術債不同，兩個團隊系統也不同，因此必需要求增長適配器才能完成接入。

什麼叫適配器？簡單來講多是一個基於代理的SDK，或是基於某一個協議的。

若是以前另外一個團隊沒有用代理，而是直聯Redis，該怎麼辦呢？就只能經過中間適配器的方式來幫它橋接到如今這套系統裏面去。

爲何要這樣作？由於對於中臺團隊，這樣作的技術成本會很低。由於我只要維護一套系統，經過兩個適配器，兩個SDK的封裝包，就能解決。

3. 衆口難調

在咱們技術中臺作技術選型的時候，基本上都是出於老闆的豐富經驗。你的老闆用了A你就去用A，你老闆用了B技術你也只能用B技術。固然還有一些技術債的問題，這就致使了誰說了都算，誰說了也都不算這樣的尷尬境地。

混合交易場景下，技術中臺的將來在哪？

前面所說的多產品交易，基於多金融體系下的這種混合場景交易，咱們的技術中臺將來該怎麼走？

如今因爲咱們公司須要從線上轉型到線下，包括咱們自身的一些調整以及行業的變化，咱們的技術團隊人員在收縮，對於技術的投入愈來愈小。

前期已經把整個技術架子搭到這麼大，可是如今卻沒有那麼多的人和成本去投入，因此這是一個很悲慘的過程。

當你的產品比人還多，好比你技術中臺所提供的產品有30個，現有團隊就只有20多個，你想一想看你的服務會作得好嗎？

因此這個就是咱們接下去所要解決的一個很大的問題，前臺沒辦法變更，畢竟業務總得要作。當你的人員規模萎縮，可是業務還在，該怎麼辦？只能把這個事情往外走。

好比咱們從線上轉線下，APP和網站等都還在，外包又會限制你的效率和行業敏感度。而自建研發團隊，也會受到規模和技術投入上的限制。

你在缺人、缺經驗、缺錢，再加上一些客觀條件的限制，很多中小型企業可能只能摸着石頭過河，既沒有時間試錯，也沒有試錯的本錢。但需求仍然還在！

公司仍是會繼續給你提需求，因此只能要一點作一點、壞一點修一點，處於疲於奔命的狀態。基於這樣的狀況，最後咱們準備上騰訊雲。

由於咱們的業務轉型，對線上的依賴在降低，因此咱們如今能夠選擇把咱們一些標準的服務上到騰訊雲，完成咱們技術中臺的標準、工具以及團隊的逐步上雲。

後臺也是同樣，咱們能夠把咱們的服務器，包括咱們的網絡所有都上到騰訊雲，來解決咱們目前所須要的一些問題。

我以爲對於建設中臺，並不意味着中大獎，它實際上是靠每家公司逐漸演化才能產生收益的。

由於你作任何東西都須要投入，必定要記收益，不是作着玩的。技術中臺要基於本身的特性，它就像健身同樣，3個月有效果，10個月有結果，惋惜的是大多數企業基本上都是一拍腦殼就上了。

咱們的技術中臺是基於以前咱們的特性，中間有數據、有業務、有團隊、有流程、有文化，才造成了咱們如今所謂的技術中臺。它確實解決了幫咱們度過2015-2016年快速發展過程當中所須要的東西.

咱們如今之因此可以去上雲，並且咱們也可以制定成這個過程，就是由於咱們如今把整個技術變成了前中後臺，纔可以很是清晰的劃分出前臺和中後臺的區別。

咱們才能把中、後臺逐漸的往騰訊雲上遷移，咱們也清楚了哪些東西須要去上雲，哪些東西是不要上雲的。

Q&A

Q：公司也要作中臺產品，這是企業的將來道路嗎？

A：你無論你作什麼中臺，首先你須要有必定的規模，並且你要多業務線，而後你的組織結構要相對偏垂直，也就是你們分工要明確，而且你有不少複用的需求，你纔有必要去作中臺。

Q：創業公司如何低成本搭建中臺，如何說服領導大建中臺，解決技術和業務效率低的問題？

A：我的建議，若是你如今的團隊還在100人如下，也沒有那麼多業務線的話，我建議你不要走這條路，繼續走原先的路。除了上面談到的組織結構的問題，即使是換成中臺垂直的模式，也有不少新的問題出現。若是你的複用用到很少，我的建議你仍是說服領導不要去作中臺了。

問卷

爲了給廣大開發者提供最實用、最熱門前沿、最乾貨的視頻教程，請讓咱們聽到你的須要，感謝您的時間！點擊填寫 問卷

騰訊雲大學是騰訊雲旗下面向雲生態用戶的一站式學習成長平臺。騰訊雲大學大咖分享每週邀請內部技術大咖，爲你提供免費、專業、行業最新技術動態分享。