歡迎光臨
每天分享高質量文章

十年 IT 老兵帶你通過案例學架構,附C#代碼

技術大會上的分享大多高大上,億級流量、超大型研發團隊,雖然值得借鑒,但由於應用場景與研發資源的差異,一般企業並不容易落地。其實,中小型研發團隊在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、企業支付網關

企業支付網關集中和封裝了公司的各大支付,例如支付寶、財付通、微信、預付款等。它統一了業務系統呼叫各支付接口的方式,簡化了業務系統與支付系統的交互。它將各種支付接口統一為支付、代扣、分潤、退款、退分潤、補差、轉賬、凍結、解凍、預付款等,呼叫時只需選擇支付型別即可。

企業支付網關將各大支付系統進行集中地設計、研發、部署、監控、維護,提供統一的加解密、序列化、日誌記錄和安全隔離。

進階篇——從架構到管理

架構要落地、固化和提升,需要通過技術架構與組織架構的對齊來達成。從生產力到生產關係,從架構師到技術管理,你關註的角度也將發生變化。從關註技術到關註技術的商業價值、技術與業務的匹配與融合、技術團隊的文化等等。

本篇內容包括技改之路、技術與業務的匹配與融合、研發團隊文化是怎麼長出來的。

1、技改之路:從單塊應用到微服務

技改是技術改造的簡稱,是技術的蛻變。

本章指的是在公司技術發展的某個瓶頸階段,按原有開發和組織方式已經無法玩下去,這時公司希望引進架構師或技術牛人,來破解當前困局。

技改之路少講技術多講路,我們不過多地關註技術細節和中間件的實現,而重點講述技術改造的過程和思考。技改是大折騰,於公司於個人而言都是。

小改怡情、大改傷身,所以真正高手下棋,應該是通盤無妙招,讓正確的事情很容易發生,基於自然的演化來實現技術的演進。

2、技術與業務的匹配與融合

是什麼在驅動公司的發展?技術說“科學技術是第一生產力”,市場說“沒有市場,哪來的業務”,運營說他自己。應該說他們都是正確的,但又不全面。這如同盲人摸象一樣,引發了不少的爭論,也直接或間接地導致了技術與業務的矛盾。

本文先丟擲了一個啟發性的問題,然後分析問題出在哪裡,理解源於彼此的瞭解,如何去匹配與融合,最後正面回答了該問題。

只有尊重事物的發展規律,加強技術與業務的之間合作,才能促進公司發展。

3、研發團隊文化是怎麼長出來的

從死氣沉沉到激情活力,從固步自封到好學分享,這是一個有關團隊文化的主題。寺廟文化傳承千百年,舌尖上的美食流傳至今,它是如何形成和生長的?是參考大公司或從管理書籍上挑選幾個詞語,還是腳踏實地、土裡吧唧,自己一步一步埋頭乾?

本章先介紹了我們遇到的問題,然後是解決之道,包括管理工具、制度和行為措施,並予以貫徹並形成一種習慣,最後是總結並歸納成幾個可以貼到牆上的大字,即「共治分享自視一起拼,簡單有效快」,這個過程就如同花朵一般。只有這樣「長」出來的文化,才能管人做事,才能成為公司或團隊的執行力。

總結

以上目錄順序不僅是架構改造的參考路徑,也是架構師的成長路徑。照著做,你也能夠成為架構師。但為了本書的閱讀效果,篇章目錄並沒有採用以上順序,而是先介紹架構,然後是框架、公共應用和進階篇,敬請註意。

根據我們以往的經驗,通過以上的分享,業務研發就可以快速地進入專案實戰。對於後面新加入的團隊成員,也可通過Wiki自主快速學習。這是我們之前對自己的要求,儘量降低工具對研發人員的門檻,簡單實用、降低成本。文章中部分Demo採用C#或Java語言,但到了框架與架構層面,與語言本身沒有太多關係。如RabbitMQ、Job、Redis和集中式日誌ELK,它們服務端的部署都是一樣的,只是客戶端語言版本稍有不同。

所有Demo在一段時間內都可直接運行,服務地址和管理後臺亦可直接訪問(所有案例和Demo下載地址:https://github.com/das2017?tab=repositories)。以上這些基礎工作,希望能夠幫助到中小型研發團隊,解決大家專案中遇到的實際問題,也願與你一起在架構方面有所成長,謝謝! 

作者簡介:張輝清,10多年的IT老兵,系統分析師、專案管理師,曾任中青易游CTO、同程交通創新技術負責人、古大集團首席架構師、攜程架構師等職務。帶領過30~200人的技術團隊,將其研發能力提高1~2個檔次。現階段主要關註技術創新、技術創業、中小研發團隊的能力提升。

六、新書上市



小團隊構建大網站:中小研發團隊架構實踐結合作者十幾年的工作經驗,總結了一套可直接落地、基於開源、成本低、可快速搭建的中小研發團隊架構實踐方法。本書共5篇22章,開篇是本書的導讀;架構篇是設計思想的提升,包括企業總體架構、應用架構設計、統一應用分層等;框架篇主講中間件和工具的使用,包括訊息佇列、快取、Job、集中式日誌、應用監控和微服務等;公共應用篇是技術與業務的結合,包括單點登錄和企業支付網關;進階篇是從架構到管理,包括技改案例、技術與業務的匹配與融合等。從架構、框架、公共應用,到案例實戰和技術管理,本書將大公司的工程理念壓縮應用到中小研發團隊,使小團隊也能構建大網站。

  • 專家推薦:

赞(0)

分享創造快樂