對.net系統架構改造的一點經驗和教訓（轉）

在互聯網行業，基於Unix/Linux的網站系統架構毫無疑問是當今主流的架構解決方案，這不只僅是由於Linux自己足夠的開放性，更由於圍繞傳統Unix/Linux社區有大量的成熟開源解決方案，覆蓋了網站應用擴展的方方面面。

我記得十幾年前第一波互聯網浪潮的時代，採用Windows平臺ASP架構的大型網站是很是普及的，而現在採用Windows平臺.net架構的大流量知名網站已經百裏挑一了。不少採用Windows平臺.net架構的大型網站都面臨了架構上的擴展問題：

例如國外的SNS網站MySpace網站面臨過很嚴重的性能擴展問題，國內電商網站京東也不止一次受困於架構擴展帶來了性能瓶頸。所以，一些Windows平臺.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系統架構改造的經驗和教訓

我2010年接手前公司的產品和研發團隊的時候，核心系統大約2/3是Windows平臺.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的核心繫統佔整個網站的比重很高，且極端複雜，一旦出問題，根本就一籌莫展，必需要有好手坐鎮維護。當時我已經開始review核心系統的.net代碼，準備親自上陣了。

若是將來放棄「去.net化」的計劃，也許短時間能夠解決一些頭疼的系統維護的問題，可是對整個網站長期的發展會帶來不少不利的方面：例如網站的安全性問題，網站的架構擴展問題，網站服務端軟件全面正版化的成本問題等等。若是當時不下定決心去.net化，那麼未來再想作這個事情，代價只會愈來愈高。

當時，我最初的想法是：招聘2名水平尚可，沒有太大上進心，能夠安於現狀，踏踏實實工做的.net程序員來維護老的.net核心系統；同時招聘和搭建ruby研發團隊，以我過去用ruby開發網站的驚人開發效率，爭取時間，逐一重寫老的.net核心系統。可是這樣作，風險也很大：

我來公司的時間不是很長，當時線上產品又多又雜，足有上百個之多，不少系統我都不清楚幹什麼的；
前公司領導也不太支持我這麼快動手，甚至很擔憂我大刀闊斧的改造網站，會把當時已經很脆弱的網站完全搞休克；
我只帶來1個Ruby程序員，而搭建Ruby團隊，磨合團隊，開發核心系統，都不是一朝一夕的事情，想快也很難快起來；
幸運的是，我招聘過程當中，面試到了兩個至關不錯的.net工程師，有很強的上進心，編程功底和悟性都很好。雖然不符合我當時想找安於現狀的工程師的標準，但我又不太想錯過好的人才，因此我臨時改變了本身的想法，將他們招過來，組建了新的.net團隊。

爲了不出現以前.net團隊流失的問題，給新的.net團隊創造在公司發展的機會和空間，我想來想去，決定採起一個折衷的方案：即保留和沿用.net編程語言和框架，可是網站總體架構仍然去Windows化，概要說來：

數據層放棄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 說過一句很精闢的話：「技術問題，老是在短時間被高估，在長期被低估」，我也想補充一句：「技術出現了問題，歷來都不單純是技術致使的問題」。