【對.net系統架構改造的一點經驗和教訓】的技術要點的看法

【對.net系統架構改造的一點經驗和教訓】的技術要點的看法

如題

最后更新 2023/9/3 下午9:45
张巍
预计阅读 7 分钟
分类
.NET
标签
.NET C# 架構設計

也 10 年前的一篇文章,针对《对.NET 系统架构改造的一点经验和教训》一文的技术要点看法。

对.NET 系统架构改造的一点经验和教训】里面的几条对 CSDN 的改造的技术要点如下:

  1. 數據層放棄 sql server 資料庫和存儲過程,全部遷移到 linux 平台上的 mysql 資料庫上;
  2. 緩存不再依賴 .net 自身提供的緩存機制,遷移到部署在 linux 平台上的分布式的 redis 上;
  3. 服務之間的調用,避免使用 .net 自身專有協議,改成 restful 的 http web api 調用;
  4. 靜態資源請求,不再讓 iis 自己處理,分離到 linux 平台上的 nginx 去處理;
  5. 需要讀取的文件系統,也改成訪問 linux 平台上的分布式文件系統;
  6. 部署 .net 代碼的 windows 伺服器放在 lvs 後面,用 lvs 做負載均衡和故障切換。

1. 資料庫應該採用 sqlserver 還是 mysql

作為 web 程式 web 端從來都不是瓶頸,瓶頸從來都是在數據端。按照正常的邏輯,.net 的執行速度要比 php 快,原因是.net 是編譯性的,php 是解釋性的。但是目前很多大型網站都部署在 php 下面。主要是 php 的現成的解決方案比較多。

如果一個系統出現問題從來都不是語言的問題,而是架構的問題,或者說是架構者的問題。作為 web 服務,大部分時候的瓶頸都是在資料庫上。有童鞋說到 sqlserver 資料庫授權貴的問題,大家可以去 qinfo 上找一下大眾點評一個講座,他們用的是asp.net和 mysql 資料庫。本質上 sqlserver 和 mysql 都是作為結構化資料庫,對開發人員來講沒有太大的不同。而資料庫的可擴展性大致就是 1)資料庫讀寫分離 2)業務水平分區 3)大表垂直分區 。其他的就是細節上的實現了

2. 緩存是用自身緩存還是分布式緩存

csdn 將緩存遷移到 redis, 個人覺得這個並不是.net 自身緩存機制的問題,如果做分布式緩存,不管是用 memcache 還是 redis,中間都間隔著機器,肯定沒有 web 伺服器緩存快,如果業務量小的話,採用緩存伺服器來替代 web 自身的緩存機制其實是不划算的。當系統訪問量達到一定程度,自身的緩存機制已經不能夠滿足系統的要求了,是肯定要切換到緩存伺服器的。當然我想沒有人會用 windows 伺服器來做緩存伺服器。不管是.net 還是 java 或者 php。用 memchace/redis 的時候難道還有性能上的差別麼。csdn 最先改版的應該是博客系統,和博客園的博客系統用的都是一家,不過現在修修改改已經早就不是原版的樣子了。不過很難想想當年 csdn 的博客那麼大的用戶量用.net 自身的緩存是怎麼撐過來的。看博客園雲路的文章就知道博客園用的是 memcached 緩存的。

我的理解是,作為緩存當用戶量小的時候可以用 web 自身的緩存機制,當達到一定數量級後,自身緩存機制無法滿足大量數據緩存的需求的時候就需要切換到分布式的緩存組件上去。而遵循的原則就是,讓數據更加的靠近用戶。現在很多網際網路服務,使用 memcached 或者類是的 key-value 資料庫將所有的數據都放到緩存裡面,而 mysql 等結構化的資料庫只是用來作為資料庫的備份,當緩存失效等才會從資料庫裡面讀取數據。

3. 系統協議的選擇

微軟是一個很喜歡將一些協議裡面加入自己的東西,並且也只有自己的那一套解決方案可以用,對於選擇全套微軟的產品來說確實是很方便,但是當我們需要用到非微軟的東西的時候就拙計了。在 web 服務上主要是有 webservice 或者 wcf 的 http 服務。webservice 是一套公開的標準,xml 格式的一套協議。

web service 是一項新技術, 能使得運行在不同機器上的不同應用無須藉助附加的、專門的第三方軟體或硬體, 就可相互交換數據或集成。依據 web service 規範實施的應用之間, 無論它們所使用的語言、 平台或內部協議是什麼, 都可以相互交換數據。web service 是自描述、 自包含的可用網絡模塊, 可以執行具體的業務功能。web service 也很容易部署, 因為它們基於一些常規的產業標準以及已有的一些技術,諸如 xml 和 http。web service 減少了應用接口的花費。web service 為整個企業甚至多個組織之間的業務流程的集成提供了一個通用機制。

在 web 傳輸中 json 是比 xml 格式更加簡短,並且能夠被 js 原生支持的格式,而且第三方的支持也不少,選擇 json 作為載體要比 xml 好。而 restful 對我而言更向是一種數據訪問風格。讓 url 請求更加清晰。而不是協議。所以在 web 系統中,做 api 我更加的傾向用 restful 風格的 api 和 json 作為載體。如果全套都是微軟的產品,我認為 wcf 微軟出品還是最好的選擇。

4. 文件系統的選擇

文件伺服器放到 linux 下是比 weindows 好的,最起碼 linux 不用去處理各種文件碎片,好吧文件服務我也沒有玩過,不好評說。

5. 靜態資源請求是 iis 還是單獨出來

我們知道 iis 是只能夠處理靜態文件的如果訪問動態比如.aspx 文件,iis 會交給 aspnet_isapi 來處理請求,然後將結果返回給 iis。作為靜態文件的處理,nginx 比 iis 是有優勢的。靜態文件處理的時候,我們通常會做的事情就是將 js、css 文件進行合併壓縮,開個一個或多個單獨的二級域名來作為圖片伺服器。減少前端的等待過程。或者是將圖片服務交給又拍、七牛等來處理。前段時間研究過又拍一下,提供 rest 和表單 api 的接口,可以很方便的集成過去。而且提供 cdn 加速,比自己搞靜態文件伺服器要便宜。

6. 均衡負載。。。

當 web 伺服器不夠用的時候,這個時候需要對 web 伺服器部署均衡負載,當然部署均衡負載的方法很多。俺也沒有部署過這玩意,不好說,當單台 web 伺服器無法支持業務需求的時候,均衡負載是必須滴。

總結

所以上面 6 點中除了第二點,我認為是作者對系統理解的不夠外,其他的都是支持的。系統出現了問題,重來都不是語言的問題,而是架構的問題。當然這只是個人想法,也許我所認知的都是錯了。

作者:張巍 出處:http://beixiu.net/

Keep Exploring

延伸阅读

更多文章
同分类 / 同标签 2026/2/7

aot使用經驗總結

從項目創建伊始,就應養成良好的習慣,即只要添加了新功能或使用了較新的語法,就及時進行 aot 發布測試。

继续阅读