上一篇文章介紹到雲端儲存專案，下一個做的專案就是統一日誌。這一個專案前前後後做了一年多，版本迭代更新了很多版本，架構升級都做了3次以上。做這一個專案是收穫最大的，我在這一個專案中鍛鍊了大型分散式系統的架構設計能力，也從0開始完全自主研發和設計的一個分散式系統。裡面涉及到了很多技術，例如日誌實時抓取和採集技術、資料實時傳輸、資料壓縮、軟負載均衡、zookeeper等。統一日誌專案從最開始的3個人到最多的時候19人，到最後又只剩下3個人。從每天除了幾GB的資料到每天處理每天幾百TB的資料，從每天處理幾千條日誌到每天處理上百億條日誌資料。可以說做統一日誌專案的每一天都是快速成長的一天，剛開始求著別人使用我們的日誌平臺，到後面全部都主動要求接入、到最後成為日誌的標配系統，所有系統都必須接入。當時我們的口號就是讓日誌觸手可及，我們內部的專案名稱叫做loghub。在做這個專案的過程中，大家一起經常加班到凌晨，但是精神都還是很好的，下班後大家還要一起去宵夜，一起吃燒烤喝啤酒，在一起聊聊工作和技術，聊聊人生和理想。久而久之大家都非常的熟悉了，就這樣大家開始逐漸建立了深厚的友誼，雖然後面大家都散到各個專案或離開了，但是還是每年組織幾次活動。做每一個專案都有不同的感受和經歷，這個專案我逐漸的意識到技術創新和發明的重要性，在這一個專案中我也寫了很多技術發明專利，並且專利局目前已經授權了2篇。如果做技術你就一定要做到行業最好，只有做到最好的時候你才有機會去創造更好的技術，不然你只有永遠的跟隨哪些做的比你好的技術。技術創新都是建立在以後的很多技術之上，如果你不能掌握目前最好的技術，就根本談不上去創新。技術不是憑空一個想法就可以創造出來的，一個技術創新一定就是解決了某一個還沒有被解決的問題或者是比以前更好的解決方案。這個專案讓我印象太深刻了，不論是從技術本身還是團隊本身。

大家都知道網際網路公司變化很快，而唯一不變的就是變化。但是變化不一定好也不一定壞，事情都是有兩方面的。作為一個積極向上的我，更願意去接受變化，並且改變自己。很多人和我聊天以後都會問我一個問題，你是怎麼成長這麼快的。首先我不認為我自己成長夠快，因為只有自己清楚自己想要的是什麼，自己知道對自己的定位是什麼。至於做技術的人怎麼讓自己更快速的成長，我覺得首先前面的文章中已經提到過，積極主動花更多的時間去學習更多和更深的相關技術，並且讓自己有機會去實踐這些技術。當然這裡還有提到一點就是積極的迎接變化，因為變化意味著你又有新技術接觸想的專案和技術了，那麼你的另一個技術領域就有機會去實踐和突破了。從我前面做的每一個專案都幫助我建立了一套技術體系，而且這些技術體系之間相互融會貫通，對於軟體架構設計有極大的好處，因為軟體架構師需要有足夠多的技術才能選擇最合適的技術去架構系統。這裡談了變化，因為變化讓我有機會參與下面一個很重要的專案，而這個專案讓開始真正接觸雲端計算，並且這個專案讓我的能力和價值發揮到了最大。下一個專案就是做一個公有的PAAS平臺。

剛開始做公有PAAS平臺的時候我還只是一個高階軟體工程師，前面做很多專案甚至連高階軟體工程師都還不是。但是已經是那些專案的技術負責人和架構師了，從這裡可以看出，在網際網路公司級別不一定是最重要的，最重要的是你有機會發揮你的價值和能力。不過話又說回來，很多事情沒有級別可能也做不了，不是誰都像我這麼幸運，有機會負責這麼多NB的技術挑戰的專案。現在繼續談談做的這個公有的PAAS平臺，這個專案最開始並不是在我們部門的，而是從其他部門移交過來的。移交過來的時候，部門的老大就在部門內部找人接手這個專案，當時這個專案主要是使用ruby和go語言開發的。部門老大就在部門郵件組裡面發了一封郵件問，哪些人會ruby和go，作為一個從.net轉型到java的技術體系公司，想找ruby和go語言的人才基本上是沒有，何況go語言是一門比較新的語言。不過還好自己比較關注技術前沿和新技術，當我瞭解到go語言是Google推出並開源的一門語言以後就去深入瞭解了一下，深入瞭解以後我覺得這是一門比較有前途的語言，所以就開始買了一本書開始學習，每天晚上睡覺前看半個小時左右，然後在用半個小時把看過的內容實踐一遍，就這樣一個星期下來基本上掌握了go語言最基本的內容。所以收到這封郵件以後我就簡單的回了一封我會go語言，當時自己也還沒有想要去加入做公有PAAS平臺的專案，結果部門老大就認為我要求主動去做這個專案了。結果現在這個專案的負責人（也就是前面說的統一日誌平臺，在簡單說一下我只是技術負責人，不是團隊的負責人，團隊負責人一般是M線）就來問我怎麼回事，不過還是誤打誤撞的去負責公有PAAS平臺的技術和架構了。雖然以前做過好幾個分散式系統了，但是之前的都是比較單一功能的系統，整體架構不是很複雜。但是自從我一開始接觸公有PAAS平臺，就被這個系統的複雜程度驚訝到了，光大大小小的子系統就有十幾個，每一個子系統可能又有很多個小的系統模組組成。不過自己還是很高興，有機會接觸和架構這麼複雜的系統了。我很快的把以前的統一日誌平臺交接給另外一個同事以後就開始正式開始進入公有PAAS的研究了，因為是從其他部門交接過來的，所以接受這個系統還是花了一個星期。他們團隊過來了兩個人進行交接。交接的時候這個平臺要是需要邀請碼才能使用的，也就只有幾百個使用者，活躍使用者就十幾個吧。但是交接的時候還是經常出現問題，而且還有兩個很致命的缺陷，首先是所有使用者入口的代理層經常假死，導致不能使用，只有重啟代理層，第二個是這個平臺完全依賴一個訊息中介軟體，而且這個訊息中介軟體是單點的而且ruby開發的效能很差。所以接手以後除了需要馬上解決這兩個問題，但是還要本身熟悉整個系統那麼多，還要學習ruby。可想工作量很大，基本上剛開始接手的那幾周天天都是需要強制加班的，一遍學習還要一遍排查問題。代理層假死那個問題是最急迫的，首先需要招到原因，代理層系統是使用go語言實現的，在線上是後臺啟動的程序，但是他們以前在啟動的時候沒有把輸出日誌重定向，以致於每次假死都時候都看不到異常日誌。後面我登入上去檢視各種伺服器資源消耗的問題，其中網路連線數引起了我的注意，每次假死的時候一般都是1024左右連線處於timewaiting狀態。後面我重新啟動程序並且把日誌重定向到一個檔案，下次再次假死的時候我去看，果然是too many file....的錯誤日誌。原因終於明白，由於這個程序沒有進行特殊的資源設定又是普通賬號，所以預設只有1024個檔案控制代碼可以使用。找到問題就好辦了，首先把限制調大一些，但是後面還是會假死，因為連結數會持續上漲。很明顯是程式碼裡面造成了連結資源的洩露，就是連結斷開以後沒有及時的釋放，如果不重啟連結資源一直不會釋放。在沒有找到具體原因之前需要有方案來避免這個問題導致的系統問題，那麼我就寫了一個shell指令碼來統計連結數達到可能會導致假死的時候就去自動重啟一下這個程序。這樣問題基本上得到了緩解，能夠給我更多時間去排查問題，因為那個時候我對程式碼一點都不熟悉。後面就開始從程式碼級別去排查問題了，經過幾天程式碼的熟悉終於找到了沒有正確釋放連結資源的程式碼，經過改進完全解決了這個問題，首戰告捷。大家終於可以放鬆一下心情繼續學習PAAS平臺的相關技術。

第二個問題就是訊息中介軟體的單點和效能問題，這個問題必須要在大規模推廣之前解決，不然一點訊息中介軟體出現問題就會導致這個系統不可用。這個是一個極大的挑戰，我就開始調研方案。最終的方案就是自己設計分散式的訊息中介軟體，並且改用go語言實現，工作量很大，不僅僅需要實現伺服器端，還是實現訊息中介軟體的go客戶端和ruby客戶端。不過這些工作都是我自己完成，自己設計方案自己去實現，最後安排了一個測試協助我測試。當然我提交的測試版本基本他是測試不出什麼問題的，這個很簡單，因為在提交測試的時候我自己已經經過了充分的測試，而且我自己才知道怎麼去測試一些異常場景和邊界條件。我正在實現這個方案的過程中，新的問題又出現了，儲存系統又出現問題，為了保證儲存系統的可靠性以前是使用nfs進行同步的，但是nfs有一個問題就是單塊磁碟，而且nfs經常出現效能問題和最後的磁碟容量問題。這個時候又需要我去解決，還記得我前面是做過雲端儲存專案的，當時就是使用開源的分散式檔案系統，所以對我來說很快就有了方案，並且很快的申請資源部署系統就搞定了。但是需要維護這個分散式檔案系統還是比較複雜的，雖然第一次使用分散式檔案系統以後解決了長期的容量問題，但是後面還是可能需要擴容。最後時間充裕以後我們就完全把儲存放在雲端儲存系統上去了，這個雲端儲存有專門的團隊維護的。等我把使用go語言開發的分散式訊息中介軟體上線以後就開始大規模的推廣了，經過幾個月的推廣我們的使用者很快就達到10萬級別了，主要是免費吸引了很多使用者。當然整個過程中還做了很多架構升級和優化的工作，還在各大網站上釋出過具體優化的文章：http://blog.csdn.net/wangdk789/article/details/23605403。

經過上面的改造平臺基本上平臺基本上穩定下來了。後面又做了很多改造和優化，例如整個平臺的監控系統改造，資源利用率優化（提升資源利用率10倍以上）等，就不詳細介紹了，我在很多技術分享會議上進行過比較詳細的分享。整個專案對我技術能力的提升飛躍式的，讓我熟悉了整個PAAS平臺的技術體系，包括現在很流行的容器技術docker，後面由於這個積累又做了基於docker的內部私有云專案，不過這個又是後話了。這個專案不僅僅讓我技術能力得到了提升，讓我對雲端計算也有了更深入的認識，當然對我自己的價值也有成倍的提升。