當動態伸縮無法實現時，很多優秀架構就只剩下複雜性了

離開應用場景談技術那就是耍流氓，這也是為什麼針對某個技術或者產品總會有多種截然不同的觀點與看法。經常有朋友給我推送這樣的文章，讓我對孰是孰非發表看法。回答這種問題，我往往都會說大家都對，也都不對。朋友就會說我耍滑頭，兩邊都不想得罪。實際上對於大多數衝突的觀點，我用“也對也不對”這五個字去回答就正確得不能再正確了。凡事不絕對這句話在技術上基本上是到哪都說得通的。

前陣子有人在爭論資料庫是否應該放到容器裡，大家說得都挺有道理的，因為大家都是從各自的應用場景和現狀來談的，所以正反雙方的觀點都很充分。確實有不少使用者把資料庫放到容器裡，用Operator做自動化管理，日常的運維管理不需要了、備份也不需要了、資料庫最佳化更不需要了，最後連DBA都不需要了。這些使用者上了容器後用得很爽，不過也有不少使用者在容器上碰得滿頭是包，資料庫時不時出現卡頓甚至當機，主從複製經常出問題，高可用切換也常常失效。這兩種都是真實的場景和體驗，都是事實，並不一定是哪個水平高用得好，其主要區別在於應用場景、系統規模與開發團隊水平的差異。

與傳統IT基礎設施相比，雲平臺，容器化的IT基礎設施在平臺層面上的複雜度都是超級的，大多數使用者都無法完全掌握，甚至連有效的最佳化與管理都無法勝任。不過如果平臺與上面的應用能夠自洽，那麼這些複雜性都是被遮蔽的，一切都是自動化的，無需人工干預的。這是企業IT夢寐以求的，大型網際網路企業的成功實踐就證明了這一點。讓大型網際網路企業能夠玩轉這種高度自治與彈性的軟體定義資料中心的是網際網路企業超乎尋常的技術能力，以及對自身業務的高質量把控，因此他們可以讓應用系統與雲平臺高度融合，實現完全自治的閉環。

傳統企業在這方面天然存在弱點，首先是業務規範性不好，企業IT對業務的理解也只是在摸索中，因此傳統企業的系統研發是較為缺乏計劃性的，因此業務系統與基礎設施的匹配問題往往無人關注。再加上傳統企業的管理制度把資訊系統管理成一個個相互獨立的煙囪。在業務系統沒有打破煙囪的前提下，單單把IT基礎設施的煙囪拆了，是完全不夠的。

我見過一個企業的IT系統，他們目前強制系統上雲，而且也確實把大量的應用系統改造上雲了。目前應用都採用微服務架構，應用元件完全容器化部署，資料庫也有一部分部署到K8S的容器中了。以前三四臺物理機，十幾個WEBLOGIC例項搞定的系統，現在分拆到部署在數百個POD中的微服務裡了。因為微服務分拆得太細碎，而給這個專案分片的物理資源又有限，因此每個容器配置的資源都很緊張，經常會因為某個微服務的處理能力不足而導致應用出現卡頓現象。當我我問他們為什麼不把微服務設定成動態伸縮的。他們說雲平臺給他們分配的資源是有限的，目前已經完全被他們佔滿，因此無法動態伸縮。問他們為什麼不申請更多的資源，他們說目前雲平臺的資源十分緊張，除非某個系統的CPU總體使用率不超過某個閾值，雲管那邊無法給他們專案分配資源。如果因為讓你的系統動態擴充套件而影響了別的業務部門的系統執行，雲管中心是要擔責的。

這真的是十分滑稽了，微服務，容器化原本是為了享受其動態的優勢，系統上雲後，企業在IT系統的容量與資源管理模式上依然延續原有模式，就讓雲平臺的優勢蕩然無存了。不過雲管中心的人也很無奈，他們的IT預算是固定的，目前雲平臺的擴容資本金與當年沒上雲時候相比是持平的，不過因為小型機不採購了，因此購買到的算力其實是比以前要多很多的，因此他們也無法向企業申請更多的資金用於雲平臺的擴容。不過因為系統建設速度太快，他們的雲平臺資源目前也十分緊張，因此他們雖然可以滿足某個系統的擴容需求，但是必須滿足一些系統資源使用率的閾值才行，否則大家都來申請資源，他們就抓瞎了。

關於上雲後是否省錢的事情是另外一筆糊塗賬，用這種碎片化的管理模式去管理動態的雲，資源使用能變得更有效，這隻能是一句空話了。如果系統的動態伸縮無法實現時，那麼新IT架構就只剩下複雜性了。

這種複雜性讓系統變得愈發脆弱，拆得十分零碎的微服務不僅不能有效的使用雲平臺的融合資源，反而出現了無數的弊端。原本一個複雜的業務流程是在一個WEBLOGIC例項中完成的，模組之間的呼叫成本極低，效率極高。目前拆分成數十個微服務後，完成同樣的模組就需要呼叫數十個介面。前陣子我看過一個系統的最佳化報告，其中一個模組每次執行需要好幾秒鐘，原本以為只要問題在SQL上，後來從ARMS中發現SQL響應並不慢，只有100毫秒左右，每個呼叫在幾十毫秒到幾百毫秒之間，算一下總時間，也差不多幾秒鐘了。想要把這個模組最佳化到非功能性需求要求的2秒鐘之內，還是有一定挑戰性的。

用適當的架構做適當的系統，選擇最簡單的架構來做系統，讓研發專注於業務邏輯。這是IOE時代的主要架構思路，也是IOE成為IOE的關鍵。隨著IT技術的發展，軟體定義概念的流行，目前留下的技術層出不窮。很多企業還沒掌握好一種新技術，更好的，更新的技術就出現了。於是企業IT就從以業務需求出發變成了跟著創新走了，這導致了一種新的不和諧，那就是業務跟著架構走而不是為業務選擇合適的架構了。在這種情況下，一旦系統的複雜度超出了研發與運維人員的能力範圍，那麼系統出問題就是早晚的事情了。

企業應用系統架構的最佳化演進，必然伴隨著企業在IT管理方面制度的變革，以及企業在IT成本投入策略的變化，這樣才能讓系統架構演進獲得有效的保障。實際上大型網際網路企業在這方面做得不錯，而到了傳統企業，一切都變味了。學習網際網路企業先進的技術架構這一點也沒問題，因為這兩年網際網路企業也在大力輸出。但是網際網路企業在管理方面的先進經驗，大家都沒有學到，一方面企業覺得管理是自己的事情，不能照搬，另外一方面是網際網路企業在這方面也沒有什麼油水可撈，因此也教得也不盡心。因此往往我們只獲得了新技術的複雜性，並沒有獲得讓新技術與自己業務更好融合的內功心訣。這樣的學習借鑑，是很難成功的。