奶爸程序員的「育兒」心得

自我介紹一下，本人之前是.net程序員，去年下半年負責把項目從.net轉到java，而且有跨機房遷移，億級訪問量，app服務端項目。

自我吐槽一下，工做了8年了，沒有成爲架構師，也沒有進入管理層，沒有成爲技術大師，也沒能成爲分享大師。一直在作業務，並在這條路上越走越遠。有的時候以爲很尷尬，但又有的時候以爲還蠻適合本身。
過年以前，老婆生了一個小公舉。寶寶餓了，「老婆快來餵奶！」，寶寶又餓了，「老婆快來餵奶！」，寶寶睡醒了又餓了，「老婆快來餵奶！」……老婆說：「我感受我就是頭奶牛」！做爲一名「奶爸」，感觸頗爲深入!
本身負責的項目就像本身的孩子，孩子出事了，你們首先想到的就是這個奶爸。奶爸上陣(經常半夜爬起來)，該換尿布換尿布(服務器故障)，該餵奶就餵奶(bug)。若是生病了，就喂喂藥，吃藥無論用，就外面請大夫（疑難雜症，搞不定，請別人搞定也是搞定）。寶寶的奶粉若是出了問題，巴不得拿刀宰了那個奸商（調用了別人的服務，服務掛了，影響到了本身）。寶寶吃飽喝足，安靜睡了，奶爸也能夠安心睡了！

-------------------------------------------------------------------------------
下面開始乾貨，記錄一下本身的「育兒」心得：
一. 技術選型
開發語言：java,go,php,nodejs
如開頭所說，本人以前是C#程序員，C#的語法精妙，逆天的ide，.net版本更新較快，快到我都不記得最新的版本號了。那麼多新特性，若是服務器上安裝的始終都是.net3.5 對咱們來講又有什麼用呢。
開始是很抵觸java的，斷斷續續學了好屢次也沒投入使用，此次必需要上了。不得不說，這麼多年了，java一直在增加，穩定，成熟，幾乎能解決全部問題，並且性能也不差。這大半年下來，java的水真的好深，異步、並行等等，還沒接觸過的好多好多。
go的好處就不說了，在學習，若是喜歡又以爲能拿捏的住，就上吧(哈，確定不會像說的那麼輕鬆)。
nodejs作前端太方便，也有人用來作服務端接口層。
php作前端頁面，就像服務端用java同樣，萬金油，成熟，穩定，用的人多，資料也多。
總之一句話，沒有最好的，只有最適合的！
選java是由於 咱們後端的不少微服務也是用java開發的，方便調用。還有就是，不用java還能用啥。
存儲：mysql, mongodb, redis
當分庫都不能解決問題的時候，分表就格外重要，有一種無限擴展的感受。以前用的oracle，只分庫，沒有分表，hold不住了。
存儲的類型仍是儘可能越少越好，redis作緩存通常是繞不過去，都要用的。
團隊裏有不少人排斥mongodb，就不說具體緣由了，redis能搞定的事情，就不要用mongodb了。
仍是那句話，沒有最好，只有適合，把相應的數據放到最適合的存儲裏。
mq: rabbitmq，activemq
你確定會用到mq的，即便如今不會，之後確定會的。
java框架：spring mvc
用的人多，成熟，坑都被你們踩過了，遇到問題好查資料好解決。
ibatis和struts在咱們的項目中沒有用到。

二. 源代碼管理工具
語言選好了，框架選好了，要開始寫代碼了，問題來了，寫好的代碼用什麼管理？
Git! SVN!
Git的分支真的能夠解決太多問題，很強大！
SVN的tag也不錯，用來作發佈不錯。

無論用什麼工具，必定要作好規範，好比git的分支命名。時間長了分支愈來愈多，若是不規範一下，會亂的一團糟。
再好比分支的合併，應該怎麼合併，不該該怎麼合併。
分支的流程，去哪一個分支提交測試，去哪一個分支發佈等等。
分支合併的衝突解決，必定要事先溝通好，否則代碼丟失，找都很差找。

三. 開工
1. 搭架子
這裏最好能把監控作起來，監控過重要了，一開始就要考慮清楚，否則後面加會痛苦萬分。
若是打算用hystrix之類的框架，一開始也要搞清楚實現方式，後期實現太痛苦。
2. 代碼規範
架構師一開始都會想的很完美，若是不作規範，來來回回人多了，裏面就亂了。
固然，即便你作了規範，也會亂的，只是會亂的小點。
3. 一些基礎代碼
好比：打日誌，http請求，怎麼加監控，怎麼rpc調用，接口在線查詢文檔等。
4. 調試
代碼寫完了怎麼運行，怎麼調試，本地是用jetty仍是tomcat，怎麼發佈測試服務器，這些都要根據實際狀況調整了。
5. 開發工具
如今說好像有點晚了，對於java，有的人喜歡eclipse，有的人喜歡idea。再好比git的管理工具，有人喜歡sourcetree, 有人喜歡敲命令，就比較難統一了。
6. 代碼審查
沒事看看同事寫的代碼，代碼放的位置對不對，有沒有重複代碼，不要把你的架子搞亂了。
Findbugs，這個插件實在太有用了，能夠發現不少低級、沒有預料到的問題，好比可能存在的空引用，String.format格式化問題等等。
7. 團隊溝通
人多事情就會來，確定會有人遇到奇奇怪怪的問題，這個時候就要一塊兒溝通解決了。
底層框架的問題，要趕快修復優化。
流程問題，優化流程規範並通知團隊。
若是能有個wiki，論壇之類的把你們踩過的坑記一下就更好了。
按期開例會同步進步，同步問題。

四. 測試
代碼寫完了，須要有個強大的測試團隊來測試功能了。
咱們的項目是接口，對外輸出json數據，若是沒有自動化比對工具，全靠肉眼真的要瘋掉。
字段缺失，大小寫問題，格式問題，各類問題都會一一暴漏，是時候再優化規範了。
1. 自動化測試
這個看測試實力了，本人也不太懂，有個測試大牛是多麼的重要。
2. 接口文檔
開發在作接口的時候就要把文檔更新好，修改代碼及時更新文檔。
固然寫文檔太煩了，java裏的註解能夠搞這些，而後自動生成在線文檔。
3. 壓力測試，併發測試等
作的接口可否支撐起業務，怎麼評估，就要看壓測結果。不達標？優化！

五. 上線
這個時候要想好怎麼規範發佈流程了，若是公司有團隊幫你作自動化集成發佈就太讚了，若是沒有就只能本身擼了。
什麼jenkins，打包腳本，就本身搞起來吧。
什麼，代碼服務器和上線服務器不在一個機房裏？ 不要緊，svn，git幫你搞定。tomcat也有上傳war包的功能。
1. 申請服務器
根據訪問量評估服務器數量。
要不要拆分接口，好比abc接口只訪問A服務器，def接口只訪問B服務器，nginx接入層搞起來。
2. 發佈
發佈流程，發佈系統。
是否須要灰度發佈？
可否快速回滾。
配置管理系統搞起來。
3. 監控
奶爸程序員最重要的工做之一，就是看監控。
什麼調用量，高峯調用量，成功率，失敗率，超時率，平均耗時等等。
最好能在線查看接口調用返回的code,能夠快速定位問題。
除了app調用你的服務的監控，還有你調用別人服務的監控。一個是發現本身的問題，一個是發現別人的問題，撕逼和被撕逼，都要拿出證據。
失敗率，超時率，平均耗時這些頗有必要，也是奶爸程序員的kpi。
若是能有cpu,內存，網卡使用率等的監控更好了。
再進一步，若是有jvm的監控那就更棒了！
監控都作了，報警必須有，短信、郵件，你懂的！
4. 日誌
奶爸程序員最重要的工做之二，甚至比看監控還重要。
監控有延時，有時候並不能及時發現問題，這個時候看錯誤日誌就很重要。
系統是否正常運行，就是經過日誌來判斷。
錯誤日誌會幫你發現問題，甚至早於用戶發現問題解決問題。
奶爸程序員還要看日誌是否是打多了，打少了，打錯地方了，重要業務日誌有沒有。這是個長期的過程，根據狀況逐步調整。
觀察線上服務器的日誌，是奶爸的重中之重，先於用戶發現問題，先於客服事件解決問題，保駕護航，簡直就是爹媽不容易啊!
因此，辣麼多服務器，你最好有個日誌收納系統，在線查看篩選系統。
5. 穩定保障
nginx接入層，在tomcat前面用nginx作接入層，用nginx作分發，對服務器作分組，周邊服務掛了，不能影響核心業務。
nginx還有個好處仍是作轉發，好比，你有個a.site.com站點要改版，老版本的a.site.com域名不能動，新版本的在別的服務器上，a.site.com域名也必須用，那麼nginx接入層的做用就顯現了，把新改版的頁面所有指向新站，其餘的回老站，搞定。

還有就是在你的後方有衆多微服務，各個微服務也可能會相互依賴，若是其中一個掛了，那麼對你來講可能就是災難，怎麼避免這種狀況？
這個也是最近在作的事情，搜了一圈，都是在談Netflix的Hystrix，這個應該是比較成熟的方案了。
熔斷和降級只能保證微服務不會星火燎原，但不能保證前端出現錯誤，因此前端一塊兒配合，提供一些柔軟、體驗好的錯誤提示會更好。

最後
奶爸的工做固然不止這些了，爲人父母固然沒那麼簡單了，雜七雜八超乎你的想象。
和產品談需求，客服事件排查，和同事討論技術方案，和測試溝通改bug，和領導彙報，什麼？app又打不開了？什麼？機房有故障？什麼？有人在刷接口？永無止境。。。

------------------------------------------------------

說幾個本身踩過的坑：
1. 網卡被打滿
當第一次遇到網卡被打滿的時候，以爲很神奇，有一種介於牛A和牛C之間的感受。時日至今，網卡被打滿真不是什麼新鮮事了。
測試在壓力測試的時候，qps總是上不去，後來發現是壓測機的網卡被打滿了。
服務崩了，緩存服務器網卡被打滿了，單key存儲的東西太大。
總結：網卡被打盡是不得不考慮的事情，尤爲是你來來回回傳輸的東西既大調用量又高。解決辦法就是單key的值不宜太大，並且不管是什麼緩存，隨着值大小的增長，性能是急劇降低的，因此能拆就拆，如今都是分佈式緩存，key越多，各個服務器就越平均,key的增長對性能的影響微乎其微。

2. tomcat總是被重啓
一到高峯期，tomcat就噼裏啪啦的自動重啓，找不到緣由啊，奶爸遇到挑戰了。
就像前面說的，孩子生病了，你有的藥吃很差，那就請大夫開方子，請別人治好也是康復啊。
後來在tomcat重啓的時候作了dump和tcp監控，後來發現tomcat在重啓的時候time wait過多，推斷出某個服務的調用出現了性能問題，積壓太多，累積到必定程度就爆炸了。
後來是增長某服務的rpc調用的鏈接數搞定了。
還有一點就是synchronized關鍵詞的使用要當心，當心出現性能問題，會堵塞。

3. 監控曲線忽然沒了
曲線忽然沒了，掉成0了，頓時嚇尿了，趕快排查日誌，發如今上報監控的時候報錯了，上報的線程的掛了。
改唄，上報錯了就錯了，不能製造驚魂啊！

-----------------------------------------------------------------

總結：
以上都是本人的一些經驗心得，可能對你來講沒什麼特別，也只能說鄙人才疏學淺，跟不上技術發展的腳步。若是你有更好的，請不吝賜教，你們一塊兒成長！
以上的全部東西，對於小公司小團隊，或者從無到有的項目仍是很龐大的。監控系統，日誌系統，運維，發佈，處處都有坑讓你踩。咱們目前所用的rpc調用方案、緩存、mq都是第三方的，雖然有技術支持，仍是踩了不少坑。
坑處處都有，咱們要作的就是踩到坑了不摔倒！

祝你們新年快樂！