前不久我們公司和業內一家一流的公司做了一次技術交流，對于他們的監控系統、日志系統、統一配置系統以及部署系統印象深刻。深刻的原因是我們公司這些工作都是徒手操作，跟他們相比簡直是大刀對坦克了，交流完后我們大伙內部也討論了下，該公司的這些系統我們這邊也是急切需要的，無數生產的問題以及生產效率的問題都是因為監控、日志、配置以及部署所造成的，但是現實是做這些自動化管理的系統需要投入大量人力和物力，而且還要專心致志做相關研究才能將這些系統做完做好，而我們技術部門現在人力遠遠不足的時候這樣的系統開發對于領導而言是會影響核心業務開發的，領導絕對不會讓我們這些開發人員投入大量精力去做這樣的事情，如果不是全身心投入的，那又怎么能做出好東西來哦。其實大伙都很想做這些，就是有勁使不上，本質還是我們公司實力不夠，沒有這家公司那么多的開發研發的資源。
這些系統一定是每一家成熟的互聯網公司都會去做的，因此我今天想根據和這家公司的交流的回憶，思考下這些系統的做法以及會使用到的相關技術，因為我沒做過這些系統，只能是靠回憶和自己的理解進行描述，如果有錯誤的地方還請大家多多包涵哦。
首先是監控系統，監控系統很好理解，它的作用是監控線上系統的運行狀況，如果線上系統發生問題，那么監控系統會將問題及時的通知到每一個相關的人員。我們公司這樣的工作是一個半自動化的狀態，很多工作還是需要大量人力的投入才能完成，但是與我們交流的公司的監控系統已經實現了監控自動化，雖然該公司的系統比我們多的多，但是他們監控的人力的成本卻是比我們少之又少。大型互聯網公司的系統往往是成百上千，服務器則是成千上萬，因此自動化的監控絕對不是看不到產出的而一定是可以實實在在創造價值的。如果我們想對這么龐大的資源進行監控，那么我們就得要去考慮怎么進行監控了，我想這種監控應該首先要定義一些監控的維度，一般最大是系統級別，其次是系統下的功能模塊，再細點就是方法層面的，在實際的開發中，一般會從功能模塊和方法上控制，這些控制好了，系統級別的監控也就相應的做到了。一般這種監控肯定也是會使用到打點的技術，也就是在程序合適的地方引入監控程序，當系統運行出現異常的時候，監控程序會及時的將信息傳遞到監控的服務器，服務器將這些問題記錄下來后通過短信，郵件的方式通知給相關人員。方法級別的監控比較好做，只要監控程序捕獲到了程序運行的異常就行，而功能模塊的監控則是需要相關人員定義一套捕獲規則，當功能模塊觸發到不符合規則的地方，監控系統就會給相關人員發出警報，與我們交流的公司這些都實現的不錯，而且監控的實時性已經達到了秒級，效率是非常的高的。談到打點，知道打點技術的人都會有一種擔心，這個打點會不會影響到業務系統的運行了，在監控打點將信息傳遞到服務端時候，會不會擠占一定的網絡資源，打點技術無法避免這些問題的發生，而最優的解決方法就是讓這些影響降低到最小，并不是因為有這個問題而拋棄打點的方式。該公司怎么解決的，我現在記得不清楚，但是我自己思考解決這樣的問題無非有兩種（針對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，谷歌等等，不知道哪里可以獲得這樣的資料，有人知道可以給我推薦下，我真想好好研究下，因為這種系統實現的難度還是非常高的，要是能掌握能充分體現程序員的個人價值。
文章列表
留言列表
