恆豐銀行微服務架構優化實踐

「Weniger aber besser（少而優）」是德國工業設計大師 Dieter Rams 崇尚的設計理念，也是喬布斯「至繁歸於至簡」的精髓所在。

關於架構，是不是越複雜越好呢？從各大金融案例來看，恰恰相反，簡單才是硬道理。這也正是微服務能夠流行的原因，市場上出現的服務架構如 EJB、SCA、Dubbo 等，相比微服務來說他們的功能更完善，但因為它們過於複雜，所以都沒有微服務這麼深入民心。

目前，微服務架構已經在金融企業範圍內實踐應用，伴隨著系統不斷的優化，企業會選擇在原有基礎進行改進，或者開發更多適合企業業務的新架構平台，這也許就是簡單框架流行的本質。

本文就圍繞微服務架構在恆豐銀行的使用案例，採訪恆豐銀行科技開發部資深軟體架構師 曾光堯老師，請他談談微服務架構給恆豐銀行帶來了哪些收益，以及恆豐在微服務架構上做了哪些研發。

InfoQ：曾老師，您提到說，恆豐銀行開發團隊自己研發了很多自適配的服務，是因為傳統技術架構存在性能瓶頸，這裡可否詳細的介紹一些性能瓶頸有哪些？

曾光堯：銀行傳統的應用服務架構大多數是基於 J2EE 體系的，在大家熟悉的 Tomcat、JBoss、WebLogic 等應用服務容器上開發部署，應用軟體通過較流行的 Spring/Struts/Hibernate 等技術框架實現對象容器化管理、MVC 分層、數據對象映射等基礎能力。大部分的應用服務容器都是傳統的多線程系統架構模式，通過服務線程池調度實現對外部請求的響應。由於操作系統線程切換代價較大等原因，在傳統多線程架構下單個節點能夠同時服務的客戶端有限，並發服務能力始終沒辦法獲得大的提升，在我們實際生產環境中，單節點應用服務的 Qps 一般在 1000 以內。

通過學習國外先進網站的應用技術架構特點，和現有的架構做比較，我們可以發現傳統多線程服務架構不能有效發揮當前 CPU 多核的硬體優勢，存在如下缺點：

在網路多路復用 IO 技術選擇上，大部分應用服務容器採用 select/poll 機制，對操作系統內核的負擔較重, 容易遭遇 C10K 問題（即單個伺服器節點客戶端連接不能超過 1 萬）。而在目前移動互聯應用場景下，手機設備往往需要和後端應用伺服器建立 WebSocket 這種全雙工的長連接，以提升客戶交互體驗，這就對單台伺服器能連接的設備數量提出了更高要求。

一個客戶端請求在執行過程中獨佔一個服務線程，應用服務容器同時處理的請求任務數取決於線程池大小，我們往往需要配置較大線程池（一個 CPU 邏輯核對應 10 個以上線程）才能實現更大的並發處理能力。但在高並發場景下，線程數越大意味著操作系統的線程切換管理負擔加大，從而減少硬體資源的有效利用率，增加服務響應時間，降低伺服器負載容量。

線程之間共享資源操作需要藉助鎖機制，而在高並發場景下，鎖衝突會加劇，從而影響業務邏輯的執行效率和線程資源的使用效率。

在客戶端請求執行過程中只能採用同步（阻塞式）IO 機制，在商業應用中，伺服器線程大部分時間是花在 IO 等待上面，比如本地文件讀寫或網路服務等待上。

傳統應用服務容器本質上還是單體應用，高度容錯的分散式並行處理編程困難，業務邏輯難以拆分成多個並行處理子過程，無法有效利用多節點和多核的 X86 伺服器集群硬體優勢，業務邏輯越複雜對客戶端的響應時間也越慢。

綜上所述，我們認為傳統服務架構因為網路多路復用 IO 機制、線程調度、鎖資源競爭、同步 IO 等因素，難以有效利用 CPU 計算資源和實現業務邏輯的並行化處理， 整體服務承載能力有效，不能滿足移動互聯應用場景高並發低延遲的技術能力要求。

InfoQ：簡單介紹一下恆豐銀行的業務特點是什麼？對整個公司的 IT 架構有什麼特殊的規格？

曾光堯：恆豐銀行是 12 家全國性股份制商業銀行之一，經營的金融業務種類齊全，近年來業務發展穩健快速。恆豐銀行致力於做「知識和科技的傳播者、渠道和平台的建設者、金融綜合解決方案的提供者」。提出了「四輪驅動、兩翼齊飛」的經營策略（「四輪」是指企業金融、金融市場、零售金融、移動金融業務，「兩翼」則是投資銀行和資產管理業務），依託金融雲平台和大數據平台，實現龍頭金融、平台金融、家庭金融、O2O 金融等四大金融創新業務模式，打造數字銀行、交易銀行、銀行的銀行，力求為客戶和社會提供效率最高、體驗最佳的綜合金融服務。

恆豐銀行的發展戰略意圖是如何更好發揮金融媒介作用，整合金融服務資源和能力並與社會經濟活動、大眾生活場景相結合，實現社會多方參與協作的業務模式創新。恆豐銀行突破物理網點的限制，面向細分客戶群體的不同需求，有針對性地設計產品和業務流程，並以數字化運營為基礎，充分發揮移動互聯網路的優勢，為客戶提供便捷個性化、智能場景化的創新金融服務。唯有如此，才能在激烈競爭的金融市場存活並獲得發展，才能揚長避短實現彎道超車。

行內業務發展對 IT 系統建設提出的總體要求是「打造數字化驅動的智慧銀行」，從 IT 架構規劃和實施的角度，體現為如下幾點：

充分利用雲計算技術的優勢，打造靈活高效並支持彈性部署的軟體服務基礎設施，支持高並發低延遲的移動互聯場景應用需求，支持銀行業務重心從線下到線上的轉移，滿足客戶通過各種移動設備和自助機具獲得良好服務體驗的需求。

打造基於大數據技術的數字化運營體系，實現海量數據的自動化獲取、加工處理、深度挖掘，並運用數據智能技術構建恆豐銀行的「智慧業務大腦」，實現智慧網點服務、智能風控體系、智能獲客與產品個性化推薦、實時的業務分析與決策支持。這也意味著一筆簡單的線上客戶交易，後台發生的事會越來越複雜，除了傳統的交易帳務處理之外，還可能涉及到客戶線上操作行為的採集、交易反欺詐引擎的規則判斷和模式計算、交易完成後個性化的產品推薦和業務提醒、基於地理位置的生活場景服務推送；與此同時，客戶實時業務視圖在後台自動更新處理，不同的業務部門按照各自管理視角定製的實時業務分析看板也要重新計算和刷新。

堅守銀行系統運行安全可靠的底線，在積極實現業務創新的同時，提供穩定可靠的服務質量。如在應對「雙十一」購物狂歡節等特定的交易峰值是能保持穩定的服務能力輸出；局部的程序缺陷造成的影響能有效隔離和自動修復，不好出現全局性的服務可用性問題。

InfoQ：恆豐銀行在設計微服務架構初期，有什麼樣的考量，需要規避哪些可能存在的坑？

曾光堯：企業應用軟體架構經歷以 TCP/IP 網路通信編程為特徵的 Client/Server 模式、以 IDL 介面描述語言為特徵的分散式組件對象架構（DCOM 和 CORBA 為代表）、以 WSDL/WebService/ESB 為特徵的 SOA 面向服務架構，一直進化到 Reactive/ 容器化 /DevOps 為特徵的微服務架構。每一次應用軟體架構的變化，都號稱解決了以前的問題，簡化了應用的開發，但對於大多數程序員來說，好像都是痛苦地被裹挾到這個軟體進化的洪流，不得不適應主流技術架構的變化，在這個過程中的一知半解往往會引發無法預見的問題。

從我個人的角度看，這 20 多年應用軟體架構變化主要有如下動因：

簡化和屏蔽複雜的底層網路通訊細節，增強網路服務的可管理性和位置透明。

將越來越複雜的現實應用程序分拆為更小的軟體部件，不斷弱化部件之間的耦合度，降低部件的開發難度，優化它們組合成完整應用的實現形式。

將解耦後的軟體部件部署為分散式輕型化的組件服務，增強組件服務的自治性、容錯性，更好地實現分散式並行處理能力。

微服務架構在恆豐銀行被採用的原因，主要因為當前應用的複雜度和應用服務的彈性部署要求。通過將大的單體應用系統分拆為多個松耦合、可獨立運行的微服務組件，可按業務和技術職能劃分給更小的團隊獨立開發，減少代碼變更對整體應用的影響，對不同的應用部件按需彈性配置硬體資源。

容易陷入的認知誤區是：

認為應用程序只是換了一種運行容器或基礎設施，大家還是按照單體應用程序的構建形式開發和部署軟體。

把握不好微服務的粒度劃分原則。粒度劃分過細導致微服務過多，會增加跨網路的介面調用成本和降低響應速度，加大運維部署成本和資源分配難度；粒度劃分過粗，甚至退化為原有的三層結構，不容易隔離業務應用之間的影響，為出現性能瓶頸的軟體部件分配更多的硬體資源。

考慮到我們需要採用 Reactive 微服務架構去解決傳統架構存在的問題，我們還是從技術和業務兩個維度去切割微服務：

用非同步化編程模式包裝各種網路服務為基礎的微服務組件，如資料庫服務、FTP 服務、MQ 服務等，這些服務局限在應用內部調用，一般不對外開放。這種做法可以簡化網路服務調用的複雜交互控制細節，為後端網路服務的壓力負荷管理提供可能性。

消耗 CPU 較多的複雜迭代演算法或內存計算任務，微服務化後可以更好地支持分散式並行處理。如蒙特卡洛模擬等演算法，可以切分搜索空間，發送給不同節點去做實際運算。

具備獨立的業務能力的軟體模塊，介面比較穩定或者可以設計得比較寬泛（如通過可變參數列表形式），多個微服務化的業務組件可以組合成更加複雜的業務功能服務。

InfoQ：最終選擇 Akka 作為微服務基礎軟體框架的原因是什麼？更關注 Akka 的什麼功能特性？

曾光堯：Akka 作為高性能、高度容錯、支持彈性部署的成熟方案，Actor 模式的特性可以很好地用來實現微服務。其詳細特點描述如下：

Akka 消息處理的高性能。單節點每秒可完成 5000 萬消息處理。

資源需求低，每 GB 內存可容納 250 萬 Actor 實體對象。

Akka 的成熟度。是著名的 Spark 大數據平台的底層架構軟體，也被 BBC、Amazon、Cisco、eBay、Groupon 等眾多大企業採用，並在 2015 年獲得 JAX 創新開發技術大獎。

基於強大的 Scala 語言編寫，編碼實現效率高，可以和其他 JVM 語言類庫相互調用。

角色（Actor）並發編程模型較好地屏蔽了底層通訊細節和線程任務調度細節，編程較容易；基於消息傳遞機制實現服務協同和數據共享，消除資源鎖競爭。

來源於 Amazon Dynamo 系統的 Gossip 集群通訊協議，經過 Amazon 雲服務平台的長期技術驗證，可靠性高。可支持 Cluster Sharding、Cluster Singleton、Distributed Publish Subscribe、Distributed Data 等多種集群應用場景。

父子角色對象（Actor）的監管者（Supervisor）模式。父角色對象可以捕獲子角色對象的異常並自動執行不同的重啟策略，極大提高了系統的容錯性和服務可用性，減少高可用性代碼編寫難度。

通過軟體路由器 (router) 和執行分發器 (dispatcher) 組合實現多種 Actor 並發和負載均衡演算法策略，構建軟體彈性部署能力。其中路由器支持如輪詢調度（round robin)、隨機調度 (random)、廣播（broadcast)、一致性哈希（Consistent Hashing）等任務分配演算法；執行分發器構建獨立線程池，隔離不同類型 Actor 之間的 CPU 資源競爭影響。

InfoQ：據了解，恆豐自研基於 Akka 的微服務架構平台 Skyline 進行相關組件開發，那麼最後實現了那些需求，效果如何？Skyline 在恆豐內部還發揮了哪些作用？

曾光堯：Akka 等微服務軟體框架上的應用開發存在工程實現難度，主要表現為如下三點：

受限於語言本身對分散式並行處理的支持程度不高，大部分基於微服務或非同步 IO 框架的軟體開發需要關注非同步通訊的交互細節，容易陷入嵌套非同步回調的編程陷阱，不符合大部分程序員順序編程思維的習慣，開發和調試都非常困難。

基礎平台層面缺乏應對峰值壓力下的自適應調整能力，容易將訪問壓力傳導到資料庫等更脆弱的基礎軟體設施，導致系統整體崩潰。

缺乏在運行時對不同服務質量的差異化管理機制，在雲計算環境下的動態部署能力受限。

針對上述技術難點，我們在 Akka 的基礎上自研了 Skyline 微服務架構平台，針對上述三類問題，我們的技術解決方案為：

獨立自主設計實現了支持分散式並行計算的新編程語言 Zebra，實現多種並行處理範式，支持微服務的非同步並行調用。

微服務組件化，實現服務組件容器，實現服務組件實例的彈性創建和銷毀，服務請求的排隊、超時清理、過載阻斷，保護後端較脆弱的服務設施，提供穩定的服務質量。

服務組件容器支持不同微服務的並發實例數、使用線程資源池、任務隊列長度、超時時間、部署物理節點等動態配置項，可以在運行時動態調整，以支持差異化的服務質量。

Skyline 平台最終實現的效果為：

實現高並發低延遲服務能力。Zebra 分散式並行服務語言通過增強語法支持非同步並行服務調用，通過數據並行、指令並行、Pipeline 等三種方式提升程序的運行速度，降低響應延遲時間；Zeroutine 協程調度框架減少線程切換成本，構建完全無阻塞的程序運行機制，有效提高服務吞吐量。

提供穩定可靠服務輸出。服務組件容器技術實現微服務實例的按需自適應調整和峰值壓力下的排隊緩存、超時清理和過載阻斷機制；組件容器隔離程序缺陷影響，實現異常崩潰後的快速重啟；並通過 Zebra 語言的契約式編程範式提升代碼質量，隔離不同模塊和應用系統的錯誤影響。

更好的彈性部署能力。可動態配置的服務組件部署機制，支持多種集群部署模式；從並發處理能力、單位時間最大吞吐量、線程資源等多個維度實現彈性的服務部署策略；與 Docker 容器雲技術結合實現硬體資源的彈性擴容。

Skyline 平台解決了系統容錯、集群彈性部署、快速開發測試、應用服務間集成、數據並行化處理、系統過載的服務可用性等關鍵問題，對移動互聯場景下高性能數據應用服務開發提供了完整有效的平台工具支持；基於 Zebra 語言編寫的商業邏輯代碼能有效屏蔽底層服務技術細節，加快分散式並行數據處理應用服務的開發效率。恆豐銀行在客戶營銷、風險管理等多個業務領域基於 Skyline 平台開發了近 30 多個應用和公共服務，單節點的 QPS 值達到 7 萬多，應用服務的總體硬體成本降為原來的 1/5-1/10，高質量分散式軟體服務的開發成本降為原來的 1/2，並且可以節約較多的商用中間件軟體的採購成本。

InfoQ：請介紹在微服務架構下，是如何與大數據軟體生態集成，如何快速開發實時創新應用的？

曾光堯：Skyline 平台主要通過如下幾個方面實現和大數據軟體生態的集成和整合：

開發相關網路服務適配器。將我們能用到的大數據軟體（如 Kafka、Hbase、Spark 等）的客戶端代碼包裝成可動態配置參數的適配器組件，屏蔽複雜的介面交互細節、異常處理等事項，該組件能被容器部署並動態管理，在 Zebra 腳本語言中非同步調用，並支持多種並行處理模式對應用加速。

實現了分散式實時消息匯流排。通過服務代理機制集成了 MQ、Kafka 等多種消息設施。與其他技術方案相比，提供了統一的發布訂閱編程原語，容易擴展集成多種消息設施，可在客戶端與客戶端、客戶端與伺服器以及多個伺服器之間實現一致性的即時消息通訊開發；支持可插入式的消息編碼解碼演算法，支持 Pub-Sub、RPC、OneWay 三種介面調用方式，可在 Web 端通過 WebSocket 直接調用 Zebra 函數實現分散式並行數據處理。

Skyline 分散式實時消息匯流排結合 Flume、Kafka，打造完整的實時流處理平台。開發操作系統、資料庫和各種網路服務的數據探針，對接多種系統數據源；開發管理工具，支持數據採集、格式化處理、數據過濾、聚合計算、數據補全、數據存儲、數據流控等過程的動態配置和自動化部署；可動態嵌入 Zebra 語言編寫的業務邏輯處理代碼，提升後端服務的並行處理效率。與其他流處理方案相比，業務編程更簡單，可實現高並發無阻塞的業務處理過程，支持多系統動態集成，可充分利用分散式硬體資源優勢。

開發面向業務團隊的實時智能決策引擎。業務團隊可通過可視化工具配置客戶營銷、風險管理等領域的業務知識庫、業務規則路由，支持複雜規則驅動的業務邏輯處理，實現營銷機會的實時推送和潛在風險的實時預警。

以信用卡交易監測應用為例，基於 Skyline 平台的實現步驟如下：

在流處理管理平台定義 APM 網路報文日誌實時採集和動態解析加工規則，自動部署 agent 到相關應用服務節點；flume collect 將 agent 發過來報文數據按預定義的規則解析成結構化數據，轉入 Kafka 的交易信息主題。

執行 Zebra 業務處理代碼的流處理組件訂閱了交易信息主題，能及時收到相關交易數據，非同步存儲到實時流緩存資料庫；交易數據接著觸發實時智能決策引擎的規則推理過程，輸出判斷交易風險的分類數據，並轉發到信用卡交易風險數據主題。

信用卡交易風險數據主題被風險處置的流業務組件所訂閱，可以根據風險分類等級，確定執行卡凍結、還是增加新的驗證環節等處置手段。

整個過程大部分可通過實時流處理平台的數據採集和加工解析配置、智能決策引擎的知識庫與規則路由配置，加上較少的 Zebra 業務處理代碼來實現，大數據平台上的實時創新應用開發會比較快。

InfoQ：恆豐銀行針對微服務架構做了哪些性能優化、性能調優方面的舉措？如何提升它的高可用性能？

曾光堯：恆豐銀行在構建 Skyline 微服務架構平台時設計了如下性能優化的機制：

Skyline 的協程架構和非同步服務調用機制，zebra 編寫的業務邏輯處理組件在容器中可以用接近於邏輯核的線程數實現無阻塞運行，完全避免了線程切換成本。

網路服務通過適配器組件包裝並單獨 docker 化部署，可實現不同訪問成本任務的差異化並發控制，最大化提升後端傳統服務架構的吞吐量，與業務邏輯任務有效隔離，避免不同類型代碼模塊的執行速度失配，影響系統整體的高並發服務能力。

Skyline 的分散式實時消息匯流排，可實現各種設備與後端服務的長連接，減少網路延遲時間。

Zebra 語言提供的多種任務並行化機制，可提升單個任務的並行度，充分利用分散式硬體資源，極大降低任務的響應時間。

Skyline 平台基於 Actor 的組件編程模式，消除了資源鎖競爭，提高了並發任務的執行效率。

大部分應用調優可通過 Skyline 平台組件容器的運行策略動態調整解決，具備運維的便利性。

高可用性主要體現在如下方面：

Docker 容器化部署實現了硬體故障的失效轉移和快速重啟。

組件容器實現任務的緩存排隊、超時清理和過載阻斷，可有效緩衝峰值壓力，實現穩定平衡的服務輸出；基於異常處理的策略化管理，可有效隔離程序缺陷，實現異常服務組件微秒級的快速恢復。

涉及網路服務的關鍵組件和分散式實時消息匯流排都實現了心跳活躍檢測和自動化重建連接的機制，提升了網路化服務的高可用性。

Zebra 語言支持契約式編程機制，可在開發測試階段提前發現業務邏輯缺陷，並在運行時有效阻斷程序異常缺陷在不同軟體部件中傳播。

增強的 Raft 協議服務組件，可構建跨中心的組件服務，實現多中心的運行時災備容錯，構建永不停頓的服務質量。

InfoQ：最後，問一個經驗類的問題，您擁有 22 年的銀行 IT 系統開發經驗，可不可以談談，銀行系統開發經歷了哪些變革階段？當前的銀行系統需要具備什麼樣的特性？如何與最熱的 AI 技術、FinTech 技術相結合呢？

曾光堯：商業銀行 IT 系統的開發演進基本跟隨了軟體技術的各個發展階段：

1990 年代早期，主機 - 終端時代，編程語言為 C/COBOL。銀行的主要 IT 系統是核心帳務處理系統，架設在集中式的主機之上（大行採用小型機或中型機，小行採用 PC 伺服器），網點通過終端與主機連接，一般只能構建同城的終端網路系統，實現了同城業務集中和通存通兌。那個年代推廣一套系統，包里揣個硬碟就出去了。

1990 年代中後期，客戶機 / 伺服器架構時代。銀行 IT 系統建設開始提以客戶為中心的綜合業務系統概念，開始實施區域集中的核心銀行系統，地市前置機系統外掛網點終端設備，通過 DDN 專線與省行帳務處理主機相連，採用交易通訊中間件或通過 TCP/IP 協議實現前置機與帳務主機的報文通訊和交易一致性機制。這個時候的銀行核心系統大部分基於 Unix 系統和 C 語言開發，商業銀行網銀系統開始出現，嘗試使用 JAVA 語言、HTML、Javascript 開發應用。

2000 年代初期至中期，客戶機 / 應用伺服器 / 資料庫伺服器分離的三層架構時代。股份制銀行率先實現全行大集中核心項目，實現全行業務通存通兌；商業銀行的應用系統建設出現細分，業務報表、信貸管理、票據系統等紛紛從核心帳務系統職能剝離，形成專業化應用；BI、數據倉庫技術開始引入，CRM 系統、客戶呼叫中心系統、經營決策系統、財務管理系統等新系統開始建設，新建系統開始採用 J2EE 架構，JAVA 語言逐漸替代 C 語言成為應用開發的主流語言，也有部分應用採用微軟的.NET 技術。

2000 年代後期至 2010 年代初期，SOA 架構時代。銀行應對激烈的市場競爭，開始注重業務模式變革、管理模式變革。較領先的股份制銀行提出了流程再造、產品工廠等新概念和新需求，SOA 架構某種程度上順應了銀行流程再造的需求，也有利於商業銀行進行渠道和產品系統整合以及創新業務產品的快速推出。與此同時，移動互聯網逐漸興起，客戶交易主渠道逐漸轉向新推出的手機銀行系統；銀行開始重視客戶的服務體驗，重視風險管理體系建設，開始嘗試數據挖掘和機器學習技術提煉數據價值，提升客戶營銷與風險管理水平。

進入 2010 年代中期，商業銀行面臨利率市場化和國內金融市場對外開放的壓力，互聯網金融的興起也加劇了銀行客戶和資金的流失。面對新的挑戰，商業銀行在科技領域也在加大創新投入，虛心向互聯網企業學習，不斷擁抱新技術，體現如下：

引入雲計算技術構建企業私有雲，包括 OpenStack 和 Docker 容器技術，實現硬體資源的彈性管理。

嘗試運用微服務架構開發創新應用，包括在分散式核心系統、實時風險預警、實時營銷應用等新建系統，希望降低單體應用的運營風險，在雲環境更合理地給不同業務服務彈性分配硬體資源。

搭建大數據平台，開發創新的數據應用與服務。大數據技術逐漸流行，有效提升了企業的海量數據處理能力和業務建模能力，實時流處理技術提升了銀行的客戶感知能力和風險預警能力，加快了業務的反應速度。

人工智慧技術開始在銀行受到重視。基於大數據平台的機器學習技術逐漸流行，加速了客戶營銷與風險管理領域的業務建模速度；文本分析、認知計算、知識圖譜等技術提升了銀行對文本數據、社交網路數據的價值提煉和業務應用水平；規則推理引擎技術的應用，使得複雜業務場景的智能決策成為可能。

區塊鏈、VR 等新技術在商業銀行處於預研和孵化階段，在等待技術體系不斷成熟和實施成本下降的過程中，正在尋找合適的業務場景結合點。

嘉賓介紹：

曾光堯，恆豐銀行科技開發部資深軟體架構師，22 年銀行 IT 系統開發經歷。個人現階段關注的是高性能微服務架構設計、分散式並行處理技術、領域語言設計、大數據與人工智慧技術等。

8 月 10-11 日，聽雲聯合極客邦科技 /InfoQ 將共同主辦國內第二屆應用性能管理大會 -APMCon 2017，會議的演講內容聚焦行業內最新的技術和最接地氣的實踐案例，共同探討 APM 相關的性能優化、技術方案以及創新思路，為更多的行業從業者指點應用效能提升的迷津。

已確認嘉賓（部分）

恆豐銀行科技開發部資深架構師，曾光堯

微信客戶端開發團隊負責人，陳岳偉

阿里巴巴資料庫技術團隊技術專家，喬紅麟

百度高級前端工程師，李文倩

滴滴出行技術專家，戴銘

甲骨文中國技術產品事業部高級技術總監，李珈

支付寶性能測試專家，童庭堅

清華計算機系副教授、智能運維演算法專家，裴丹

泰康保險集團數據信息、中心運維自動化主管，王剛

奇虎 360 手機衛士技術經理，紀剛

獵豹安全大師國內技術負責人，梁炳輝

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！