作者：往邊界
來源：https://www.cnblogs.com/yasire/p/6366379.html
自我介紹一下，本人以前是.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都是第三方的，雖然有技術支持，還是踩了很多坑。
坑到處都有，我們要做的就是踩到坑了不摔倒！