與國內某知名互聯網公司交流後的心得

前不久咱們公司和業內一家一流的公司作了一次技術交流，對於他們的監控系統、日誌系統、統一配置系統以及部署系統印象深入。深入的緣由是咱們公司這些工做都是徒手操做，跟他們相比簡直是大刀對坦克了，交流完後咱們大夥內部也討論了下，該公司的這些系統咱們這邊也是急切須要的，無數生產的問題以及生產效率的問題都是由於監控、日誌、配置以及部署所形成的，可是現實是作這些自動化管理的系統須要投入大量人力和物力，並且還要專心致志作相關研究才能將這些系統作完作好，而咱們技術部門如今人力遠遠不足的時候這樣的系統開發對於領導而言是會影響核心業務開發的，領導絕對不會讓咱們這些開發人員投入大量精力去作這樣的事情，若是不是全身心投入的，那又怎麼能作出好東西來哦。其實大夥都很想作這些，就是有勁使不上，本質仍是咱們公司實力不夠，沒有這家公司那麼多的開發研發的資源。

　　這些系統必定是每一家成熟的互聯網公司都會去作的，所以我今天想根據和這家公司的交流的回憶，思考下這些系統的作法以及會使用到的相關技術，由於我沒作過這些系統，只能是靠回憶和本身的理解進行描述，若是有錯誤的地方還請你們多多包涵哦。

　　首先是監控系統，監控系統很好理解，它的做用是監控線上系統的運行情況，若是線上系統發生問題，那麼監控系統會將問題及時的通知到每個相關的人員。咱們公司這樣的工做是一個半自動化的狀態，不少工做仍是須要大量人力的投入才能完成，可是與咱們交流的公司的監控系統已經實現了監控自動化，雖然該公司的系統比咱們多的多，可是他們監控的人力的成本倒是比咱們少之又少。大型互聯網公司的系統每每是成百上千，服務器則是成千上萬，所以自動化的監控絕對不是看不到產出的而必定是能夠實實在在創造價值的。若是咱們想對這麼龐大的資源進行監控，那麼咱們就得要去考慮怎麼進行監控了，我想這種監控應該首先要定義一些監控的維度，通常最大是系統級別，其次是系統下的功能模塊，再細點就是方法層面的，在實際的開發中，通常會從功能模塊和方法上控制，這些控制好了，系統級別的監控也就相應的作到了。通常這種監控確定也是會使用到打點的技術，也就是在程序合適的地方引入監控程序，當系統運行出現異常的時候，監控程序會及時的將信息傳遞到監控的服務器，服務器將這些問題記錄下來後經過短信，郵件的方式通知給相關人員。方法級別的監控比較好作，只要監控程序捕獲到了程序運行的異常就行，而功能模塊的監控則是須要相關人員定義一套捕獲規則，當功能模塊觸發到不符合規則的地方，監控系統就會給相關人員發出警報，與咱們交流的公司這些都實現的不錯，並且監控的實時性已經達到了秒級，效率是很是的高的。談到打點，知道打點技術的人都會有一種擔憂，這個打點會不會影響到業務系統的運行了，在監控打點將信息傳遞到服務端時候，會不會擠佔必定的網絡資源，打點技術沒法避免這些問題的發生，而最優的解決方法就是讓這些影響下降到最小，並非由於有這個問題而拋棄打點的方式。該公司怎麼解決的，我如今記得不清楚，可是我本身思考解決這樣的問題無非有兩種（針對java）一種是多線程，一種是RPC的方式，RPC能夠說是一種進程的方式，我我的以爲線程的侵入性要強於進程的方式，若是是我去實現，我應該會用RPC的方式，由於RPC佔用線上系統的資源比較少，它的開銷主要是在監控服務端自己以及網絡資源，並且咱們很容易控制RPC所佔用的寬帶資源的比例。互聯網公司的系統應該都不會有單點的系統，都會用分佈式來實現，而監控系統須要管理那麼多的系統和資源，因此它自己的分佈式系統的可靠性要求就很是的高，該公司這邊解決分佈式可靠性的問題是經過zookeeper或者借鑑zookeeper的原理本身實現的一套機制，此次分享我深切感覺到zookeeper技術的重要性了，zookeeper我今天就不展開討論了，我後面會從新研究下zookeeper，等研究好了，我再專門寫一篇文章。監控系統還須要一個很重要的功能就是自動化部署，這點也是很是關鍵的，能夠想象下一個擁有成百上千個系統，成千上萬服務器的公司，若是監控系統不能實現自動化部署，避免過多人力介入的辦法，那麼作出來的監控系統可能還沒能體現到自身價值以前，就開始爲每一個應用系統埋下了定時炸彈，惋惜本人沒有參入過多的系統運維的工做（由於我如今在公司是專職前端）因此我不清楚業內通常是如何作到這點，我只能想象一下，是否是就是使用一些能作批量部署操做的shell腳本就好了。與此同時該公司的監控系統作的也很是人性化，全部的操做均可以在一個Web的管理系統裏完成，這個管理系統也是用了大量的可視化圖表的方式，直觀且易於操做，同時還有相關的績效管理功能，實在是很是的強大。

　　下面我再說說日誌系統，經過日誌查找線上系統的問題，這是解決生產問題的惟一方式，可是對於查看互聯網系統的日誌是一件很是痛苦的事情，由於互聯網的系統幾乎沒有單點，都是分佈式的，因此查看日誌的時候咱們就須要查找不少臺服務器，若是碰到程序自己的日誌寫的不太合理，那麼查問題幾乎是一件大海撈針的事情，此外，在公司裏，生產環境每每都是被嚴格的管理起來的，只有不多數的人能夠直接查看生產日誌，通常人員想看生產日誌經常會有一大堆冗長的審批過程，這些審批過程保證了生產系統的穩定性和安全性，可是惡果就是嚴重拉長了問題解決的時間，那麼若是有一套實現辦公自動化的日誌系統那就是很是棒的一件事情了，這裏我仍是想說我認爲這樣系統是實實在在有產出的，是提高公司能力的一個重要手段。與咱們交流的公司就本身研發了一套這樣的日誌系統，它的日誌系統定義了一套日誌的規範，應用系統的開發人員能夠按這個規範打出日誌，該系統除了能打出符合日誌規範的日誌，還能將應用系統自身的日誌拉到日誌系統裏，這些日誌的查看再也不是經過命令行在控制檯裏看，而是由專門的Web系統來進行查看，他們的Web系統作的挺棒的，能夠分組分類的查看相關係統的日誌，這些日誌在規定的時間裏會自動刷新，同時使用者也能夠在Web系統裏像控制檯那樣實時的查看相關的日誌，只有有相關查看日誌權限的人，隨時隨地不受限制的查看到系統的運行狀況。日誌系統的設計上某些地方和監控系統相似，也要作到非侵入式，勁量下降系統對生產系統的影響。比較特別的是，在Web系統裏看到日誌並非保存在生產系統上的日誌，而是存放在日誌系統裏的日誌，也就是說該日誌系統會實時的同步生產系統的日誌，這種同步不是盲目的，而是會根據一個的規則同步到日誌系統，這種規則能夠保證在Web系統裏很容易定位到那個系統，那個功能模塊的日誌。大量日誌存儲毫不可能用關係數據庫完成，那麼想高效的查詢到日誌就得使用搜索技術，而對方使用的是solr進行搜索的。固然保證日誌集羣的可靠性，zookeeper就得上場了，zookeeper已是作分佈式系統不可避免的技術了。

　　第三個是統一配置系統，系統的配置通常是指將一些環境的參數，系統的參數或者是某些會常常變化的信息用一種特殊的文件保存起來，這樣利於系統的維護和擴展，java裏一般使用xml文件和properties文件存儲配置信息，而那些會常常改變的信息一般會使用properties文件保存，這種配置管理方式對於規模不大或者變動不多的系統而言十分有效，可是對於互聯網公司的大型系統以及一些關聯度很高的系統而言，當系統運維到必定程度，配置文件多是最讓人沮喪和痛苦的事情，特別是維護它們的方式是經過人力的方法，其潛在的風險也是很是之大的。之前我有篇文章寫道zookeeper一個重要特性就是配置管理，該公司實現的統一配置系統就是經過zookeeper來實現的，至於如何使用zookeeper作配置管理，等我研究好了後我在寫一篇文章分享下。統一配置系統一樣也是可視化的，使用者不用直接到生產機器上修改配置，重啓服務器，而是直接在Web管理系統裏操做，配錯了能夠修改，也能夠進行回滾，咱們公司這方面和他們真是有差距，咱們要改一個配置須要好幾個領導審批，而後興師動衆的到機房上線，時常還會出現配置改錯改掉的問題。

　　最後是部署系統，生產部署是一個項目的最後一步，也是內心壓力最大、風險最高的一步，若是最後上線部署失敗了，這種感覺就猶如進行了一次辛苦的長跑，眼看就要到達終點了，沒想被一塊大石頭絆倒了，甚至還會掉到坑裏，最後還要挨領導批，那滋味可很差受。咱們公司系統部署的問題不少，咱們公司的環境能夠分爲五類：辦公環境、開發環境、測試環境、預發佈環境和生產環境，辦公環境、開發環境和測試環境是通的，這個比較好，可是辦公環境、開發環境和測試環境同預發佈環境同生產環境基本上是徹底隔離的，並且不一樣環境之間的環境配置，系統配置等等東西都存在或多或少的差別，常常發生，測試環境運行好好的程序到了預發佈環境就出現問題，更揪心的是，測試環境和預發佈環境都沒問題，上了生產出問題了，並且是環境形成，這就讓咱們每一次部署操做都是當心翼翼的，部署後任然還要投入大量的人力和時間進行監控和測試。與咱們交流的公司這邊的環境其實比咱們這裏還要複雜，它們甚至在預發佈環境和生產環境之間還有一個仿真的環境，仿真的環境是能夠直接從生產上摘取一個服務器，部署新開發的程序，讓相關人員進行測試驗證，並且部署環境的切換也是有專門的Web系統進行管理，不一樣環境之間能夠作到平滑的過渡。這樣部署操做不只是安全性以及在效率上都有很大的提高。

　　與咱們交流的公司說他們幾千名的開發人員只須要20幾個運維人員，而咱們幾十人的開發部就超過了20幾個運維人員，的確差距很大，不過這種差距也能夠理解的，由於人家有強大的開發團隊能夠支撐這些內部管理系統的研發，而咱們的開發團隊人力是嚴重不足，但我相信只要公司業務蒸蒸日上，這些事情早晚會作的。

　　由此能夠看到互聯網的技術遠比傳統的企業軟件複雜的多，互聯網的技術基本都是分佈式的，所以線程、進程、通信、分佈式技術以及分佈式的可靠性是十分的重要。我上面描述的這四種系統，也不是和咱們交流的公司自創的，也是大量借鑑與美國牛叉的大型互聯網公司，例如facebook，谷歌等等，不知道哪裏能夠得到這樣的資料，有人知道能夠給我推薦下，我真想好好研究下，由於這種系統實現的難度仍是很是高的，要是能掌握能充分體現程序員的我的價值。