中小型研發團隊不少,而社區在中小型研發團隊架構實踐方面的探討卻不多。中小型研發團隊特別是 50 至 200 人的研發團隊,在早期的業務探索階段,更多關注業務邏輯,快速迭代以驗證商業模式,不多去關注技術架構。這時若是繼續按照原有的架構及研發模式,會出現大量的問題,再也沒法玩下去了。能不能有一套可直接落地、基於開源、成本低,可快速搭建的中間件及架構升級方案呢?我是一個有十多年經驗的 IT 老兵,曾主導了兩家公司的技術架構升級改造,現拋磚引玉,與你們一塊兒探討這方面的問題。在接下來的一段時間裏,我會陸續推出此係列文章。根據咱們以往的經驗,分享者主講一個小時左右,業務研發就能夠快速地進入項目實戰。對於後面新加入的團隊成員,也可經過 WIKI 自主快速學習。這是咱們以前對本身的要求,儘可能下降工具對人員的要求,簡單實用、下降成本。文章中部分 Demo 採用 C# 語言, 但到了框架或架構層面,與語言自己沒有太多直接的關係。如 RabbitMQ、Job、Redis 和集中式日誌,它們服務端的部署是同樣的,只是客戶端語言版本稍有不一樣。全部 Demo 均可直接運行,服務地址及管理後臺也可直接訪問。由於部署在公有云,牽涉到成本費用的問題,我計劃持續到明年 3 月底。這些小小的基礎工做,但願可以幫到中小型研發團隊,解決你們項目中遇到的實際問題。願與你一塊兒成長,你的分享和點贊是我這次付出的動力,謝謝!git
整個系列文章分爲三個部分,包括 框架篇、架構篇 和公共應用篇。github
框架篇 即中間件或工具的使用,如緩存、消息隊列、集中式日誌、度量、微服務框架等,工欲善其事,必先利其器。redis
架構篇 主要是設計思想的提高,有企業整體架構、單個項目架構設計、統一應用分層等。數據庫
公共應用篇 是業務與技術的結合,有單點登陸和企業支付網關。編程
如下是篇章的具體介紹:緩存
框架篇——工欲善其事,必先利其器安全
若是說運維是地基,那麼框架就是承重牆。農村建住房是一塊磚一塊磚地往上壘,而城市建大 House 則是先打地基,再建承重牆,最後纔是壘磚,因此中間件的搭建和引進是建設高可用、高性能、易擴展可伸縮的大中型系統的前提。框架篇中的每篇主要由四部分組成:它是什麼、工做原理、使用場景 和 可直接調試的 Demo。其中 Demo 及中間件歷經兩家公司四年時間的考驗,涉及幾百個應用,100 多個庫 1 萬多張表,日訂單從幾萬張到十幾萬,年 GMV 從幾十億到幾百億。全部中間件及工具都是基於開源,早期咱們也有部分自主研發如集中式日誌和度量框架。後期在第二家公司時爲了快速地搭建,下降成本,易於維護和擴展,所有改成開源。這樣不只利於我的的學習成長、知識重用和職業生涯,也利於團隊的組建和人才的引進。服務器
集中式緩存 Redis微信
緩存是計算機的難題之一,分佈式緩存亦是如此。Redis 看起來很是簡單,但它影響着系統的效率、性能、數據一致性。用好它不容易,涉及到的問題包括:緩存時長(複雜多維度的計算)、緩存失效處理(主動更新)、緩存鍵(Hash 和方便人工干預)、緩存內容及數據結構的選擇、緩存雪崩的處理、緩存穿透的處理等。Redis 除了緩存的功能,還有其它功能如 Lua 計算能力、Limit 與 Session 時間窗口、分佈式鎖等。數據結構
消息隊列 RabbitMQ
消息隊列比如葛洲壩,有大量數據的堆積能力,而後再可靠地進行異步輸出。它是 EDA 事件驅動架構的核心,也是 CQRS 同步數據的關鍵。爲何選擇 RabbitMQ 而沒有選擇 Kafka,由於業務系統有對消息的高可靠性要求,以及對複雜功能如消息確認 Ack 的要求。
集中式日誌ELK
日誌主要分爲系統日誌和應用日誌兩類。試想一下,你該如何在一個具備幾百臺服務器的集羣中定位到問題?如何追蹤天天產生的幾 G 甚至幾 T 的數據?集中式日誌就是此類問題的解決方案。早期咱們使用自主研發的Log4Net+MongoDB 來收集和檢索日誌信息,但隨着數據量的增長,查詢速度卻變得愈來愈慢。後期改成開源的 ELK,雖然易用性有所降低,但它支持海量數據以及與編程語言無關的特徵。下面是 ELK 的架構圖。
任務調度 Job
任務調度 Job 如同數據庫做業或 Windows 計劃任務,是分佈式系統中異步和批處理的關鍵。咱們的 Job 分爲 WinJob 和 HttpJob:WinJob 是操做系統級別的定時任務,使用開源的框架 Quartz.NET 實現;而 HttpJob 則是自主研發實現,採用 URL 方式可定時調用微服務。HttpJob 藉助集羣巧妙地解決了 WinJob 的單點和發佈問題,並集中管理全部的調度規則,調度規則有簡單規則和 Cron 表達式。HttpJob 它簡單易用,但間隔時間不能低於 1 分鐘,畢竟經過 URL 方式來調度並不高效。下圖是 HttpJob 的管理後臺。
應用監控 Metrics
「沒有度量就沒有提高」,度量是改進優化的基礎,是作好一個系統的前置條件。Zabbix 通常用於系統級別的監控,Metrics 則用於業務應用級別的監控。業務應用是個黑盒子,經過數據埋點來收集應用的實時狀態,而後展現在大屏或看板上。它是報警系統和數字化管理的基礎,還能夠結合集中式日誌來快速定位和查找問題。咱們的業務監控系統使用Metrics.NET+InfluxDB+Grafana。
微服務框架 MSA
微服務是細粒度業務行爲的重用,須要與業務能力及業務階段相匹配。微服務框架是實現微服務及分佈式架構的關鍵組件,咱們的微服務框架是基於開源 ServiceStack 來實現。它簡單易用、性能好,文檔自動生成、方便調試測試,調試工具 Swagger UI、自動化接口測試工具 SoapUI。微服務的接口開放採用咱們自主研發的微服務網關,經過治理後臺簡單的配置便可。網關以 NIO、IOCP 的方式實現高併發,主要功能有鑑權、超時、限流、熔斷、監控等,下圖是 Swagger UI 調試工具。
搜索利器 Solr
分庫分表後的關聯查詢,大段文本的模糊查詢,這些要如何實現呢?顯然傳統的數據庫沒有很好的解決辦法,這時能夠藉助專業的檢索工具。全文檢索工具 Solr 不只簡單易用性能好,並且支持海量數據高併發,只需實現系統兩邊數據的準實時或定時同步便可。下圖是 Solr 的工做原理。
更多工具
分佈式協調器 ZooKeeper
ZK 工做原理、配置中心、Master 選舉、Demo,一篇足以。
ORM 框架
Dapper.NET 語法簡單、運行速度快,與數據庫無關,SQL 自主編寫可控,是一款適合於互聯網系統的數據庫訪問工具。
對象映射工具 EmitMapper 和 AutoMapper
EmitMapper 性能較高,AutoMapper 易用性較好。
IoC 框架
控制反轉 IoC 輕量級框架 Autofac。
DLL 包管理
公司內部 DLL 包管理工具 NuGet,可解決 DLL 集中存儲、更新、引用、依賴問題。
發佈工具 Jenkins
一鍵編譯、發佈、自動化測試、一鍵回滾,高效便捷故障低。
架構篇——思想提高
會使用以上框架並不必定能成爲優秀的架構師,但一位優秀架構師必定會使用框架。架構師除了會使用工具外,還須要設計思想的提高和性能調優技能。此篇以真實項目爲背景,思想方法追求簡單有效,主要內容包括企業整體架構、單個項目架構設計、統一應用分層、調試工具 WinDbg。
企業整體架構
當咱們有了幾百個上千個應用後,不只僅須要單個項目的架構設計,還須要企業整體架構作頂層思考和指導。大公司與小商販的商業思惟是同樣的,但大公司比較難看到商業全貌和本質。而小公司又缺少客戶流量和中間件的應用場景,中型公司則兼而有之,因此企業整體架構也相對好落地。企業整體架構須要在技術、業務、管理 之間遊刃有餘地切換,它包括業務架構、應用架構、數據架構和技術架構。附檔是一份脫敏感信息後的真實案例,有參考 TOGAF 標準。但內容以解決公司系統的架構問題爲導向、以時間爲主線,包括企業商務模型、架構現狀、架構規劃和架構實施。
單個項目架構設計
單個項目的架構設計如同施工圖紙,能直接指導工程代碼的實施。上一環是功能需求,下一環是代碼實施,這是架構設計的價值所在。從功能需求到用例,到用例活動圖,到領域圖、架構分層,到核心代碼,它們之間環環相扣。作很差領域圖可能源自沒有作好用例活動圖,由於用例活動圖是領域圖的上一環。關注職責、邊界、應用關係、存儲、部署是架構設計的核心,下圖是具體案例參考。
統一應用分層
給應用分層這件事情很簡單,可是讓一家公司的幾百個應用採用統一的分層結構,這可不是件簡單的事情。它要作到可大可小、簡單易用、支持多種場景,咱們使用 IPO 方式:I 表示 Input、O 表示 Output、P 表示 Process,一進一出一處理。應用系統的本質就是機器,是處理設備,也是一進一出一處理,IPO 方式相對於 DDD 而言更爲簡單實用。
調試工具 WinDbg
環境偶爾會出現一些異常問題,而 WinDbg 或 GDB 就是解決此類問題的利器。調試工具 WinDbg 如同醫生的聽診器,是系統生病時作問題診斷的逆向分析工具,Dump 文件相似於飛機的黑匣子,記錄着生產環境程序運行的狀態。主要介紹調試工具 WinDbg 和抓包工具 ProcDump 的使用,並分享一個真實的案例。N 年前不知誰寫的代碼,致使每一兩個月偶爾出現 CPU 飆高的現象。咱們先使用 ProcDump 在生產環境中抓取異常進程的 Dump 文件,而後在不瞭解代碼的狀況下經過 WinDbg 命令進行分析,最終定位到有問題的那行代碼。
公共應用篇
先工具再框架,而後架構設計,最後深刻公共應用。公共應用由於與業務系統結合緊密,但又具備必定的獨立性,因此通常自主開發,不使用開源也不方便開源。公共應用主要包括單點登陸、企業支付網關、CTI 通信網關(短信郵件微信),這次分享單點登陸和企業支付網關。
單點登陸
應用拆分後總要合在一塊兒,拆分是應用實施層面的拆分,合成是用戶層面的合成,而合成必須解決認證和導航問題。單點登陸 SSO 即只須要登陸一次,即可處處訪問,它是創建在用戶系統、權限系統、認證系統和企業門戶的基礎上。咱們的憑證數據 Token 使用 JWT 標準,以解決不一樣語言、不一樣客戶端、跨 WebAPI 的安全問題。
企業支付網關
企業支付網關集中和封裝了公司的各大支付,例如支付寶、財付通、微信、預付款等。它統一了業務系統調用各支付接口的方式,簡化了業務系統與支付系統的交互。它將各類支付接口統一爲支付、代扣、分潤、退款、退分潤、補差、轉帳、凍結、解凍、預付款等,調用時只需選擇支付類型便可。企業支付網關將各大支付系統進行集中的設計、研發、部署、監控、維護,提供統一的加解密、序列化、日誌記錄,安全隔離。
本系列文章涉及內容清單以下(並不按這順序發佈),其中有感興趣的,歡迎關注:
開篇
緩存 Redis
消息隊列 RabbitMQ
集中式日誌 ELK
任務調度 Job
應用監控 Metrics
微服務框架 MSA
搜索利器 Solr
分佈式協調器 ZooKeeper
小工具:Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
發佈工具 Jenkins
整體架構設計
單個項目架構設計
統一應用分層
調試工具 WinDbg
單點登陸
企業支付網關
結篇
LayerDemo 下載地址:https://github.com/das2017/LayerDemo
本系列文章涉及內容清單以下(並不按這順序發佈),其中有感興趣的,歡迎關注: