10 年前的一篇文章（2013 年，原文robbinfan.com已经无法访问，找到最早的还是在博客园这篇），现在读来还是感慨颇深。
文/范凱
在網際網路行業，基於 unix/linux 的網站系統架構毫無疑問是當今主流的架構解決方案，這不僅僅是因為 linux 本身足夠的開放性，更因為圍繞傳統 unix/linux 社區有大量的成熟開源解決方案，覆蓋了網站應用擴展的方方面面。
我記得十幾年前第一波網際網路浪潮的時代，採用 windows/.net 架構的大型網站是非常普及的，而如今採用 .net 架構的知名網站已經鳳毛麟角了。特別是除了微軟自身旗下的網站 msn 和 hotmail，其他採用 .net 架構的大型網站很多都面臨了架構上的擴展問題，讓 .net 架構的擴展性成了一個比較有爭議的問題：
例如國外的 sns 網站 myspace 網站面臨過很嚴重的性能擴展問題，國內電商網站京東也不止一次受困於架構擴展帶來了性能瓶頸。因此，一些 .net 架構為主的網站，不得不考慮“去 .net 化”，拋棄 .net，全面遷移到以 java 為主的架構上。
但是大型網站的架構遷移，本身也是傷筋動骨的事情，風險極高，成功案例尚不多見，失敗案例俯拾皆是，這是因為：
架構遷移是在現有業務系統上進行的，並不是從容的開發新產品，有足夠的時間測試和完善，相當於給正在高空飛行的客機換引擎，必須一次切換成功，沒有第二次機會，稍有差池，就會機毀人亡。而我們都知道，新開發一個大型系統，沒有上線磨合和完善過，無法做到一次 100% 完美。
架構遷移意味著老的研發團隊將被淘汰，而往往老團隊體系隨著公司壯大已經掌握了足夠話語權，新架構的團隊在公司又根基未穩，出於維護自身利益的本能，新舊團隊之間很容易爆發政治鬥爭，相互排擠，導致遷移失敗。
5173“去 .net 化”的教訓
5173 網站以遊戲裝備交易起家，曾經在客戶端網路遊戲發展黃金時期，迎來了業務爆發性的增長期。此時，用 .net 架構開發的網站已經不堪重負，由於現有的 .net 研發團隊長期無法解決網站的性能問題，5173 決定將網站從 .net 架構全面遷移到 java 為主的架構上。為此，5173 花了很大的代價，從淘寶和 sun 公司挖了很多工程師，組成了一個六七十人的 java 架構研發部門。
新的 java 研發部門開發新的 5173 網站，而老的 .net 研發部門維護現有的 5173 網站，兩個部門並行工作，兩個版本的網站並行運行，這帶來了公司內部激烈的政治鬥爭，新開發完成的 java 版本的 5173 網站從未正式上線過，老的 .net 研發團隊在面臨嚴重生存威脅的情況下，努力解決了一些核心的可用性和穩定性問題。同時隨著端游黃金時代的結束，網站性能問題也逐漸顯得不再重要。
在圍繞新版本網站是否要正式替換老版本網站的問題上，各個利益方爭執不下，反反覆覆拉鋸戰，而空降而來的女 cto 不屬於任何派系，態度模稜兩可。最終鬥爭的結果 .net 利益方戰勝了 java 利益方，java 研發部門被清洗。
我的“去 .net 化”的經驗和教訓
3 年前，我剛接手 csdn 的產品和研發團隊的時候，csdn 的核心系統大約 2/3 是 .net 架構，1/3 是 lamp 架構。研發人員當時也很少：只有 2 個 .net 程式設計師，3 個 php 程式設計師，後來還有 1 個我帶過來的 ruby 程式設計師。當時的計劃是：網站整體架構改造的方向是 linux 架構，逐漸替換掉現有的 .net 系統。因此不打算繼續招聘和補充 .net 程式設計師了，現有的 .net 程式設計師負責老的核心系統維護工作。
但碩果僅存的 2 個 .net 程式設計師在隨後不到半年時間都走了：一個 .net 程式設計師跟著微軟出來的高管去創業，另一個 .net 程式設計師跳槽去百度做了前端工程師。這中間的道理也很簡單：既然公司要去 .net 化，那 .net 工程師就會擔心等到將來 .net 系統都換掉之後，自己在公司還有價值嗎，不就徹底邊緣化了嗎？
當然我在制訂架構遷移計劃的時候，也考慮到了這一點：我給那個更資深的 .net 工程師制訂的是整個公司總架構師的培養計劃，那個精通 js 的 .net 工程師制訂的是未來前端團隊 leader 的培養計劃。不過有不確性的承諾總是不如現實的威脅更迫切，所以我也特別能夠理解 .net 工程師的流失。
這個時候，我陷入了一個兩難的處境：
如果未來還是沿著“去 .net 化”的計劃往下走，就算重新招聘和搭建了 .net 研發團隊，由於 .net 在公司是註定要被替換掉的，那麼新的 .net 團隊是不可能穩定的，很可能來一兩個月，一看形勢不對，立馬走人了。而當時 .net 的核心系統占整個網站的比重很高，且極端複雜，一旦出問題，根本就束手無策，必須要有好手坐鎮維護。當時我已經開始 review 核心系統的 .net 代碼，準備親自上陣了。
如果未來放棄“去 .net 化”的計劃，也許短期可以解決一些頭疼的系統維護的問題，但是對整個網站長期的發展會帶來很多不利的方面：例如網站的安全性問題，網站的架構擴展問題，網站服務端軟體全面正版化的成本問題等等。如果當時不下定決心去 .net 化，那麼將來再想做這個事情，代價只會越來越高。
當時，我最初的想法是：招聘 2 名水平尚可，關鍵是沒有太大上進心，可以安於現狀，踏踏實實工作的 .net 程式設計師來維護老的 .net 核心系統;同時招聘和搭建 ruby 研發團隊，以我過去用 ruby 開發網站的驚人開發效率，爭取時間，逐一重寫老的 .net 核心系統。但是這樣做，風險也很大：
- 我來 csdn 的時間不是很長，當時 csdn 線上產品又多又雜，足有上百個之多，很多系統我都不清楚幹什麼的;
- 公司領導也不太支持我這麼快動手，甚至很擔心我大刀闊斧的改造網站，會把當時已經很脆弱的網站徹底搞休克;
- 我來北京以後，只帶過來 1 個 ruby 程式設計師，而搭建 ruby 團隊，磨合團隊，開發核心系統，都不是一朝一夕的事情，想快也很難快起來;
幸運的是，我招聘的過程當中，面試到了兩個相當不錯的 .net 工程師，有很強的上進心，編程功底和悟性都很好。雖然不符合我當時招聘想找安於現狀的工程師的標準，但我又不太想錯過好的人才，所以我臨時改變了自己的想法，將他們招過來，組建了新的 .net 團隊。
為了避免出現之前 .net 團隊流失的問題，給新的 .net 團隊創造在公司發展的機會和空間，我想來想去，決定採取一個折衷的方案：即保留和沿用 .net 程式語言和框架，但是網站整體架構仍然去 .net 化，概要說來：
- 數據層放棄 sql server 資料庫和存儲過程，全部遷移到 linux 平台上的 mysql 資料庫上;
- 緩存不再依賴 .net 自身提供的緩存機制，遷移到部署在 linux 平台上的分布式的 redis 上;
- 服務之間的調用，避免使用 .net 自身專有協議，改成 restful 的 http web api 調用;
- 靜態資源請求，不再讓 iis 自己處理，分離到 linux 平台上的 nginx 去處理;
- 需要讀取的文件系統，也改成訪問 linux 平台上的分布式文件系統;
- 部署 .net 代碼的 windows 伺服器放在 lvs 後面，用 lvs 做負載均衡和故障切換。
簡單說來，就是單純讓 .net 做應用層的程式語言和框架，其他都交給 linux 平台的開源解決方案。而 .net 框架單純做應用層，無論 asp.net mvc 的開發效率，還是 .net clr 虛擬機的運行效率都非常好，目前我們單台 windows 伺服器上跑幾百萬的動態請求毫無壓力，而且應用層架構是可以橫向擴展的：如果請求負載非常高，只需要添加更多 windows 伺服器即可。總之，做到了揚長避短。
此外，我也比較注重不同程式語言研發團隊之間的交流，鼓勵 .net 工程師熟悉 linux 作業系統，培養 .net 工程師整體架構意識。我們現在的主力 .net 骨幹和我說，感覺來到這裡以後技術上最大的提升就是視野一下被打開了。
在後來兩年的整個網站改造過程中，也證明了這樣的做法是相當成功的：
- net 團隊穩定的延續了下來，而且成為整個研發部門表現一直非常突出的團隊;
- 整個系統改造的過程非常穩健和平滑，沒有碰到過什麼風險;
- 對網站用戶的衝擊很小，基本上都是在潛移默化當中，不知不覺的完成了整個網站產品的翻新;
- 對公司線上業務也沒有造成任何影響，而且隨著系統不斷改造，對業務的支持越來越好;
當網站架構全面 linux 化，並且架構解決方案全部統一以後，其實在應用層用什麼程式語言來寫，就不是一件重要的事情了，我們目前應用層現有產品線，既有 .net，也有 php 和 ruby 寫的，但是架構都是統一的，用什麼程式語言，主要取決於研發團隊資源的調配情況而定。
總之，以我的經驗來說，一個傳統上嚴重依賴微軟解決方案架構的網站，如果要進行架構改造，遷移到 linux 平台，甚至用其他程式語言重寫，從來都不是一個單純的技術問題，它至少涉及如下幾個層面的問題：
- 如何保障舊系統的研發團隊的利益問題，如何做到激勵老團隊參與架構改造，分享成功。這是最重要的，往往也是架構遷移最容易出現的致命問題，如果架構改造註定要犧牲老團隊，完全不考慮和保障他們的利益，我認為一定會產生殘酷的政治鬥爭，最終必然失敗;
- 現有業務系統如何保持正常運轉和平滑過渡的問題，如果架構改造影響到了業務，那一定會夭折;
- 如何保證網站用戶體驗的平滑過渡和改善的問題，如果架構改造影響了用戶基本使用體驗，那也一定會被叫停;
- 領導對架構改造當中出現風險的容忍度問題，以及領導對架構改造周期拉長以後的耐心問題;
一點題外話
我感覺我們網際網路行業有一個不太好的現象：有些網站在促銷期間癱瘓了，有些網站經常出現訪問不穩定的現象，公司老闆就喜歡跑到微博上來放狠話，請下屬喝茶，或者急就章的嚷嚷百萬年薪招 cto。這就好比一個人，平常生活習慣差，花天酒地，從不注意養生，結果長年累月下來，終於病倒了。在這個時候狠狠的揮舞支票嚷嚷，哪個名醫能給我藥到病除，我給誰百萬報酬。
所以，當一個網站出現嚴重的技術問題，其根源往往都不是單純的技術問題，也不是單純換個 cto 就可以藥到病除的，要反思公司企業文化是不是從來沒有重視過研發，對技術團隊的激勵到位了嗎？對架構師的意見重視過嗎？對未來可能面臨的技術門檻是否有過長期的研發投入？
關於這個現象，我記得 fenng 說過一句很精闢的話：“技術問題，總是在短期被高估，在長期被低估”，我也想補充一句：“技術出現了問題，從來都不單純是技術導致的問題”。
来自: robbinfan.com