東方金科基於開源的開發平臺建設之路

李家智 ,就職於東方金科,現任架構師一職。作為行業享有盛名的大咖，李家智行事低調，對工作熱情飽滿，多次受邀作為嘉賓出席各類大會，並發表了精彩演講。2018年10月17日,李家智 受邀參加了由IT168主辦的《SACC 2018第十屆系統架構師大會》,並發表了精彩演講，以下內容根據 SACC大會實錄整理。

什麼是金融公司裡的IT公司？

東方金科東方金科是東方邦信融通控股全資子公司，是中國東方資產管理公司旗下唯一一家科技公司，也是典型的金融公司的IT公司。

中國東方資產管理股份有限公司，成立於1999年，註冊資本為100億元人民幣，處置中行剝離出的政策性不良資產。2016年, 經國務院批准中國東方改製為股份有限公司。2017年，在主管監管部門的支援和指導下，中國東方順利完成引入戰略投資者工作，成功引入全國社會保障基金理事會、中國電信集團有限公司、國新資本有限公司、上海電氣集團股份有限公司等四家投資者。

截至2017年末，中國東方集團總資產超過9,800億元，在國內中心城市設有25家分公司和1家經營部，業務涵蓋不良資產、保險、銀行、證券、信託、普惠金融、信用評級，國際業務等。

金融公司裡的IT公司通常有三種運營方式：

第一種是信科部門獨立運營，比如：建信金融，還有民生科技等。因IT部門具有特殊性，獨立運營有利於做得更專業，薪酬能夠更加市場化，有利於留住更多IT人才。

第二種是拆分運營，比如：興業數金、招銀雲創。將本行的IT系統、金融雲、運營和維護能力輸出給中小型金融機構。

第三種是新建子公司，成立網際網路金融綜合平臺，像光大雲付一樣。與網際網路公司相比，這類公司更瞭解銀行，對銀行的要求理解得更為深刻，對監管的要求和規則執行得更到位。

基於開源的開發平臺如何構建？

對於金融企業來說，大家都在強調要有自己的開發平臺。為什麼這樣做?

東方金科架構師李家智的看法是：首先，是政策原因，技術必須要自主可控。其次，歷史原因。資產公司的IT資訊化建設發展較晚，早期的系統都是交給第三方廠商完成。新的技術創新環境會推動科技企業自己做開發平臺，和第三方廠商協作完成。

現在的東方金科仍然是以第三方合作廠商為主，東方金科輔助廠商去共同研發。希望未來能以東方金科研發的開發平臺為主，和廠商協作，來交付金融系統。

開發平臺早期是像“火鍋”，有底料，有牛、羊肉，有配菜，根據金融系統的不同需求，提供不同的產品。未來隨著金融系統的成熟發展，其開發平臺也會發生變化，這種變化更像是各種品牌的汽車。有奧迪的不同款型，也有保時捷，它們雖然都是汽車，但是都來自於同一款大眾MLP平臺。未來，金融系統的開發平臺也要這樣做。

金融系統的開發平臺應該自下向上構建，每一層都可以以專案的形式落地。第一層是開發規範和管理規範;第二層是技術框架和UI庫;第三層是業務參考模型;第四層是服務和元件;第五層是開發平臺;第六層是視覺化開發平臺。

在技術框架的選擇上，東方金科是在公司內部業務基礎上定義的一套後臺系統，有業務參考模型，包括使用者決策許可權什麼，有服務元件，有文件預覽服務，還有處理服務元件，包括各種UI控制元件、Java控制元件，在這基礎上構建了自己的開發平臺。金融企業應用的業務參考模型，流程相比於網際網路企業同樣的模型和流程，更有深度。

在團隊架構方面，包括幾大部分。

第一，是資訊科技部，負責指導監督計劃執行，還有成果落地。因為開發平臺並不是一蹴而就的，它的每一部分成果都可以在專案中使用，所以這部分由資訊科技部去指導，由專案經理負責去落地。

第二，是三方諮詢團隊，是由東方資產聘請的第三方公司負責做技術諮詢和技術評審。

第三，是金科技術委員會，也做技術支援，技術評審，這是一個內部的委員會。當然東方資產也有個技術委員會，級別更高，有些內部解決不了的問題，就會往更高的技術部門去彙報。

第四，是專案群中專案經理，負責開發平臺已有部分成果落地。

第五，是PMO監督計劃執行。

第六，是技術創新部，負責研發開發平臺，同時也同其他團隊做一些協作，比如UI前端以及網際網路技術合作等。

在開源技術框架構建時，東方金科踩過很多坑。

第一個坑是，是否採用Spring Boot。雖然，現在看採用Spring Boot毋庸置疑。但是兩年前，爭議非常大。自有技術框架在公司群眾基礎好，呼聲高，Spring Boot 瞭解人少。但是最後的結論是，採用Spring Boot。自有技術呼聲敗給了時間的流逝，Spring Boot開始碾壓式的流行。

第二個坑，平臺是否需要支援視覺化開發?當時，公司上下都對這個功能曾非常有興趣。後來調研了商業軟體，覺得開發效率提升有限。業務邏輯過於複雜，視覺化做不到。最後的結論是：不做視覺化開發，做程式碼生成。

第三個坑是，是否為業務人員提供完善的流程設計器?業務人員直接參與流程的定製和部署，這是一個美好願望。但是流程過於複雜，不支援直接部署，業務人員更傾向於提供需求，而不直接參與流程定製。所以，最後做了不需要完善的面向業務人員的流程設計器。

第四個坑是，工作流是否需具備固定的使用者模型?集團層級複雜，彙報路徑多樣。工作流應用到各個專案中的使用者模型不一致。最後的結論是，工作流不具有固定使用者模型，有業務端解釋使用者模型而不是工作流。

第五個坑是，UI元件庫是什麼樣式?視覺團隊提供了素色的一個版本，但是總裁喜歡活潑一點。網際網路研發團隊也有自己的風格偏好，比如，字型大，間距大。企業應用研發團隊認為頁面內容需要密集展現。大家一致認為應該以業務需求為導向，但是對於開發平臺，業務人員根本沒空。最後，先有一個風格再說，技術上必須易於調整。

第六個坑是，前端框架用哪個?React,Vue,Angular 小規模用過 ， Bootstrap+JQuery 前端人員非常熟悉。3個月的React使用失敗，現有React元件庫無法支撐金融後臺UI系統需求。傳統企業應用公司，開發模式決定了前端人員一直儲備不足。最後只能回到傳統開發模式，使用Bootstrap+JQuery。

第七個坑是，用成熟的商業開發平臺還是自研?商業和開源產品都調研過。商用產品價格不菲，從十萬到百萬、千萬。並且，商業產品落地成本較高，部分產品商用技術較為落後，不支援系統拆分。最終選擇了自研，好處是成本小，貼近業務需求。

第八個坑是，開發平臺如何落地?金融系統規模較大，不會輕易更換技術。並且融系統數量有限，能使用機會不多，不同於網際網路系統，東方金科的選擇是“零敲牛皮糖”。

第九個坑是，阿里開發手冊還是唯品會開發規範?“孤盡”名氣大，“江南白衣” 也不是浪得虛名。唯品會開發規範和落地結合，與Clean Code和 Effective Java結合也很緊密。結論是，選用唯品會開發規範，並取得授權。

第十個坑是，怎麼解決技術偏好之爭?當時的分歧主要有三個：分歧一：專案骨幹之間技術之爭;分歧二：技術委員會之間技術之爭;分歧三：與諮詢公司的技術之爭。結論是，選擇正流行的開源技術，因為能自主掌控的技術就是可選技術。

第十一個坑是，企業是否需要統一的組織架構檢視?每個系統，無論大小，都有一個使用者和組織機構模型，每個系統都會重複建設，但是每個系統關注的組織機構模型“深度”不一樣。最終決定是，每個系統暫時擁有各自的組織機構模型，開發平臺根據“深度”要求定製模型。

第十二個坑是，遺留系統問題。作為以業務驅動為主的公司，技術創新非常尷尬。研發人員不足，研發投入不足，研發成果落地困難，研發和專案群關係尚未理順。

為什麼會選擇Spring Boot 2 ？

之所以選擇Spring Boot 2，是因為它是現成的技術框架，凝聚著國內千萬軟體企業曾經的努力結果。另外，Spring Boot的開發特別簡單。雖然Spring Boot有著自己的問題，比如對配置的依賴，後期擴充套件很難。但是，它能簡化部署，還能進行部署監控等。最重要的是，Spring Boot改變了應用系統組織方式，能將系統拆分成小系統或者微服務。

舉一個例子，Spring Boot能讓單元測試更加簡單。現在單元測試面臨的現狀是，大部分程式設計師一直宣稱自己做了單元測試，但實際上這是一個假的單元測試。因為單元測試有個特點是，必須是可以重複測試，但實際上據我所知，很多單測試都無法重複的。

Spring Boot讓測試變成非常簡單，比如它可以透過註解，來模擬一個無法測試的內容，或者還未完成類。比如我們的積分系統管理，管理是一種設定，是一個沒辦法去做的單元測試。我們可以模擬一下，比如說模擬一個使用者輸入，模擬使用者輸出，這樣去測試。還可以模擬各種情況，比如模擬異常或者模擬呼叫次數。

企業應用很多測試會涉及到資料庫，大多數會選擇最初始化的一個資料庫指令碼去做測試。但是這樣會有兩個問題。第一個問題就是條款本身不是特別直觀，尤其對於企業資料來說，它會產生大量的資料。如果用生物小本模擬，其實對於維護來說不是特別直觀。第二個問題，你在單元測試完畢需要去做比較驗證的時候，也需要寫大量的程式碼去比較驗證。如果從資料庫取資料，還要看介面是不是一樣，所以說我們在開發平臺也做了一定程度增強。用Excel來模擬一個測資料，比如包含註冊，我們也可以應用庫的一個其他的一個基礎的測資料。

我們除錯了各個表資料表資料可以呼叫的方法，也可以定義變數，在測試完畢過後，可以將資料庫資料跟Excel資料進行比較。這樣單元測試程式碼量就非常小，而且非常容易維護。無論是開發人員或者專案經理，或者需求人員，都能看明白你要測試什麼，結果是什麼，所以我們增強了資料模擬和測試驗證。

Activiti 流程引擎的重要性

Activiti是流程引擎，採用它，是因為它是基於BPMN2.0，成熟可靠。並且，它的設計是將執行流程和歷史流程分開，能支援數十萬流程的同時執行。還有，國內有很多Activiti擴充套件的文章和工具。

如果沒有接觸過工作流，想象中的工作流程應該是按照環節劃分，以單線形式進行設計。實際應用中，系統裡面能審批的流程非常少，這並不意味著企業沒有決策執行，只是能落地到流程的內容很少。普通的流程跳轉是正常流程，節點之間需要新增連線，任務撤回是不可能的，流程結束不可能恢復。但是國內應用很任性，流程節點可以任意跳，任意回退，不必要定義連線，只要新任務未處理，就可以撤回，結束的流程也能起死回生，並且可以回到任意節點。

有人可能會說，為什麼要回溯，能不能重新發一個流程?對於東方資產來說，重新發一個流程的成本非常大，環節特別多，會經過很多公司，甚至還涉及到很多總裁、經理、委員會的審批等。

Activiti流程引擎能大大降低了流程的複雜度。

那麼，開源開發平臺到底要怎樣構建?最後總結一點，企業要基於開源技術自己幹構建，並且整個開發平臺要自下而上，逐層構建。