算是總結2016，想一想2017

 

    今天，就今天閒得蛋痛，獨自坐在咖啡廳上看看一些技術文章。有感而發，也寫寫這一年的總結。

    想一想2016這一年，真操蛋的忙。不過有時以爲忙點還好，最起碼日子過得充實。這一年開始由0到1開發一個新的項目。從想法到實現，這中間經歷過很短的一個時間。

一開始是由本身把老闆的想法簡單地作了出來，說是簡單，其實也有了核心的功能了。整個階段大概花了一週時間。也就是我們項目的初版。也是年前完成的。

ok，這項目也好好地過完了新年，年後的安排能夠full full的了。各類各樣的功能都想要。有時老闆頭腦一熱，說，這個功能好像不錯，人家作這功能感受挺好的。這個能不能快速實現？

能夠，就這樣，全部的迭代就變爲一週一個版本，慢慢地把功能作上去了。每週都累成狗。這裏想總結一下，不少事情，特別是創業公司，有一個好一點的idea就要快速實現，也是爲了迎接市場的須要。

可是迭代得太快，維護就跟不上了，作出來的質量差強人意，也就過了半年了。到6月，用戶量暴漲，很快從百萬能漲到千百級了。但是以前都沒作過這種數據量級的服務，很快服務器就撐不住了。由於用戶的基數大起了，數據天然會暴漲。

當初仍是單臺服務器，不少寫法都是依賴了服務器的內存，數據很難作到共享，這就成了改成均衡的一個阻礙。可是均衡是勢在必行的了，只有想辦法去改動。第一個作法就是把單臺服務器要共享的數據提取出來。舉個例子，用戶登陸信息當初是存Session的

這一個要作到多臺服務器上共享才能使得用戶在訪問不一樣的服務器時不用再次登陸。Session共享的方案也有很多。咱們後來用了Redis來作數據共享，多臺服務器的登陸信息都統一存在Redis上。把用戶的標識（如生成一個SessionId）存在Cookies上，用戶拿着

這個標識來向Redis服務器換取登陸信息。這種方案就能夠解決了均衡的問題。

      OK，均衡作上去。用戶訪問的分流上也有效果了，但服務器仍是卡。特別是天天的早上7：00-12：00。很容易就卡成白屏，基本上不能使用。服務器的性能絕對是能夠支撐起這些訪問量以及併發量的。想到這裏，就不能再礸牛角尖了，可能還有其餘地方有問題

致使的。如今想一想當初也是死想着某個問題致使的，因此花了很長時間去證實了，頁面打開慢並非一個問題致使，你解決了一個問題，並不能對頁面的優化起到很大的做用。可能同時有多個問題致使你的服務訪問緩慢，頁面打開卡頓。我們用的是windows服務器，在

iis上花了很長時間去看哪裏出問題，看看能不能iis上得出一些問題的來源。結果發現也像園主當初遇到的一些狀況同樣，有黑色1秒的狀況，其資料可參考一下這個：

雲計算之路-阿里雲上：「黑色30秒」走了，「黑色1秒」來了，真相也許大白了

我瞭解到，系統的某些資源是被佔用了，長時間未獲得釋放或是該資源執行的時間比較長，致使外面不少請求被阻塞在外，沒法進來，服務器也就塞車了。資源出不去，請求進不來，打開頁面只會是白屏。

    其實解決一個問題，時間每每是花在找問題上。問題定位好了，方案就會浮出水面了。不少資源是在數據庫層面上阻塞了，由於數據量大起來了，一個表又查又插的，加上這個表的數據量已經在億級了，索引曾經加過，但沒有針對性地去作過優化。

其實索引並非看哪一個查得多就加在哪一列上，而是針對現有的查詢方式以及使用狀況加上去的，索引加上去，對於某部分的查詢起到了一個很大的幫助，但到了1.5億的數據量，查詢又到了一個瓶頸。其實回到數據的最原始作法，把數據作小，查詢纔不會有問題。

舉個例子，你能在移動服務服務廳上查幾個月的數據嗎？細心看看京東的訂單，它也不提供一個日期控件讓你挑哪天到哪天的訂單信息。它會提供一個月內的訂單，三個月內或一年內。其實這些數據也有可能不在原始表，會在一個"熱"表上。「冷」表，"熱"表，"原始"表

這些都擁有着一樣的表結構，只是存的數據有所不同。我說說當初的作法。由於原始表已通過億了，服務器的性能再好也不能在它上面作很雜的查詢了。由於會有"冷"，"熱"表的詞語出來。先說"熱"表，"熱"表是指用戶常常要訪問的數據，但不必定是由建賬到如今的數據，咱們的業務上有一個頁面叫個人收入，能看到個人賬號上的全部進出記錄，包括獎勵記錄，一個活躍的用戶一天都有可能起過一萬條記錄。千萬的用戶，活躍的用戶也有百來萬，因此這表至關大。但好在"個人收入"這個頁面是作在微信上，在手機瀏覽，因此是往上拉再加載下一頁，不會讓用戶本身輸入一個頁碼跳到某一頁上。因此熱表只存着某個用戶的前500條記錄，當用戶加載完這500條數據，再向"冷"表請求500條數據，而後再作一個定時任務，把每一個用戶超過500條的數據刪除，這樣一來就能夠保證"熱"表的數據量不會過大。

熱表的數據保持在1億如下，查詢是不會有太大壓力的。而"冷"表比熱表存的數據要多一些，能夠異步的方式去向"原始"表請求新的數據回來存儲，"原始"表也能夠分表去作存儲。想一想這方法在實現起來比較麻煩，也比較臃腫，但起碼在性能上起了一個很大的做用，資源很快地得麼釋放，服務器的"高燒"也慢慢退下來了。但仍然會有些時候產生卡頓，由於還有些狀況不是這個問題致使的，是由於某個流程很複雜，須要比較的數據不少，整個邏輯執行下來所花的時間很多，也要求邏輯嚴謹。好比提現。

    提現問題應該不少同行都遇到的，包括支付也是同樣的問題。提現咱們是直接發紅包的，在高併發的狀況下，若是餘額未被扣除，但紅包已經發下去了，用戶再一次提現，估計公司有多少錢都不夠發，加上這些損失是要算在開發者頭上的。這些流程又佔時間，邏輯又

複雜，業務又多。若是多人進行提現了，很容易出問題，也很容易致使服務器卡頓，服務器一旦卡頓了，可能影響了其它業務也不能正常使用。如何是好？這時想到了用隊列的形式去處理，其實在提現上，支付上，人們都已經接受了延遲的概念了，想一想銀行的轉賬，也不是實時到賬的，可能要隔那麼幾分鐘。在咱們的用戶看來，你只要錢到了，慢那麼幾分鐘是沒問題的，總好過不到。在.net的環境下，對比了幾個隊列的性能以及開發學習成本，最終選擇了RabbitMQ。前文也說過，不少問題，不少功能要快速解決，因此選一個成本比較低的來處理現有的問題。其實這個消息隊列工具處理起來仍是挺好的，至少出現的問題比較少。不過也是相對的。咱們後期把這個服務裝到Linux上了，包括前文提到的Redis，這兩個服務在windows上很不穩定，性能也不及在linux上好。反正在windows上很容易就會掛了，不能訪問，若是沒留意，就很容易一大堆數據沒法提交了。但放到linux上運行了幾個月，沒發生這樣的事。奇了怪了。

    總結到這裏，不少人可能會說。SB，這些問題的解決套路都是這樣的。我已經工做了7年，這些問題也是在這家公司遇到。之前的公司壓根兒就不會有這麼多數據，數據能達到10萬已經算多的了，也不必用到均衡，也不用隊列去解決併發問題，用戶量少，併發都講不上。一些大神們，可能也是從我這樣的一個階段去經歷過才總結出來的經驗，一些沒作過這方面的事的大神，可能知道這些解決方案，但自身沒遇到這些狀況，也真不知道用的時候能不能奏效，由於我總結到，不一樣的項目遇到的問題都不同，解決問題的套路都同樣但方案可能不同，要針對着所遇到的問題去處理，有些在技術上的性能可能很差，但運營改改體驗可能就能作一個性能好一點的功能了，這些都要溝通去想。由於開發如今可能想的不僅是編代碼的事了，可能要想產品，要想運營，要想運維，還要想售後維護的事。各類各樣的事多着呢。因此這一年，在這樣的一家創業公司上，作得好累，學到的東西也不少。

    在技術上的總結差很少了，總結一下管理的破事。

    其實過這家公司是但願多接觸管理團隊的事，由於在職業生涯上是向管理方向走的，並不是走技術方向。我在這家公司是一名開發經理，頂上有一副總，副總比較少理會開發團隊的事，他作一些高性能的接口，他是典型的走技術方向的人。因此能夠這麼說，團隊的管理全在我這邊。

    在管理上，我第一次以爲本身的情商不夠，情商這詞是從老闆上學到的。老闆是一個情商十分高的人。是我很是願意去追隨的一位領導。對比我當初畢業出來工做，領導給個人印象就是喜歡罵人，你咋這麼笨，這個東西都作很差，這又作很差，那也作很差。其實心理真很差受。但如今的管理（非國企），感受是領導上下不是人，由於這個職位要承上啓下。個人團隊的離職率不高，培養起來也是比較順手，由於基本的框架與底層代碼在員工入職時已經搭好的了，帶着他去學習不是一件難事。在組建團隊時，有一點很重要，是要看清楚每一位同事他想要什麼，你能爲他提供什麼，不少時候站在他的角度去想一些問題，但也要致使他要站在公司的角度去看問題。須要這邊的加班很是多，但怨言很少，一塊兒走過來的隊友一直都在。不少人的離職是由於壓力，我把壓力分爲兩種，一種是心理壓力，一種是身體壓力。心理壓力大很容易讓人產生厭惡，從而產生離職，身體壓力產生厭惡感遠遠比心理的要低。在創業公司上班，加班累是必定的話，身體壓力就必定會有的，這個沒法避免，但心理壓力就不必定。在組建團隊的過程當中，要讓隊友在團隊中找到方向，找到存在感，找到本身的責任所在。同時團隊的氣氛必須活躍，天天上班是指望的，而不是消極的。好比你們合資去買些零食，下午吃點東西吹吹水。吹水這點能夠放開點，由於工做忙的時候，你們吹水的時間不會過長，閒的時候（好吧，基本沒閒的時候），礙於其餘部門同事的眼光，他本身也不會太長張揚。再好比加班時選個地點能夠坐久點，聚在一塊兒吃飯，你們聊聊工做，聊聊生活，均可以。這些經費是能夠向公司申請的，若是這點經費公司都不肯付，估計你這團隊的組建是比較難進行的。能夠自費地去組織自駕遊，去周邊的景點玩一下，由於你們在公司有凝聚力，組織這些活動是很容易的。不要刻意去組織，能夠在吹水提起不如我們去哪玩哪玩。其實這些活動，會在不知不覺間提高了你們的默契，對團隊是有着十分大的做用的。他會以爲這是一個你們庭，一塊兒去作一些事是頗有趣的，包括加班，你們作完手頭上的事會問其餘人有沒有其餘事他能夠幫忙的，這樣的一個團隊後期是很好管的。

    另外，團隊活躍不表明作事能夠隨便。我這裏的一個工做比較難作的是要你們隨時On Call，客服或銷售有問題，在羣上去問問題時，會有人主動回覆，並去解決問題。平時上班時間這些都不成問題，但到了週末，這會成爲一個問題，由於不少人對週末還要作事很反感，反正我已經習慣了。這點是要培養你們的責任心，這個項目是你作出來的，你不處理誰處理，要換位思考，這些功能已經致使用戶不能使用了，你還不處理，會給整個團隊帶來很差的影響，團隊有榮譽感，我的認可這個團隊，他也會主動去承擔這些責任。有一個同事跟我說，他舍友常常笑他這些晚了還要在宿舍加班處理公司的事，他當初也很反感，以爲很累，但後來以爲這些都沒事，只要把這事作好了，也對得起本身，對得起團隊，對得起公司。這些概念是管理者須要向每位成員灌輸的，也是管理者的工做之一。想一想，在半夜打個電話叫同事回公司處理一些事，他說沒問題，這種心情是無比的欣慰的。由於你們都圍繞着同一個目標前進的，都有共同的方向，不少事是容易推動的。

   再說到工做量的問題，在這家公司工做量是很大的，但我不是那種什麼需求，什麼功能都說好，能接的人。有時也站在團隊角度去想問題，儘可能不能安排很是多的工做，但也要站在公司的角度去想問題，哪些是市場急需的，咱們就盡本身的能力去作上去。一塊兒成長，一塊兒去經歷纔是硬道理。因此面對老闆，我是會say no的，面對團隊，我也會說你們配合一下，把這事給辦了。這可能就是承上啓下的做用。

    在管理上還有不少東西要學習，如上文說到的情商。隊友因一些低級錯誤致使功能出現漏洞，致使給客戶罵，這個時間你受氣了，不是把他罵一通就算了，而是想辦法與他一塊兒去解決這事，這事解決後，要跟他分享一下此次教訓與經驗。讓他知道這事是他的責任，他有必要要改掉這些壞毛病。責怪是不能解決問題的，問題出現了，首先不是要追究誰的責任，而是先把問題解決了，再看看後面如何去防止這些問題再次出現。

    在這家公司也有不少很差的事情，在下半年，產品愈來愈亂，亂到我無法控制到優先級，進度，對團隊的需求改了又改，剛開完會決定這周要作的事，下一秒就變了，開始動工去作一件事，下一秒就停了。不少時候很無奈，不少時候想去糾正這些很差的事，但，始終不行，後期感受作壞了，人浮於事。這也是一點很差的地方，於我，卻找不到方向，動力去改變它，由於嘗試過好屢次，沒法改變。這個時候不是我的要適應公司，而是明知公司的產品這樣走下去出問題，本身卻沒法改變。這種很無奈。

    2017，團隊會愈來愈大，管理的目標我很清晰，技術的方向我也很明確。有信心帶你們走得更遠，只但願在產品方向能有一個好一點的轉變。