24
係統架構-性能篇章2（係統拆分2-問題）
在文章《係統架構-性能篇章2（係統拆分1）》有提及到過關於係統在什麼情況下會拆分，拆分的目之類的問題，本文會闡述一些關於拆分過程中遇到的各種各樣的常見問題進行分析，和上一個文章中提及到的一樣，講解的目錄如下：
1、負載均衡設備的問題。
2、不同係統之間的通信問題。
3、數據寫入和查找的問題。
4、跨數據庫事務問題。
5、跨數據庫序列問題。
6、不同應用的本地緩存問題。
7、係統之間的直接依賴和間接依賴問題。
8、獨立模塊麵臨的單點問題。
9、各類批量分組、切換、擴展的問題。
10、統一監控和恢複問題。
進入正題：
一、負載均衡設備的問題：
負載均衡設備就是當係統被拆分為多個節點進行發布後，前端應用係統訪問的過程中，還是應當有一個被一個統一認識的整體，也就是有一個統一的入口，而不能讓客戶端來記住每一個節點的地址來輸入；如輸入：www.google.com，穀歌的後台就有非常多的服務器來為我們服務，但是我們訪問的是一個目錄地址。
付：負載均衡設備目前是狹義的一個公司內部的入口或者一套係統的入口，不過很多廣義的負載均衡還包含鏈路的負載均衡（網絡層的解析）、同一台機器上進程之間的負載均衡，不過都可以理解為節點之間的負載均衡。
我們在經過網絡層解析後，訪問到目標地址後，然後再開始找對應的應用係統平台，然後找到可執行對應應用的主機信息，開始進行負載均衡的操作動作；什麼是應用自己的平台呢？那就是URL上麵的子目錄，或主目錄本身也有可能。
負載均衡也有硬件負載和軟件負載，硬件負載均衡器一般比較貴，受限製於硬件本身，在一定程度上，它較軟件負載均衡更加有效，但是在要求更好的負載下並且要求低成本的情況，軟件負載又具有了更好的優勢，也就是高集成度的東西始終處於中間的那個位置，但是兩者都是可以並存的。
目前我們討論的主要是軟件負載均衡，在Weblogic中有一個自帶的集群配置策略，通過Proxy進行代理，Admin節點管理多個Managed節點，不過這個負載均衡比較挫，數量稍微多一點就會死掉，這個節點也做得不好，在係統的負載一般的情況下，選擇這種方式會比較簡單一些，配置的方法也是weblogic提供的傻瓜式下一步就可以了；不過注意的一點，不要在proxy節點和admin節點去發布什麼應用啥的，這種節點要是再配置些應用就更費了，qps就更低了。
其次就是我們注明的apache，其廣泛應用於很多領域，也是目前全球使用範圍最廣的負載均衡，而且提供了很多web模塊直接編譯一些語言（如php模塊），一般在這種負載均衡器下，qps可以達到3000以上甚至於更多，不過有些時候要看反饋路徑是否經過apache本身以及每次請求數據的大小，在大部分的應用下，使用它已經可以注意支撐起來；很多時候這種代理也稱反向代理服務器，apache裏頭也擁有非常豐富的第三方模塊，這方麵它甚至於超越了nginx，在安全性方麵也較好，技術資料較為健全。
世界級大型反向代理服務器nginx（Engine-X），可支持Http反向代理、負載均衡、FastCGI支持、Rewrite、緩存等等，郵件相關的各種協議，其QPS可以支持3萬以上，經過改進後的nginx更加強大；這是一位俄羅斯的著名程序員（Igor Sysoev，自稱為一個高級的係統管理員）編寫的，目前全球排位第四位，不過它的性能是最強大的，也是高並發的互聯網公司借鑒的標準，並且它輕量、開源、穩定、高性能、低CPU開銷、低內存開銷、緩存壓力甚至於抵擋常見的攻擊；nginx發展為2001年開始，04年第一個public release版本出來，至今已經有10年曆史，其接受第三方模塊較少，雖然在第三方的支持上較少，但是其代碼非常的幹淨利落，非常高的代碼質量，並且更新很快；另外nginx在熱部署上遠遠超越於apache，不過要在上麵做擴展比較困難，技術資料相對較少一點（關於nginx的一些細節，後麵有文章單獨說明，因為他的確太強大了）。
其次全球還有很多的負載均衡設備，如：IIS（微軟支持的）、google等，各自有自己的應用場景需求。
負載均衡主要需要做幾件事情：
1、需要根據信息找到目標主機進行負載。
2、多個目標節點，需要均衡的負載。
3、記住統一個session前一次訪問的主機，下次還會訪問這個機器（看模式，有些是無狀態session）
4、某個節點失敗後，需要進行相應的切換操作。
5、在指定的配置下，可能會負責反饋結果，不過在高並發應用下，這裏可能會涉及到多層負載均衡的情況，最頂層的負載均衡設備一般不幹這事。
6、必要時需要在切換時發生session的複製（在有狀態session下，需要將session的內容複製到另外的機器上，要求session中保存的內容是可以被序列化的）
7、在增加節點時，高性能的要求是在這種情況下不能出現負載偏向，這種依賴於負載均衡設備的算法，一般我們采用一致性hash可以達到這個目的，不過最初的一致性hash算法還存在很多問題（Hash的KEY通常是一些URL或者參數的內容），並不能真正解決這些問題，後來出現了很多變種的一致性hash算法的確可以很大程度上降低負載偏向的問題，其次：一致性hash並不適合於解決數據層的問題，也就是數據層具有持久性的，用一致性hash並不能解決其動態擴展的問題，雖然一致性hash為了解決這個問題做出了很多算法的變動，不過仍然存在很多版本問題。
二、不同係統之間的通信問題
上一篇文章中提及到了，係統能做到一起，我們做到一起最簡單，因為模塊之間調用就直接用對象直接就可以引用到，拆分成多個係統就不一樣了，係統之間的調用就成了進程和進程之間的通信了；
有關通信就說到早期的socket，這個socket雖然是最古老的技術，不過它也算是目前所有網絡技術衍生的基石，網絡的交互的不斷優化過程就是socket特征不斷變化的過程。
說到socket就是編寫程序比較麻煩，雙方調用和接受都需要編寫單獨的程序去通信，要求傳輸的內容都可以被序列化，寫的一方有點類似於寫文件，讀的一方有點類似讀文件，不過它也是使用IO本身的一種方法去通信；很多程序員初手在調用完了也會搞忘把socket關掉。
麵對java想要把底層封裝的，而且盡量減少程序員的錯誤，所以RMI誕生了，遠程方法調用誕生了，RMI是jvm自己封裝的一種遠程方法調用的協議，中間通過對象序列化來完成，調用方需要有遠程的接口，由於RMI本身調用過程中配置比較麻煩，但是又有了這種技術，於是EJB誕生了，EJB在RMI的基礎上衍生出標準化的分布式編程模型，不過它都是基於RMI來編寫的，主要目的是將業務和VIEW分解開，不過它是物理上將其分開了，在部署和調試程序上相對比較困難，最頭痛的就是RMI裏頭在調用完後會自己做一個System.gc()方法，將會導致Full GC，於此同時衍生出不同廠商不同係統的通信方法也是沿用EJB，是的各個工程裏頭都有和自己不想管的係統的代碼和jar包，Perm區域增加的開銷暫時忽略掉，不過係統的移植性和產品化就出現了很多困難（如果在另一個地方要發布同樣的係統，但是這個係統中有很多外部調用需要，要麼最後工程魚龍混雜，要麼要把這些東西分解出來是很困難的事情，甚至於會報一些詭異的錯誤）。
後來基於RPC的webservice出來了，它跨語言，因為它傳遞過程中你可以認為它不是傳遞對象（後來EJB也把它融進去了），不過我們很多時候還是喜歡用spring來集成它，高版本的webservice可以通過注解完成大部分的工作，不過tomcat發布這個玩意一直不是很好用；另外Spring裏頭也提供了對於RMI本身的封裝的支持，以及spring hessian也是非常不錯的交互框架，而且spring是輕量級的，越來越多的人開始選擇spring了，因為EJB很多功能它都有，沒有的大部分東西也不想要，用了EJB還有各種各樣的問題。
最最簡單的交互方法，HttpClient，這種是apache組織提供的一種非常輕量級的交互方法，其實也是基於socket寫的，因為瀏覽器本身和服務器交互也是一種socket，隻是建立了協議包頭和一些短連接機製；所以HttpClient就是使用socket模擬的一個瀏覽器客戶端發起的一次提交操作，可以發起Get和POST的請求，也可以控製參數的傳遞的字符集等等，傳遞和結果信息由雙方決定；服務方隻需要通過正常的response輸出數據即可，隻是這個時候不是輸出一個頁麵，而是輸出一些客戶端可以被解釋的數據，如json結構或xml結構的字符串信息。
總之，係統一旦拆分，通信是避免不了，從這裏也可以看出，並不是係統想怎麼拆分就怎麼拆分的，要盡量減少相互之間的通信，就需要了解係統，做到係統的低耦合、高內聚，減少外部依賴，不然係統大部分時間就在通信了，沒有做其他的事情，不過也不排除有這種情況，那就是有些係統是專門用來做通信的，這種係統可以例外，它處理的核心就是通信處理，做中間轉換。其餘的業務係統盡量做到減少通信的模塊數量。
三、數據寫入和查找的問題
關於數據級別被拆分後，尤其是再數據庫級別被拆分後，就會麵臨數據寫入和讀取的問題，那麼在寫入的數據就需要能夠讀取出來，那麼這裏就需要相同的規則進行讀寫操作，此時數據庫拆分後，我們更多的是將數據庫作為一種類似NoSQL的目標機器，或者說是一種存儲引擎的分布式部署方法，要實現讀寫的一致性就要保證一樣的規則（當然你說你可以用不一樣的規則，除非你中間用了十分複雜的數學算法來做，的確有這種可能，不過考慮到業務數據的準確性，我也一直不敢嚐試這些經驗，所以本文約定，寫入的規則和讀出的規則是一致的）
上一篇關於拆分的文章中提及到了數據的拆分方法，這裏就不更多的提及了，總之數據的拆分方法就那些，寫入和讀取就按照這種規則。
在這種設計下，讀數據，如果要做表關聯成為一種困難的事情，所以它隻是解決了一些問題，在並發的係統中，我們在這種情況下更多想將數據庫目標作為存儲引擎來做，對這類分布式的表讀操作基本都是單表，降低數據庫的壓力，根據讀的數據，再去檢索其他的信息，相關性的靜態數據可以適當用緩存來處理以提高性能。
其次，如果是對於非常大的表，如果還有擴展表，如有一個人類表，每個人類都有很多不同種類的屬性，擴展屬性都是動態的。所以擴展屬性也數不勝數，由於人類這個表本身就很大，擴展屬性就更加可怕，要是兩個表做關聯，結果可想而知，但是我們發現人類很多屬性是具有共性的，也就是類型是相同的（如：膚色、學曆、婚姻，至少屬性名是相同的，是否可以隻存儲一份？），再考慮，這些屬性都是可以被枚舉的，或者說可以被數清楚的，即使要增加也不會像業務數據那麼多；那麼OK，我們就將這種屬性和屬性值單獨存放起來，這裏可以將這些數據放在緩存中；而這些擴展屬性可以作為原表中的一個大字段來存放，如json結構，為了節約空間可以適當對K和V做一些壓縮，這樣就在OLTP下要查找數據，適應了擴展性的問題。
而在OLAP中，這樣肯定是不行的，因為他們需要其他的維度的數據，所以OLAP更多的是清理和整理計算數據，一般這類海量數據我們是通過一些分布式平台去計算，增量信息也可以，也就是一些關聯的結果需要被分析才能被統計以及被搜索；如需要統計具有碩士學曆二婚以上的人（每個城市取前麵幾名），正常的數據庫，一個GROUP BY就搞定了，但如果在海量分布式下就沒那麼容易了，需要通過計算成較為好計算的數據才方便使用；再例如：在搜索中輸入一個黑色，那麼就應當將相關黑色的內容搜索出來，而不僅僅在主表中存儲了黑色的代碼（如0代表了黑色）；在這類計算中，OLAP就需要計算過濾處理數據了。
OK，這部分暫時就說到這裏，關於拆分的方法，上一篇文章中有說明。
四、跨數據庫事務問題
從這一章開始，後麵都是些細節問題，相對字眼要少點，嗬嗬。
跨了數據庫，最大的困難就是數據庫的事務一致性，類似多個庫，如果要做大絕對一致性幾乎不太可能，除非網絡各方麵因素非常好，JTA本身提供了多數據源一致性操作，存儲過程也可以遠程操作其他的數據庫（不過跨數據庫類型應該還有問題），不過他們或多或少的都存在一些小問題，如果你要用最簡單的方法來實現一個一致性事務，可以開辟多個數據源，然後分別用不同的數據源去操作，操作完成後，幾個數據源一起做commit，或一起做rollback，雖然說這個未必能完全保證一致性，但是很大程度上是可以保證的，因為數據執行完了，commit和rollback失敗的概率很低，除非網絡級別和數據庫級別發生不可預知的異常。
很多時候我們更加願意用最終一致性來考慮這種問題，或者最終一致性與絕對一致性結合的方法，如上麵的問題，可能我們會在和核心庫中寫入數據，然後將要寫入其他某個庫中的數據放入到一個中間件中，這個可能是一個服務器，可能是一個文件，也可能是一張表，總之在寫入時，寫入到本庫結束，就認為成功或失敗了，遠程的服務，異步同步數據，如果出現什麼問題，報警出來由人為處理（這種隻要程序沒有問題，出現問題的概率非常低），錯誤後自己需要有一些機製進行重試，總之不會因為某一個遠程沒有寫入或者網絡而卡住，導致一些看不懂的錯誤。
與之結合的方法無非是先去嚐試絕對一致性，如果成功當然最好，失敗的話，就采用最終一致性來完成，最大程度上保證絕對一致性，各別數據由一個小的後台線程完成異步同步，這樣這個小的後台異步程序壓力也會降低很多，關於一致性的細節概念還有很多很多，這裏就不再屢了，不然越屢越亂。
五、跨數據庫序列問題
跨了數據庫，序列就有問題，不論是MySQL的索引還是Oracle的序列都會有問題，當然對於MySQL自動增長列，你可以在裏頭設置增長值來控製多個庫之間的相同表不會被交叉，這也算是一種方法；不過如果是Oracle就不是很好辦了，因為都是序列，此時這種序列應當建立統一的公共服務，類似於序列，也就是是全局唯一的，那麼這個服務體係就是需要一個公共來源，我們先假設是一個數據庫的表來存儲這些內容。
那麼這個公共服務的壓力將會非常大，對程序來說也是不可信任的，而由於你為了保證鎖，也就是每個時候隻有一個請求能拿到序列號，那麼不得不做的事情就是做一些update操作或內存直接鎖掉，那麼這就出現了嚴重的係統瓶頸，也就是係統訪問上升時，這個地方自然就上去了。
OK，那麼我們如何來解決這種問題，首先，通過UPDATE table SET NUM=?+100 WHERE NUM = ? AND ID=?；這條SQL語句，在一個瞬間隻有一個線程可以被執行成功，也就是多個主機之間隻會有一個得到最新的序號，其餘的SQL執行返回的影響行數都是0（因為前麵哪前一個執行完以後，NUM已經被修改，所以其餘的都不會得到修改），隻有這個是1，所以它此時得到它的線程會得到當前的NUM和NUM+100的值，那麼它自己在這個範圍內去循環分配編號，在Java中為了保證一致性可以使用AtomicInteger相關的變量來執行incrementAndGet操作活得最新的數據，保證一致性，注意這裏雖然可能會造成序列的浪費，也就是數據庫中的序列跳躍，但是數據庫本身也是存在這些現象的，對於海量數據，我們不用糾結這些細節。
從上麵的理論提出，你應該看到如果請求過大，這裏雖然做了100的增長，在並發量極高的時候，也是會出現問題的，為了降低壓力，我們想用兩個序列，但是又想保證一致性，沒辦法嗎？不是，辦法稍微變通下，就是每個序列每次增長200，然後兩個序列交叉100偏移量，如：A序列、B序列，應用按照某種規則分別負載到A或者B，A從0開始，B從100開始，A第一次取的時候，A被變成200，但是獲取到A的應用隻能使用A0-100之間的數據，也就是A當前值 ~ A當前值 + 偏移量；同理B也是這樣，兩者不重複，但是也可以負載壓力，去做操作的時候基本都是行級鎖，所以A和B的壓力自然被分開了。
序列的問題就先說到這裏，有問題再說。
六、不同應用的本地緩存問題
很多係統，為了讓自己的係統跑得快一點，就初始化的時候加載一些爛七八糟的數據，首先，這個東西不要亂用，尤其是再java語言中，不要用其他所有語言的緩存思想來理解java的所有，雖然你可能測試效果是要好一些，但是可能你的測試沒有出現過什麼大GC或者大緩存，如果現場的數據並不適合這樣做，要有辦法能扯開，否則java的緩存就會成為一個累贅。
同時，這種緩存當跨越到分布式，多個係統之間，當對緩存進行修改時，其他的節點都得不到相應，此時需要定時同步、客戶端指定目標去刷新等等方法去做，但是都是很挫的，而且這樣做本身就不合適，除非你隻是緩存一點點小數據，應用本身也不存在很大的並發量。
我們考慮的是在分布式的環境下應當采用分布式的緩存機製來完成這些工作，分布式緩存，我們非常注明就是MemCached，其實它本身是獨立部署的，也就是將緩存部分和應用部分獨立開了，由於它操作的獨立性，所以在網絡層麵可以認為是分布式的，不過談及到真正的分布式緩存還是有很多台機器組成的緩存集群組，這裏的分解規則就很像數據庫了，不過最大的區別就是數據庫全部都是基於持久化的，緩存默認情況下是使用內存，當然也有可以支持持久化的。
此時通信緩存可能會本地基於路由規則去獲取，或者直接通過某個中間件統一獲取。
七、係統之間的直接依賴和間接依賴問題
係統做多了，依賴關係越來越複雜，相互之間調用越來越看不懂，越來越趨向於網絡，不過網絡還可以通過單純的訪問來統計，但是係統就很困難了，一個係統動了可能一串係統出現問題，尤其是數據庫修改一個表可能導致一片係統不能運行，在這種情況下依賴關係分析非常重要，我們要做修改前發現這是有影響的，或者影響誰的，要統計之間的依賴，沒有太好的辦法，要麼看源碼（這個是土辦法，適合代碼量少，但是係統多了不可能代碼量少），係統和係統之間的依賴，可以通過類似agent去跟蹤代碼之間的調用，包含了上述的各種RMI、RPC、HTTP等調用方法；其次對數據庫的調用需要分析SQL或一些日誌信息。
OK，上麵這個步驟其實看了已經比較有難度了，主要是實施起來有難度，但是在必要情況下也得做，那麼更有難度的是間接依賴，最終你可能會遞歸死在裏頭，因為一旦間接依賴引發了，這種相互之間的依賴將會無窮無盡，這種信息的分析和搜集必須是準確的或者說是非常精確的，否則不如不做。
這算是在一個數百個係統的相互調用中，必然存在的問題，因為代碼每天在變化，會麵臨各種問題的挑戰，變更是必然的，而且是快速的，所以依賴很重要。
八、獨立模塊麵臨的單點問題
上麵有提及到緩存、統一序列的問題，這些服務雖然是一些小動作，但是當外部請求越來越多的時候，那麼就不是一個服務可以搞定的了，那麼此時他們也會麵臨單點問題，一旦他們出現問題，如果調用方沒有任何容錯處理，那麼就會導致大麵積的宕機，這是我們不想看到的，在解決模塊單點問題上我們有一些常見的手段：
方法1：通過集群負載均衡來解決，一般我不願意看到這樣，因為這樣投入的成本會更多，這種服務模式更多是比較集中式的大型服務中心。
方法2：一主一備，服務中的信息，日誌之間是通信的，當前主宕機後，備機馬上啟動服務，備份機器平時可以用來做其他的工作，隻需要簡單監控目標是否還活著，當負載較高的時候開始。
方法3：管理者模式，也就是類似於企業，有老總、有各種副總、還有部門老大，還有員工；觀察者負責去協調資源，進行分配，應用方先從觀察者哪裏拿到可以到那些機器上去拿數據，那些機器上可以拿什麼數據，他們有沒有主備關係以及狀態，並緩存在本地，應用方去嚐試拿他們的數據，當失敗後，可以采取兩種策略，一種是觀察者察覺到一個切換，將配置信息改掉，應用重新獲取配置信息或由觀察者統一推送給應用方；另一種模式就是由應用方自己去完成主備之間的嚐試，除非全部失敗，否則下次就用當前嚐試成功的哪一個。兩者不能說誰好誰壞，各自有自己的場景。
九、各類批量分組、切換、擴展的問題
在應用、數據庫、主機很多的時候，我們操作任何動作都會操作類似的動作，所以我們開始想要有批量這些動作，其實和應用係統中批量操作最大的區別就是應用係統基本是做一個update操作，可以通過數據庫本身的一致性來完成，但是如果類似這樣批量切換和分組落實到實際中，有可能會發生中途失敗，就沒有失敗回滾的那麼簡單了。
這種分組呢，我們還比較好說，可以通過統一的綁定，將某些目標節點綁定為一個業務層次中，方便做擴展；
切換就是在同一個分組下做批量的切換動作，能不能完全成功不好說，因為策略不同，但是要保證切換的動作和最終的反饋要保持一致，批量隻是提供一個平台，不過能不能完全自動化未必能保證，但是需要的是自動化的重試，提醒和容錯等處理。
擴展的問題就是當業務發展過程中，主機性能或磁盤容量等已經無法滿足需求了，還有就是現在中國式的熱點式訪問（因為中國喜歡瞎起哄看熱鬧，所以有啥新鮮事、新鮮人、活動什麼的自然就成為），付：還有一類是瞬間高峰，這類解決方案比較特殊，需要很多預熱過程，否則什麼係統也扛不住，因為各類cache和係統內部各種資源都是臨時分配的，而違背了係統本身的局部化原理，要讓他局部化需要提前對這個係統提前預熱和做相應的特殊處理才可以；
在這些情況下，我們需要擴展了，應用擴展比較方便，更多的壓力排到了負載均衡設備上，數據庫的擴展就不一樣了，涉及到曆史數據的遷移，因為擴展後就需要新的數據規則，我們一般在這些層麵上，可能是因為熱點數據，可能是因為容量，可能是因為壓力，他們需要去擴展，如果使用時間點來記錄兩套規則的切換點，這個倒是一種貌似簡單的方法，但是這個實施起來倒是存在很多的問題，而且對於容量不夠的情況，始終還是需要遷移數據，所以這個時候需要後台做全量和增量的結合遷移，業務還在運行並寫入，全量遷移中，記錄增量log，最後通過log開始做增量，如果是完全遷移，最後就將原來數據truncate，如果不是，就看遷移規則是否是分區信息，是分區也可以truncate掉分區，如果不是，就隻有用最慢的delete了，很恐怖，係統此時壓力可能會上來，做delete的同時由於兩遍都已經有了數據，所以就可以將規則進行切換，中間可能有那麼很少量的數據會出現問題，不過這些數據幾乎瞬間就可以搞定。
關於熱點偏向，一般局部化處理它，或者說要麼不要因為他影響一大堆的內容，或者不要因為其他的內容影響它，所以我們可以獨立他們，偏向處理除了本身的規則外，還需要更多的信息來處理他們，因為獨立後，索引可能對他們就沒有任何效果了，那個表可能絕大部分內容都是他，要查詢更多的業務信息可以通過自定義的業務規範來定義。
10、統一監控和恢複問題
最後，一個大型，好的分布式係統，需要有完善的監控體係，包含對應用係統各種性能指標、數據庫的各種性能指標、網絡、穩定性，健康狀況，等做出實時監控，並且對某些關鍵性數據進行實時統計運算。
這類監控係統目前還沒有什麼太好的開源軟件，因為這類大型分布式沒有多少公司有，有的公司也是通過多年積澱下來的，不會一次性透露出來，因為這裏的監控會涉及到多個方麵，一般不是一個軟件就可以搞定的問題，在大的公司內部，這些軟件由於管理的內容非常龐大，而且也要求實時，所以可能會導致本身也會出現性能問題，也可能需要集群來運算，不過這不是關鍵，關鍵的是需要用它來做什麼。
最後，係統出現問題，怎麼恢複，除了應用上的負載均衡，數據庫級別的主備切換，還涉及到更多的災難性恢複，也就是數據丟失或者錯誤如何恢複的問題，並且是在線恢複，對於災難性恢複，更多的大家會選擇一種跨地區備份的策略，而在線恢複就要更多考驗一些經驗信息了。
更多的監控粒度是可以根據鍵控製預知未來的某些信息，根據趨勢圖預測未來的內容，按照一些數學模型建立起自動化的餘量統計和預算工作，其次，就是對問題的發生具有預先判定的能力，也就是根據性能趨勢圖，提前預知機器可能會發生問題；
對於恢複更高的境界也是如此，當監控自動化的完成預知的時候，那麼恢複也希望絕大部分是可以被自動化的，因為主機成千萬上萬的時候人為很難管理，再說人需要睡覺，所以運維的朋友經常睡不著，但是很多恢複的工作，我們可以抽象出百分之八十以上的經驗出來是具有很多共性的，要相信，生在IT行業，要做得更好，就首先要為自己鋪路，共性的東西我們基本都是可以通過軟件來實現的，因為軟件本身就是為了解決重複和簡單，這些內容一旦被自動化（注意，這和人工智能還是有很大區別的，人工智能講究各種模型來模擬人理方法，這裏是自動通過計算機來解決我們的簡單和重複，讓我們做更加有意義的事情），資源的動態調配工作很多由計算機去完成，那麼這就逐步邁向我們所謂的雲了。
OK，本文先介紹到這裏！
最後更新：2017-04-02 06:52:06