話說昨天的港股發生了一件大事，騰訊成為亞洲市值最高的公司，在這歷史性的一刻，作為在鵝廠工作的C# 程序員，也應該讓世人了解下C# 並不是那么沒有市場。在鵝廠，代碼構成中60%以上是C++, C#也有10%左右的份額，后續的文章中我會和你繼續分享，當然如果你有興趣加入鵝廠會更快獲取類似信息，需要可以找我內推。小二計划寫幾篇文章來讓大家正確的認識下C#。
當我們還沒來得及把自己的夢想捂熱的時候，偉大的王老師一語驚醒了所有吃瓜的圍觀群眾——人嘛，光着眼於夢想是不行滴，還是要先定一個能達到的小目標。一個一天處理5000萬級別的應用,換算成每秒578個請求,當然應用不會這么平淡，有高峰有低谷，不過這也不是很難達到的目標，我們就來看看這樣的一個小目標如何實現，這里分享的是我的一個真實案例：騰訊OA基礎服務，簡稱TOF。
首先給出一個直觀的數據，讓大家有個初步的印象。
2015-11-5 這天的組織架構API的請求數達到36535867,超過了三千萬的請求，這天的總請求數48922122，接近五千萬的請求。
你很難想象到TOF使用的是.NET技術構建的，能夠在每天幾千萬請求，可以媲美同樣是.NET技術構建的StackOverflow社區，不過確實我也使用了大量StackOverflow開源的.NET技術，架構上也非常像StackOverflow。下面列下硬件列表：
·6台數據庫服務器（6台SQL Server），其中3台SQL Server 2012 Always集群式核心數據庫使用的是物理服務器
·12台Web服務器（IIS7.5），服務器是IT雲VD-6機器（8核32G內存）
·2台分布式緩存服務器（Redis），服務器是IT雲VD-5機器（4核16G內存）
·8台應用服務器（處理TOF的核心業務，使用WCF服務構建），服務器是IT雲VD-6機器（8核32G內存）
·IT雲提供的負載均衡服務器（LVS集群）
這些服務器都是虛擬化的服務器，騰訊IT有個內部的私有雲平台的機器，比StackOverflow的服務器比起來要弱很多。但是我在程序的架構和性能優化方面做了很多，程序架構上采用微服務架構的思想，一圖勝千言，下面給出TOF的架構圖：
上面是總體的架構圖，那么每個具體的服務又遵循了單體應用的架構，使用的是N層服務，一圖勝千言，下面給出TOF的服務架構圖。
負載均衡（LVS）
負載均衡使用的LVS和tlinux，負載均衡器使用的是IT雲的LVS集群，通過IT雲進行管理
Web層架構（IIS 7.5，ASP.Net MVC 5.2.1，和.Net 4.5.2）
TOF經過負載均衡層導入流量到12台Web服務器, 分區域部署在2個地區，Web層通過WCF服務同后端的業務服務交互。
服務層（WCF 4.5， Net 4.5.2）
在整體邏輯架構圖上可以清晰的看到，緊挨着Web層的是服務層（部署在Window服務器Windows 2008 R2上）。服務層基於WCF實現的微服務架構。為了提升這服務做了非常多的冗余，每個服務都有至少３個實例。
緩存（Redis）
TOF在緩存層用Redis，Redis服務器16G內存，采用master/slave結構部署，盡管每天2500萬的ops，每個實例的CPU使用率也在2%之下。
Redis所在服務器有L1/L2高速緩存，Web服務的HTTP緩存設置在一級緩存L1中，Redis緩存在二級緩存L2。當用戶訪問在一級緩存L1中未命中后會去二級緩存中的Redis取值，如果web服務在L1和L2兩級緩存都未命中，則會直接去原始數據源獲取（比如，數據庫查詢，API回調等），然后並把獲取到的結果緩存到本地和Redis中，這時其它服務未命中L1高速緩存便會去二級緩存L2/Redis中獲取，節省了調用數據庫查詢或者API回調的訪問時間。
OA登陸和組織架構都有自己的L1/L2高速緩存，通過L1緩存Key前綴、L2/Redis緩存數據庫ID。
貼張Redis緩存服務已經運行445天，處理了110億的請求的監控圖：
數據庫（SQL Server）
SQL Server是TOF唯一的源數據庫，所有Redis的數據都來自SQL Server。使用微軟的SQL Server監控組件AlwaysOn Availability Groups部署了一個SQL Server集群。服務器集群的配置也比較低4核32G 的A5機器。
所有數據庫過去24小時CPU監控圖如圖所示，大部分情況CPU使用率較低，偶爾做下緩存任務時會高些。
細心的朋友可能看出上圖就是使用StackOverflow開源的Opserver所采集的數據。
.NET應用程序性能優化
TOF系統屬於高並發的系統，使用系統默認的配置是不行的，需要對操作系統和.NET框架做優化：
-
Windows優化：調整tcp連接數，保證系統層面保證服務的不受限於操作系統，調整操作系統的TCP/IP參數，比如把Time_Wait 時間窗口2分鍾à45秒，可用的端口數調整到65535，默認才5024個，對一個大並發的系統來說遠遠不夠。
-
Web服務器優化：根據服務器的CPU核數調整進程數和HTTP層相關配置。
-
WCF框架的參數優化：
-
采取NETTCP綁定，保證框架通信的高效率
-
序列化：xml -> rest\json ->protobuf，適配器模式，使用protobuf替代wcf默認的二進制序列化，這里就可以6倍的性能提升。
-
根據服務流量調整WCF流量限制配置的值
總體來說，TOF整體架構並沒有采用那些非常高端的技術，使用的都是非常普通的.NET技術，混合使用Windows/Linux和開源技術照樣可以打造高性能高並發的應用系統。
相關文章：