騰訊組織架構整改引思考：中小團隊要怎樣搭建架構？
編者有言：2019年1月4日，騰訊宣佈成立技術委員會，也代表之前宣佈的架構調整終於拉開序幕。在這個瞬息萬變的時代，一個合適的團隊架構對於企業發展至關重要。面對時代風向，騰訊等網際網路巨頭逐步開始了它們的變革；那麼中小團隊要如何搭建自己的團隊架構呢？本文將會對此展開討論……
作者介紹
張輝淸，曾任中青易遊CTO、同程交通創新技術負責人、古大集團首席架構師、攜程架構師等職務。帶領過30～200人的技術團隊，將其研發能力提高1～2個檔次。現階段主要關注技術創新、技術創業、中小研發團隊的能力提升。
平時我們看技術大會上的分享大多高大上，億級流量、超大型研發團隊，雖然值得借鑑，但由於應用場景與研發資源的差異，一般企業並不容易落地。其實，中小型研發團隊在IT行業還是佔大多數，他們在技術架構方面的問題較多，技術阻礙業務、跟不上業務發展的情況非常常見。
我是一個有十多年經驗的 IT 老兵，曾在兩家幾千人的技術團隊做過架構與技術管理工作，也曾在幾十人至幾百人的中小研發團隊做過首席架構師和CTO。一個是定製的勞斯萊斯，一個是大眾轎車。在網際網路大廠做技術研發，大多隻是一個螺絲釘。而在中小研發團隊，則比較容易掌控全域性。
筆者結合近幾年的工作經驗，摸索出了一套可直接落地、基於開源、成本低、可快速搭建的框架及架構方案。小團隊也能構建大網站，中小研發團隊架構實踐更貼近於一般程式設計師的實際情況，更具應用參考價值。
一、框架篇：工欲善其事，必先利其器
如果說運維是地基，那麼框架就是承重牆。農村建住房是一塊磚一塊磚地往上壘，而城市建大House則是先打地基，再建承重牆，最後才是壘磚，所以中介軟體的搭建和引進是建設高可用、高效能、易擴充套件可伸縮的大中型系統的前提。
框架篇中的每章主要由四部分組成：它是什麼、工作原理、使用場景和可直接除錯的Demo。其中中介軟體及Demo是歷經兩家公司四年時間的考驗，涉及幾百個應用，100多個庫1萬多張表，日訂單從幾萬張到十幾萬，年GMV從幾十億到幾百億。
所有中介軟體與工具都是基於開源。早期我們也有部分自主研發如集中式日誌和度量框架，後期在第二家公司時為了快速地搭建、降低成本、易於維護和擴充套件，全部改為開源。這樣不僅利於個人的學習成長、知識重用和職業生涯，也利於團隊的組建和人才的引進。
1、集中式快取Redis
快取是計算機的難題之一，分散式快取亦是如此。Redis看起來非常簡單，但它影響著系統的效率、效能、資料一致性。
用好它不容易，具體包括：快取時長（複雜多維度的計算）、快取失效處理（主動更新）、快取鍵（Hash和方便人工干預）、快取內容及資料結構的選擇、快取雪崩的處理、快取穿透的處理等。Redis除了快取的功能，還有其它功能如Lua計算能力、Limit與Session時間視窗、分散式鎖等。我們使用ServiceStack.Redis做客戶端，使用方法詳見Demo。
2、訊息佇列RabbitMQ
訊息佇列好比葛洲壩，有大量資料的堆積能力，然後再可靠地進行非同步輸出。它是EDA事件驅動架構的核心，也是CQRS同步資料的關鍵。為什麼選擇RabbitMQ而沒有選擇Kafka，因為業務系統有對訊息的高可靠性要求，以及對複雜功能如訊息確認Ack的要求。
3、集中式日誌ELK
日誌主要分為系統日誌和應用日誌兩類。
試想一下，你該如何在一個具有幾百臺伺服器的叢集中定位到問題？如何追蹤每天產生的幾G甚至幾T的資料？集中式日誌就是此類問題的解決方案。
早期我們使用自主研發的Log4Net+MongoDB來收集和檢索日誌資訊，但隨著資料量的增加，查詢速度卻變得越來越慢。後期改為開源的ELK，雖然易用性有所下降，但它支援海量資料以及與程式語言無關的特徵。下圖是ELK的架構圖：
4、任務排程Job
任務排程Job如同資料庫作業或Windows計劃任務，是分散式系統中非同步和批處理的關鍵。我們的Job分為WinJob和HttpJob：
- WinJob是作業系統級別的定時任務，使用開源的框架Quartz.NET實現；
- 而HttpJob則是自主研發實現，採用URL方式可定時呼叫微服務。
HttpJob藉助叢集巧妙地解決了WinJob的單點和釋出問題，並集中管理所有的排程規則，排程規則有簡單規則和Cron表示式。HttpJob它簡單易用，但間隔時間不能低於1分鐘，畢竟通過URL方式來排程並不高效。
下圖是HttpJob的管理後臺：
5、度量工具Metrics
“沒有度量就沒有提升”，度量是改進優化的基礎，是做好一個系統的前置條件。
Zabbix一般用於系統級別的監控，Metrics則用於業務應用級別的監控。業務應用是個黑盒子，通過資料埋點來收集應用的實時狀態，然後展示在大屏或看板上。它是報警系統和數字化管理的基礎，還可以結合集中式日誌來快速定位和查詢問題。我們的業務監控系統使用Metrics.NET+InfluxDB+Grafana。
6、微服務MSA
微服務是細粒度業務行為的重用，需要與業務能力及業務階段相匹配。
微服務框架是實現微服務及分散式架構的關鍵元件，我們的微服務框架是基於開源ServiceStack來實現。它簡單易用、效能好，文件自動生成、方便除錯測試，除錯工具Swagger UI、自動化介面測試工具SoapUI。
微服務的介面開放採用我們自主研發的微服務閘道器，通過治理後臺簡單的配置即可。閘道器以NIO、IOCP的方式實現高併發，主要功能有鑑權、超時、限流、熔斷、監控等，下圖是Swagger UI除錯工具：
7、搜尋引擎Solr
分庫分表後的關聯查詢，大段文字的模糊查詢，這些要如何實現呢？
顯然傳統的資料庫沒有很好的解決辦法，這時可以藉助專業的檢索工具。全文檢索工具Solr不僅簡單易用效能好，而且支援海量資料高併發，只需實現系統兩邊資料的準實時或定時同步即可。下圖是Solr的工作原理：
8、更多工具
分散式協調器ZooKeeper：ZK工作原理、配置中心、Master選舉、Demo，一篇足以；
ORM框架：Dapper.NET語法簡單、執行速度快，與資料庫無關，SQL自主編寫可控，是一款適合於網際網路系統的資料庫訪問工具；
物件對映工具EmitMapper和AutoMapper：EmitMapper效能較高，AutoMapper易用性較好；
IoC框架：控制反轉IoC輕量級框架Autofac；
DLL包管理：公司內部DLL包管理工具NuGet，可解決DLL集中儲存、更新、引用、依賴問題；
釋出工具Jenkins：一鍵編譯、釋出、自動化測試、一鍵回滾，高效便捷故障低。
二、架構篇：思想提升
會使用以上框架並不一定能成為優秀的架構師，但一位優秀架構師一定會使用框架。架構師除了會使用工具外，還需要架構設計思想和效能調優技能。此部分以真實專案為背景，思想方法追求簡單有效，內容包括企業總體架構、單個專案架構設計、統一應用分層、除錯工具WinDbg。
1、企業總體架構
當我們有了幾百個上千個應用後，不僅僅需要單個專案的架構設計，還需要企業總體架構做頂層思考和指導。
大公司與小商販的商業思維是一樣的，但大公司比較難看到商業全貌和本質。而小公司又缺乏客戶流量和中介軟體的應用場景，中型公司則兼而有之，所以企業總體架構也相對好落地。
企業總體架構需要在技術、業務、管理之間遊刃有餘地切換，它包括業務架構、應用架構、資料架構和技術架構。
附檔是一份脫敏感資訊後的真實案例，有參考TOGAF標準，但內容以解決公司系統的架構問題為導向、以時間為主線，包括企業商務模型、架構現狀、架構規劃和架構實施。
2、單個專案架構設計
應用架構設計如同施工圖紙，能直接指導工程程式碼的實施。
上一環是功能需求，下一環是程式碼實施，這是架構設計的價值所在。從功能需求到用例，到用例活動圖，到領域圖、架構分層，到核心程式碼，它們之間環環相扣。做不好領域圖可能源自沒有做好用例活動圖，因為用例活動圖是領域圖的上一環。關注職責、邊界、應用關係、儲存、部署是架構設計的核心，下圖是具體案例參考：
3、統一應用分層
給應用分層這件事情很簡單，但是讓一家公司的幾百個應用採用統一的分層結構，這可不是件簡單的事情。它要做到可大可小、簡單易用、支援多種場景，我們使用IPO方式：I表示Input、O表示Output、P表示Process，一進一出一處理。
應用系統的本質就是機器，是處理裝置，也是一進一出一處理，IPO方式相對於DDD而言更為簡單實用。
4、診斷工具WinDbg
生產環境偶爾會出現一些異常問題，而WinDbg或GDB就是解決此類問題的利器。除錯工具WinDbg如同醫生的聽診器，是系統生病時做問題診斷的逆向分析工具，Dump檔案類似於飛機的黑匣子，記錄著生產環境程式執行的狀態。
本文主要介紹了除錯工具WinDbg和抓包工具ProcDump的使用，並分享一個真實的案例。
N年前不知誰寫的程式碼，導致每一兩個月偶爾出現CPU飆高的現象。我們先使用ProcDump在生產環境中抓取異常程序的Dump檔案，然後在不瞭解程式碼的情況下通過WinDbg命令進行分析，最終定位到有問題的那行程式碼。
三、公共應用篇：業務與技術的結合
先工具再框架，然後架構設計，最後深入公共應用。
公共應用因為與業務系統結合緊密，但又具有一定的獨立性，所以一般自主開發，不使用開源也不方便開源。公共應用主要包括單點登入、企業支付閘道器、CTI通訊閘道器（簡訊郵件微信），下面介紹單點登入和企業支付閘道器。
1、單點登入
應用拆分後總要合在一起，拆分是應用實施層面的拆分，合成是使用者層面的合成，而合成必須解決認證和導航問題。單點登入SSO即只需要登入一次，便可到處訪問，它是建立在使用者系統、許可權系統、認證系統和企業門戶的基礎上。
我們的憑證資料Token使用JWT標準，以解決不同語言、不同客戶端、跨WebAPI的安全問題。
2、企業支付閘道器
企業支付閘道器集中和封裝了公司的各大支付，例如支付寶、財付通、微信、預付款等。它統一了業務系統呼叫各支付介面的方式，簡化了業務系統與支付系統的互動。它將各種支付介面統一為支付、代扣、分潤、退款、退分潤、補差、轉賬、凍結、解凍、預付款等，呼叫時只需選擇支付型別即可。
企業支付閘道器將各大支付系統進行集中地設計、研發、部署、監控、維護，提供統一的加解密、序列化、日誌記錄和安全隔離。
四、進階篇：從架構到管理
架構要落地、固化和提升，需要通過技術架構與組織架構的對齊來達成。從生產力到生產關係，從架構師到技術管理，你關注的角度也將發生變化。從關注技術到關注技術的商業價值、技術與業務的匹配與融合、技術團隊的文化等等。
本部分內容包括技改之路、技術與業務的匹配與融合、研發團隊文化是怎麼長出來的，重點會介紹以下3個。
1、技改之路：從單塊應用到微服務
技改是技術改造的簡稱，是技術的蛻變。這裡指的是在公司技術發展的某個瓶頸階段，按原有開發和組織方式已經無法玩下去，這時公司希望引進架構師或技術牛人，來破解當前困局。
技改之路少講技術多講路，我們不過多地關注技術細節和中介軟體的實現，而重點講述技術改造的過程和思考。技改是大折騰，於公司於個人而言都是。小改怡情、大改傷身，所以真正高手下棋，應該是通盤無妙招，讓正確的事情很容易發生，基於自然的演化來實現技術的演進。
2、技術與業務的匹配與融合
是什麼在驅動公司的發展？
技術說“科學技術是第一生產力”，市場說“沒有市場，哪來的業務”，運營說他自己。應該說他們都是正確的，但又不全面。這如同盲人摸象一樣，引發了不少的爭論，也直接或間接地導致了技術與業務的矛盾。
本文先丟擲了一個啟發性的問題，然後分析問題出在哪裡，理解源於彼此的瞭解，如何去匹配與融合，最後正面回答了該問題。只有尊重事物的發展規律，加強技術與業務的之間合作，才能促進公司發展。
3、研發團隊文化是怎麼長出來的
從死氣沉沉到激情活力，從固步自封到好學分享，這是一個有關團隊文化的主題。寺廟文化傳承千百年，舌尖上的美食流傳至今，它是如何形成和生長的？是參考大公司或從管理書籍上挑選幾個詞語，還是腳踏實地、土裡吧唧，自己一步一步埋頭幹？
我們要先弄清遇到的問題，然後是找到解決之道，包括管理工具、制度和行為措施，並予以貫徹並形成一種習慣，最後是總結並歸納成幾個可以貼到牆上的大字，即「共治分享自視一起拼，簡單有效快」，這個過程就如同花朵一般。只有這樣「長」出來的文化，才能管人做事，才能成為公司或團隊的執行力。
以上目錄順序不僅是架構改造的參考路徑，也是架構師的成長路徑。照著做，你也能夠成為架構師。本文後續還會涉及框架中的其他部分，對內容進行更詳細的延展分析。
我們希望能夠儘量降低工具對研發人員的門檻，實現簡單實用、降低成本。文章中部分Demo採用C#或Java語言，但到了框架與架構層面，與語言本身沒有太多關係。
如RabbitMQ、Job、Redis和集中式日誌ELK，它們服務端的部署都是一樣的，只是客戶端語言版本稍有不同。所有Demo在一段時間內都可直接執行，服務地址和管理後臺亦可直接訪問。
以上這些基礎工作，希望能夠幫助到中小型研發團隊，解決大家專案中遇到的實際問題，也願與你一起在架構方面有所成長，謝謝！
案例參考和Demo下載
下載地址：