中小型研發(fā)團隊架構實踐_第1頁
中小型研發(fā)團隊架構實踐_第2頁
中小型研發(fā)團隊架構實踐_第3頁
中小型研發(fā)團隊架構實踐_第4頁
中小型研發(fā)團隊架構實踐_第5頁
已閱讀5頁,還剩9頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、 中小型研發(fā)團隊架構實踐如果你正好處在中小型研發(fā)團隊中小型研發(fā)團隊很多,而社區(qū)在中小型研發(fā)團隊架構實踐方面的探討卻很少。中小型研發(fā)團隊特別是 50 至 200 人的研發(fā)團隊,在早期的業(yè)務探索階段,更多關注業(yè)務邏輯,快速迭代以驗證商業(yè)模式,很少去關注技術架構。這時如果繼續(xù)按照原有的架構及研發(fā)模式,會出現(xiàn)大量的問題,再也無法玩下去了。能不能有一套可直接落地、基于開源、成本低,可快速搭建的中間件及架構升級方案呢?我是一個有十多年經驗的 IT 老兵,曾主導了兩家公司的技術架構升級改造,現(xiàn)拋磚引玉,與大家一起探討這方面的問題。在接下來的一段時間里,我會陸續(xù)推出此系列文章。根據(jù)我們以往的經驗,分享者主講一

2、個小時左右,業(yè)務研發(fā)就可以快速地進入項目實戰(zhàn)。對于后面新加入的團隊成員,也可通過 WIKI 自主快速學習。這是我們之前對自己的要求,盡量降低工具對人員的要求,簡單實用、降低成本。文章中部分 Demo 采用 C# 語言, 但到了框架或架構層面,與語言本身沒有太多直接的關系。如 RabbitMQ、Job、Redis 和集中式日志,它們服務端的部署是一樣的,只是客戶端語言版本稍有不同。所有 Demo 都可直接運行,服務地址及管理后臺也可直接訪問。因為部署在公有云,牽涉到成本費用的問題,我計劃持續(xù)到明年 3 月底。這些小小的基礎工作,希望能夠幫到中小型研發(fā)團隊,解決大家項目中遇到的實際問題。愿與你一起

3、成長,你的分享和點贊是我此次付出的動力,謝謝!整個系列文章分為三個部分,包括 框架篇、架構篇 和 公共應用篇??蚣芷?即中間件或工具的使用,如緩存、消息隊列、集中式日志、度量、微服務框架等,工欲善其事,必先利其器。架構篇 主要是設計思想的提升,有企業(yè)總體架構、單個項目架構設計、統(tǒng)一應用分層等。公共應用篇 是業(yè)務與技術的結合,有單點登錄和企業(yè)支付網關。以下是篇章的具體介紹:框架篇工欲善其事,必先利其器 如果說運維是地基,那么框架就是承重墻。農村建住房是一塊磚一塊磚地往上壘,而城市建大 House 則是先打地基,再建承重墻,最后才是壘磚,所以中間件的搭建和引進是建設高可用、高性能、易擴展可伸縮的大

4、中型系統(tǒng)的前提??蚣芷械拿科饕伤牟糠纸M成:它是什么、工作原理、使用場景 和 可直接調試的 Demo。其中 Demo 及中間件歷經兩家公司四年時間的考驗,涉及幾百個應用,100 多個庫 1 萬多張表,日訂單從幾萬張到十幾萬,年 GMV 從幾十億到幾百億。所有中間件及工具都是基于開源,早期我們也有部分自主研發(fā)如集中式日志和度量框架。后期在第二家公司時為了快速地搭建,降低成本,易于維護和擴展,全部改為開源。這樣不僅利于個人的學習成長、知識重用和職業(yè)生涯,也利于團隊的組建和人才的引進。集中式緩存 Redis 緩存是計算機的難題之一,分布式緩存亦是如此。Redis 看起來非常簡單,但它影響著系統(tǒng)的

5、效率、性能、數(shù)據(jù)一致性。用好它不容易,涉及到的問題包括:緩存時長(復雜多維度的計算)、緩存失效處理(主動更新)、緩存鍵(Hash 和方便人工干預)、緩存內容及數(shù)據(jù)結構的選擇、緩存雪崩的處理、緩存穿透的處理等。Redis 除了緩存的功能,還有其它功能如 Lua 計算能力、Limit 與 Session 時間窗口、分布式鎖等。消息隊列 RabbitMQ 消息隊列好比葛洲壩,有大量數(shù)據(jù)的堆積能力,然后再可靠地進行異步輸出。它是 EDA 事件驅動架構的核心,也是 CQRS 同步數(shù)據(jù)的關鍵。為什么選擇 RabbitMQ 而沒有選擇 Kafka,因為業(yè)務系統(tǒng)有對消息的高可靠性要求,以及對復雜功能如消息確認

6、 Ack 的要求。集中式日志ELK日志主要分為系統(tǒng)日志和應用日志兩類。試想一下,你該如何在一個具有幾百臺服務器的集群中定位到問題?如何追蹤每天產生的幾 G 甚至幾 T 的數(shù)據(jù)?集中式日志就是此類問題的解決方案。早期我們使用自主研發(fā)的 Log4Net+MongoDB 來收集和檢索日志信息,但隨著數(shù)據(jù)量的增加,查詢速度卻變得越來越慢。后期改為開源的 ELK,雖然易用性有所下降,但它支持海量數(shù)據(jù)以及與編程語言無關的特征。下面是 ELK 的架構圖。任務調度 Job 任務調度 Job 如同數(shù)據(jù)庫作業(yè)或 Windows 計劃任務,是分布式系統(tǒng)中異步和批處理的關鍵。我們的 Job 分為 WinJob 和 H

7、ttpJob:WinJob 是操作系統(tǒng)級別的定時任務,使用開源的框架 Quartz.NET 實現(xiàn);而 HttpJob 則是自主研發(fā)實現(xiàn),采用 URL 方式可定時調用微服務。HttpJob 借助集群巧妙地解決了 WinJob 的單點和發(fā)布問題,并集中管理所有的調度規(guī)則,調度規(guī)則有簡單規(guī)則和 Cron 表達式。HttpJob 它簡單易用,但間隔時間不能低于 1 分鐘,畢竟通過 URL 方式來調度并不高效。下圖是 HttpJob 的管理后臺。應用監(jiān)控 Metrics “沒有度量就沒有提升”,度量是改進優(yōu)化的基礎,是做好一個系統(tǒng)的前置條件。Zabbix 一般用于系統(tǒng)級別的監(jiān)控,Metrics 則用于業(yè)

8、務應用級別的監(jiān)控。業(yè)務應用是個黑盒子,通過數(shù)據(jù)埋點來收集應用的實時狀態(tài),然后展示在大屏或看板上。它是報警系統(tǒng)和數(shù)字化管理的基礎,還可以結合集中式日志來快速定位和查找問題。我們的業(yè)務監(jiān)控系統(tǒng)使用 Metrics.NET+InfluxDB+Grafana。微服務框架 MSA 微服務是細粒度業(yè)務行為的重用,需要與業(yè)務能力及業(yè)務階段相匹配。微服務框架是實現(xiàn)微服務及分布式架構的關鍵組件,我們的微服務框架是基于開源 ServiceStack 來實現(xiàn)。它簡單易用、性能好,文檔自動生成、方便調試測試,調試工具 Swagger UI、自動化接口測試工具 SoapUI。微服務的接口開放采用我們自主研發(fā)的微服務網關

9、,通過治理后臺簡單的配置即可。網關以 NIO、IOCP 的方式實現(xiàn)高并發(fā),主要功能有鑒權、超時、限流、熔斷、監(jiān)控等,下圖是 Swagger UI 調試工具。搜索利器 Solr 分庫分表后的關聯(lián)查詢,大段文本的模糊查詢,這些要如何實現(xiàn)呢?顯然傳統(tǒng)的數(shù)據(jù)庫沒有很好的解決辦法,這時可以借助專業(yè)的檢索工具。全文檢索工具 Solr 不僅簡單易用性能好,而且支持海量數(shù)據(jù)高并發(fā),只需實現(xiàn)系統(tǒng)兩邊數(shù)據(jù)的準實時或定時同步即可。下圖是 Solr 的工作原理。更多工具 分布式協(xié)調器 ZooKeeperZK 工作原理、配置中心、Master 選舉、Demo,一篇足以。ORM 框架Dapper.NET 語法簡單、運行速

10、度快,與數(shù)據(jù)庫無關,SQL 自主編寫可控,是一款適合于互聯(lián)網系統(tǒng)的數(shù)據(jù)庫訪問工具。對象映射工具 EmitMapper 和 AutoMapperEmitMapper 性能較高,AutoMapper 易用性較好。IoC 框架控制反轉 IoC 輕量級框架 Autofac。DLL 包管理公司內部 DLL 包管理工具 NuGet,可解決 DLL 集中存儲、更新、引用、依賴問題。發(fā)布工具 Jenkins一鍵編譯、發(fā)布、自動化測試、一鍵回滾,高效便捷故障低。架構篇思想提升 會使用以上框架并不一定能成為優(yōu)秀的架構師,但一位優(yōu)秀架構師一定會使用框架。架構師除了會使用工具外,還需要設計思想的提升和性能調優(yōu)技能。此

11、篇以真實項目為背景,思想方法追求簡單有效,主要內容包括 企業(yè)總體架構、單個項目架構設計、統(tǒng)一應用分層、調試工具 WinDbg。企業(yè)總體架構 當我們有了幾百個上千個應用后,不僅僅需要單個項目的架構設計,還需要企業(yè)總體架構做頂層思考和指導。大公司與小商販的商業(yè)思維是一樣的,但大公司比較難看到商業(yè)全貌和本質。而小公司又缺乏客戶流量和中間件的應用場景,中型公司則兼而有之,所以企業(yè)總體架構也相對好落地。企業(yè)總體架構需要在 技術、業(yè)務、管理 之間游刃有余地切換,它包括業(yè)務架構、應用架構、數(shù)據(jù)架構和技術架構。附檔是一份脫敏感信息后的真實案例,有參考 TOGAF 標準。但內容以解決公司系統(tǒng)的架構問題為導向、以

12、時間為主線,包括企業(yè)商務模型、架構現(xiàn)狀、架構規(guī)劃和架構實施。單個項目架構設計 單個項目的架構設計如同施工圖紙,能直接指導工程代碼的實施。上一環(huán)是功能需求,下一環(huán)是代碼實施,這是架構設計的價值所在。從功能需求到用例,到用例活動圖,到領域圖、架構分層,到核心代碼,它們之間環(huán)環(huán)相扣。做不好領域圖可能源自沒有做好用例活動圖,因為用例活動圖是領域圖的上一環(huán)。關注職責、邊界、應用關系、存儲、部署是架構設計的核心,下圖是具體案例參考。統(tǒng)一應用分層 給應用分層這件事情很簡單,但是讓一家公司的幾百個應用采用統(tǒng)一的分層結構,這可不是件簡單的事情。它要做到可大可小、簡單易用、支持多種場景,我們使用 IPO 方式:I

13、 表示 Input、O 表示 Output、P 表示 Process,一進一出一處理。應用系統(tǒng)的本質就是機器,是處理設備,也是一進一出一處理,IPO 方式相對于 DDD 而言更為簡單實用。調試工具 WinDbg 生產環(huán)境偶爾會出現(xiàn)一些異常問題,而 WinDbg 或 GDB 就是解決此類問題的利器。調試工具 WinDbg 如同醫(yī)生的聽診器,是系統(tǒng)生病時做問題診斷的逆向分析工具,Dump 文件類似于飛機的黑匣子,記錄著生產環(huán)境程序運行的狀態(tài)。主要介紹調試工具 WinDbg 和抓包工具 ProcDump 的使用,并分享一個真實的案例。N 年前不知誰寫的代碼,導致每一兩個月偶爾出現(xiàn) CPU 飆高的現(xiàn)象

14、。我們先使用 ProcDump 在生產環(huán)境中抓取異常進程的 Dump 文件,然后在不了解代碼的情況下通過 WinDbg 命令進行分析,最終定位到有問題的那行代碼。公共應用篇 先工具再框架,然后架構設計,最后深入公共應用。公共應用因為與業(yè)務系統(tǒng)結合緊密,但又具有一定的獨立性,所以一般自主開發(fā),不使用開源也不方便開源。公共應用主要包括單點登錄、企業(yè)支付網關、CTI 通訊網關(短信郵件微信),此次分享單點登錄和企業(yè)支付網關。單點登錄 應用拆分后總要合在一起,拆分是應用實施層面的拆分,合成是用戶層面的合成,而合成必須解決認證和導航問題。單點登錄 SSO 即只需要登錄一次,便可到處訪問,它是建立在用戶系統(tǒng)、權限系統(tǒng)、認證系統(tǒng)和企業(yè)門戶的基礎上。我們的憑證數(shù)據(jù) Token 使用 JWT 標準,

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論