此篇分享分為三個部分，包括 框架篇 、 架構(gòu)篇 和 公共應用篇 。

框架篇 即中間件或工具的使用，如緩存、消息隊列、集中式日志、度量、微服務框架等，工欲善其事，必先利其器。

架構(gòu)篇 主要是設(shè)計思想的提升，有企業(yè)總體架構(gòu)、單個項目架構(gòu)設(shè)計、統(tǒng)一應用分層等。

公共應用篇 是業(yè)務與技術(shù)的結(jié)合，有單點登錄和企業(yè)支付網(wǎng)關(guān)。

框架篇——工欲善其事，必先利其器

如果說運維是地基，那么框架就是承重墻。農(nóng)村建住房是一塊磚一塊磚地往上壘，而城市建大 House 則是先打地基，再建承重墻，最后才是壘磚，所以中間件的搭建和引進是建設(shè)高可用、高性能、易擴展可伸縮的大中型系統(tǒng)的前提。

框架篇中的每篇主要由四部分組成： 它是什么 、 工作原理 、 使用場景 和 可直接調(diào)試的 Demo。其中 Demo 及中間件歷經(jīng)兩家公司四年時間的考驗，涉及幾百個應用，100 多個庫 1 萬多張表，日訂單從幾萬張到十幾萬，年 GMV 從幾十億到幾百億。

所有中間件及工具都是基于開源，早期我們也有部分自主研發(fā)如集中式日志和度量框架。后期在第二家公司時為了快速地搭建，降低成本，易于維護和擴展，全部改為開源。這樣不僅利于個人的學習成長、知識重用和職業(yè)生涯，也利于團隊的組建和人才的引進。

集中式緩存 redis

緩存是計算機的難題之一，分布式緩存亦是如此。Redis 看起來非常簡單，但它影響著系統(tǒng)的效率、性能、數(shù)據(jù)一致性。

用好它不容易，涉及到的問題包括：緩存時長（復雜多維度的計算）、緩存失效處理（主動更新）、緩存鍵（Hash 和方便人工干預）、緩存內(nèi)容及數(shù)據(jù)結(jié)構(gòu)的選擇、緩存雪崩的處理、緩存穿透的處理等。

Redis 除了緩存的功能，還有其它功能如 Lua 計算能力、Limit 與 Session 時間窗口、分布式鎖等。

消息隊列 RabbitMQ

消息隊列好比葛洲壩，有大量數(shù)據(jù)的堆積能力，然后再可靠地進行異步輸出。它是 EDA 事件驅(qū)動架構(gòu)的核心，也是 CQRS 同步數(shù)據(jù)的關(guān)鍵。為什么選擇 RabbitMQ 而沒有選擇 Kafka，因為業(yè)務系統(tǒng)有對消息的高可靠性要求，以及對復雜功能如消息確認 Ack 的要求。

集中式日志 ELK

日志主要分為 系統(tǒng)日志 和 應用日志 兩類。試想一下，你該如何在一個具有幾百臺服務器的集群中定位到問題？如何追蹤每天產(chǎn)生的幾 G 甚至幾 T 的數(shù)據(jù)？集中式日志就是此類問題的解決方案。

早期我們使用自主研發(fā)的 Log4Net+MongoDB 來收集和檢索日志信息，但隨著數(shù)據(jù)量的增加，查詢速度卻變得越來越慢。后期改為開源的 ELK，雖然易用性有所下降，但它支持海量數(shù)據(jù)以及與編程語言無關(guān)的特征。下面是 ELK 的架構(gòu)圖。

任務調(diào)度 Job

任務調(diào)度 Job 如同數(shù)據(jù)庫作業(yè)或 windows 計劃任務，是分布式系統(tǒng)中異步和批處理的關(guān)鍵。我們的 Job 分為 WinJob 和 HttpJob：WinJob 是操作系統(tǒng)級別的定時任務，使用開源的框架 Quartz.NET 實現(xiàn)；而 HttpJob 則是自主研發(fā)實現(xiàn)，采用 URL 方式可定時調(diào)用微服務。

HttpJob 借助集群巧妙地解決了 WinJob 的單點和發(fā)布問題，并集中管理所有的調(diào)度規(guī)則，調(diào)度規(guī)則有簡單規(guī)則和 Cron 表達式。HttpJob 它簡單易用，但間隔時間不能低于 1 分鐘，畢竟通過 URL 方式來調(diào)度并不高效。下圖是 HttpJob 的管理后臺。

應用監(jiān)控 Metrics

“沒有度量就沒有提升”，度量是改進優(yōu)化的基礎(chǔ)，是做好一個系統(tǒng)的前置條件。Zabbix 一般用于系統(tǒng)級別的監(jiān)控，Metrics 則用于業(yè)務應用級別的監(jiān)控。

業(yè)務應用是個黑盒子，通過數(shù)據(jù)埋點來收集應用的實時狀態(tài)，然后展示在大屏或看板上。它是報警系統(tǒng)和數(shù)字化管理的基礎(chǔ)，還可以結(jié)合集中式日志來快速定位和查找問題。我們的業(yè)務監(jiān)控系統(tǒng)使用Metrics.NET+InfluxDB+Grafana。

微服務框架 MSA

微服務是細粒度業(yè)務行為的重用，需要與業(yè)務能力及業(yè)務階段相匹配。微服務框架是實現(xiàn)微服務及分布式架構(gòu)的關(guān)鍵組件，我們的微服務框架是基于開源 ServiceStack 來實現(xiàn)。

它簡單易用、性能好，文檔自動生成、方便調(diào)試測試，調(diào)試工具 Swagger UI、自動化接口測試工具 SoapUI。微服務的接口開放采用我們自主研發(fā)的微服務網(wǎng)關(guān)，通過治理后臺簡單的配置即可。網(wǎng)關(guān)以 NIO、IOCP 的方式實現(xiàn)高并發(fā)，主要功能有鑒權(quán)、超時、限流、熔斷、監(jiān)控等，下圖是 Swagger UI 調(diào)試工具。

搜索利器 Solr

分庫分表后的關(guān)聯(lián)查詢，大段文本的模糊查詢，這些要如何實現(xiàn)呢？顯然傳統(tǒng)的數(shù)據(jù)庫沒有很好的解決辦法，這時可以借助專業(yè)的檢索工具。

全文檢索工具 Solr 不僅簡單易用性能好，而且支持海量數(shù)據(jù)高并發(fā)，只需實現(xiàn)系統(tǒng)兩邊數(shù)據(jù)的準實時或定時同步即可。下圖是 Solr 的工作原理。

更多工具

• 分布式協(xié)調(diào)器 ZooKeeper
• ZK 工作原理、配置中心、Master 選舉、Demo，一篇足以。
• ORM 框架
• DApper.NET 語法簡單、運行速度快，與數(shù)據(jù)庫無關(guān)，SQL 自主編寫可控，是一款適合于互聯(lián)網(wǎng)系統(tǒng)的數(shù)據(jù)庫訪問工具。
• 對象映射工具 EmitMapper 和 AutoMapper
• EmitMapper 性能較高，AutoMapper 易用性較好。
• IoC 框架
• 控制反轉(zhuǎn) IoC 輕量級框架 Autofac。
• DLL 包管理
• 公司內(nèi)部 DLL 包管理工具 NuGet，可解決 DLL 集中存儲、更新、引用、依賴問題。
• 發(fā)布工具 Jenkins
• 一鍵編譯、發(fā)布、自動化測試、一鍵回滾，高效便捷故障低。

架構(gòu)篇——思想提升

會使用以上框架并不一定能成為優(yōu)秀的架構(gòu)師，但一位優(yōu)秀架構(gòu)師一定會使用框架。架構(gòu)師除了會使用工具外，還需要設(shè)計思想的提升和性能調(diào)優(yōu)技能。

此篇以真實項目為背景，思想方法追求簡單有效，主要內(nèi)容包括 企業(yè)總體架構(gòu) 、 單個項目架構(gòu)設(shè)計 、 統(tǒng)一應用分層、 調(diào)試工具 WinDbg。

說到這里順便給大家推薦一個架構(gòu)方面的交流學習群：650385180，里面會分享一些資深架構(gòu)師整理的文檔資料和錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系。還能領(lǐng)取免費的學習資源，相信對于已經(jīng)工作和遇到技術(shù)瓶頸的碼友，在這個群里會有你需要的內(nèi)容。

企業(yè)總體架構(gòu)

當我們有了幾百個上千個應用后，不僅僅需要單個項目的架構(gòu)設(shè)計，還需要企業(yè)總體架構(gòu)做頂層思考和指導。大公司與小商販的商業(yè)思維是一樣的，但大公司比較難看到商業(yè)全貌和本質(zhì)。而小公司又缺乏客戶流量和中間件的應用場景，中型公司則兼而有之，所以企業(yè)總體架構(gòu)也相對好落地。

企業(yè)總體架構(gòu)需要在 技術(shù) 、 業(yè)務 、 管理 之間游刃有余地切換，它包括業(yè)務架構(gòu)、應用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)。附檔是一份脫敏感信息后的真實案例，有參考 TOGAF 標準。但內(nèi)容以解決公司系統(tǒng)的架構(gòu)問題為導向、以時間為主線，包括企業(yè)商務模型、架構(gòu)現(xiàn)狀、架構(gòu)規(guī)劃和架構(gòu)實施。

單個項目架構(gòu)設(shè)計

單個項目的架構(gòu)設(shè)計如同施工圖紙，能直接指導工程代碼的實施。上一環(huán)是功能需求，下一環(huán)是代碼實施，這是架構(gòu)設(shè)計的價值所在。從功能需求到用例，到用例活動圖，到領(lǐng)域圖、架構(gòu)分層，到核心代碼，它們之間環(huán)環(huán)相扣。

做不好領(lǐng)域圖可能源自沒有做好用例活動圖，因為用例活動圖是領(lǐng)域圖的上一環(huán)。關(guān)注職責、邊界、應用關(guān)系、存儲、部署是架構(gòu)設(shè)計的核心，下圖是具體案例參考。

統(tǒng)一應用分層

給應用分層這件事情很簡單，但是讓一家公司的幾百個應用采用統(tǒng)一的分層結(jié)構(gòu)，這可不是件簡單的事情。它要做到可大可小、簡單易用、支持多種場景，我們使用 IPO 方式：I 表示 Input、O 表示 Output、P 表示 Process，一進一出一處理。應用系統(tǒng)的本質(zhì)就是機器，是處理設(shè)備，也是一進一出一處理，IPO 方式相對于 DDD 而言更為簡單實用。

調(diào)試工具 WinDbg

生產(chǎn)環(huán)境偶爾會出現(xiàn)一些異常問題，而 WinDbg 或 GDB 就是解決此類問題的利器。調(diào)試工具 WinDbg 如同醫(yī)生的聽診器，是系統(tǒng)生病時做問題診斷的逆向分析工具，Dump 文件類似于飛機的黑匣子，記錄著生產(chǎn)環(huán)境程序運行的狀態(tài)。

主要介紹調(diào)試工具 WinDbg 和抓包工具 ProcDump 的使用，并分享一個真實的案例。N 年前不知誰寫的代碼，導致每一兩個月偶爾出現(xiàn) CPU 飆高的現(xiàn)象。

我們先使用 ProcDump 在生產(chǎn)環(huán)境中抓取異常進程的 Dump 文件，然后在不了解代碼的情況下通過 WinDbg 命令進行分析，最終定位到有問題的那行代碼。

公共應用篇

先工具再框架，然后架構(gòu)設(shè)計，最后深入公共應用。公共應用因為與業(yè)務系統(tǒng)結(jié)合緊密，但又具有一定的獨立性，所以一般自主開發(fā)，不使用開源也不方便開源。公共應用主要包括單點登錄、企業(yè)支付網(wǎng)關(guān)、CTI 通訊網(wǎng)關(guān)（短信郵件微信），此次分享單點登錄和企業(yè)支付網(wǎng)關(guān)。

單點登錄

應用拆分后總要合在一起，拆分是應用實施層面的拆分，合成是用戶層面的合成，而合成必須解決認證和導航問題。單點登錄 SSO 即只需要登錄一次，便可到處訪問，它是建立在用戶系統(tǒng)、權(quán)限系統(tǒng)、認證系統(tǒng)和企業(yè)門戶的基礎(chǔ)上。我們的憑證數(shù)據(jù) Token 使用 JWT 標準，以解決不同語言、不同客戶端、跨 WebAPI 的安全問題。

企業(yè)支付網(wǎng)關(guān)

企業(yè)支付網(wǎng)關(guān)集中和封裝了公司的各大支付，例如支付寶、財付通、微信、預付款等。它統(tǒng)一了業(yè)務系統(tǒng)調(diào)用各支付接口的方式，簡化了業(yè)務系統(tǒng)與支付系統(tǒng)的交互。

它將各種支付接口統(tǒng)一為支付、代扣、分潤、退款、退分潤、補差、轉(zhuǎn)賬、凍結(jié)、解凍、預付款等，調(diào)用時只需選擇支付類型即可。企業(yè)支付網(wǎng)關(guān)將各大支付系統(tǒng)進行集中的設(shè)計、研發(fā)、部署、監(jiān)控、維護，提供統(tǒng)一的加解密、序列化、日志記錄，安全隔離。