中小型研發團隊很多，而社區在中小型研發團隊架構實踐方面的探討卻很少。中小型研發團隊特別是50至200人的研發團隊，在早期的業務探索階段，更多關注業務邏輯，快速迭代以驗證商業模式，很少去關注技術架構。這時如果繼續按照原有的架構及研發模式，會出現大量的問題，再也無法玩下去了。能不能有一套可直接落地、基於開源、成本低，可快速搭建的中間件及架構升級方案呢？我是一個有十多年經驗的IT老兵，曾主導了兩家公司的技術架構升級改造，現拋磚引玉，與大家一起探討這方面的問題。整個系列有18篇文章，可分為三個部分，包括框架篇、架構篇和公共應用篇。框架篇即中間件或工具的使用，如緩存、消息隊列、集中式日志、度量、微服務框架等，工欲善其事，必先利其器。架構篇主要是設計思想的提升，有企業總體架構、單個項目架構設計、統一應用分層等。公共應用篇是業務與技術的結合，有單點登錄和企業支付網關，以下是具體篇章的介紹：
一、框架篇——工欲善其事，必先利其器
如果說運維是地基，那么框架就是承重牆。農村建住房是一塊磚一塊磚地往上壘，而城市建大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、企業支付網關
企業支付網關集中和封裝了公司的各大支付，例如支付寶、財付通、微信、預付款等。它統一了業務系統調用各支付接口的方式，簡化了業務系統與支付系統的交互。它將各種支付接口統一為支付、代扣、分潤、退款、退分潤、補差、轉賬、凍結、解凍、預付款等，調用時只需選擇支付類型即可。企業支付網關將各大支付系統進行集中的設計、研發、部署、監控、維護，提供統一的加解密、序列化、日志記錄，安全隔離。
在接下來的一段時間里，我會陸續推出此系列文章。因個人原因，發布順序會根據本人的准備情況而作調整，敬請諒解。根據我們以往的經驗，分享者主講一個小時左右，業務研發就可以快速地進入項目實戰。對於后面新加入的團隊成員，也可通過WIKI自主快速學習。這是我們之前對自己的要求，盡量降低工具對人員的要求，簡單實用、降低成本。文章中部分Demo采用C#語言，但到了框架或架構層面，與語言本身沒有太多直接的關系。如RabbitMQ、Job、Redis和集中式日志ELK，它們服務端的部署是一樣的，只是客戶端語言版本稍有不同。所有Demo都可直接運行，服務地址及管理后台也可直接訪問。因為部署在公有雲，牽涉到成本費用的問題，我計划持續到明年3月底。以上這些小小的基礎工作，希望能夠幫到中小型研發團隊，解決他們項目中遇到的實際問題。願與你一起成長，你的分享和點贊是我此次付出的動力，謝謝！
所有Demo下載：
