為什么要做標準化？

標準化的過程實際上就是對運維對象的識別和建模過程。形成統一的對象模型后，各方在統一的認識下展開有效協作，然后針對不同的運維對象，再抽取出它們所對應的運維場景，接下來才是運維場景的自動化實現。

這有點像我們學的面向對象編程的思想，其實我們就是需要遵循這樣一個思路，我們面對的就是一個個實體和邏輯運維對象。

在標準化的過程中，先識別出各個運維對象，然后我們日常做的所有運維工作，都應該是針對這些對象的運維。如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清楚對象，運維自然不得章法。

比如我們說擴容，那就要先確定這里到底是服務器的擴容，還是應用的擴容，還是其它對象的擴容。你會發現，對象不同，擴容這個場景所實施的動作是完全不一樣的。

如果把服務器的擴容套用到應用的擴容上去，必然會導致流程錯亂。同時對于對象理解上的不一致，也會徒增無謂的溝通成本，造成效率低下。自然地，這種情況下的運維自動化不但不能提升效率，還會越自動越混亂。

這就是為什么我每次都會連續強調三遍“標準先行”的原因。雖然這個事情比較枯燥和繁瑣，但是于紛繁復雜中抽象出標準規范的東西，是我們后續一系列自動化和穩定性保障的基礎。萬丈高樓平地起，所以請你一定不要忽略這個工作。

好，總結一下標準化的套路：

• 第一步，識別對象；
• 第二步，識別對象屬性；
• 第三步，識別對象關系；
• 第四步，識別對象場景。

接下來我們就按照上面這個思路，一起來分析從基礎設施層面和應用層面應該識別出哪些運維對象。

基礎設施層面的標準化

基礎設施層面的運維對象應該不難識別，因為都是一個個物理存在的實體，我們可以進行如下分析。

• 第一步，識別實體對象，主要有服務器、網絡、IDC、機柜、存儲、配件等。
• 第二步，識別對象的屬性，比如服務器就會有 SN 序列號、IP 地址、廠商、硬件配置（如 CPU、內存、硬盤、網卡、PCIE、BIOS）、維保信息等；網絡設備如交換機也會有廠商、型號、帶寬等信息。
• 第三步，識別對象之間的關聯關系，比如服務器所在的機柜，虛擬機所在的宿主機、機柜所在 IDC 等簡單關系；復雜一點就會有核心交換機、匯聚交換機、接入交換機以及機柜和服務器之間的級聯關系等，這些相對復雜一些，也就是我們常說的網絡拓撲關系。

把以上信息梳理清楚，通過 ER 建模工具進行數據建模，再將以上的信息固化到 DB 中，一個資源層面的信息管理平臺就基本成型了。

以服務器為例簡單展示一下，我們的視角就是下面這樣的：

但是，信息固化不是目的，也沒有價值，只有信息動態流轉起來才有價值。接下來我們需要做的事情，就是識別出針對運維對象所實施的日常運維操作有哪些，也就是識別出運維場景是什么。

• 第四步，還是以服務器為例，我們針對服務器的日常操作有采購、入庫、安裝、配置、上線、下線、維修等等。另外，可能還會有可視化和查詢的場景，如拓撲關系的可視化和動態展示，交換機與服務器之間的級聯關系、狀態（正常 or 故障）的展示等，這樣可以很直觀地關注到資源節點的狀態。

完成了這些工作，接下來才是對上述運維場景的自動化開發。所以你看，在真正執行去做工具和自動化平臺之前，其實是需要先做好大量的基礎準備工作的。我要再次強調這一點，一定不能忽視。

應用層面的標準化

下面我們再一起看一個邏輯上的對象，就是我們前面經常提到的運維的核心：應用。對這個邏輯對象的建模會相對復雜一些，不過我們依然可以按照上面的套路來。

• 第一步，識別對象。

我們前面講過，這個識別過程是在做微服務架構設計或拆分的時候就確定下來的。所以嚴格地講，它不應該是運維階段才被識別出來的，而是在之前設計階段就被識別和確認下來，然后延伸到運維這里才對。

• 第二步，識別對象屬性。

一個應用是業務的抽象邏輯，所以會有業務和運維兩個維度的屬性。業務屬性在業務架構時確定，這主要是需要業務架構師去識別的，但是它的運維屬性就應該由運維來識別了。

下面我們一起來看一下，一個應用應該具備哪些基本的運維屬性。

* 應用的元數據屬性，也就是簡單直接地描述一個應用的信息，如應用名、應用 Owner、所屬業務、是否核心鏈路應用以及應用功能說明等，這里的關鍵是應用名；

* 應用代碼屬性，主要是編程語言及版本（決定了后續的構建方式），GitLab 地址；

* 應用部署模式，涉及到基礎軟件包，如語言包 Java、C++、Go 等；容器如 Tomcat、JBoss 等；

* 應用目錄信息，如運維腳本目錄、日志目錄、應用包目錄、臨時目錄等；

* 應用運行腳本，如啟停腳本、健康監測腳本；

* 應用運行時的參數配置，如運行端口、Java 的 JVM 參數 GC 方式、新生代、老生代、永生代的堆內存大小配置等。

從應用屬性的視角，應該是下面這樣一個視圖（簡單示例，不完整）：

• 第三步，識別對象關系。

也就是應用與外部的關系，概括起來有三大類：

第一類是應用與基礎設施的關系，包括應用與資源、應用與 VIP、應用與 DNS 等等的關系；

第二類是平行層面的應用與應用之間的關系，這里再細分下去就是應用服務或 API 與其它應用服務和 API 的依賴關系。如果你有相關的經驗，應該會聯想到全鏈路這樣的工具平臺了，沒錯，這樣的平臺就是用來處理應用間關系管理的。

第三類是應用與各類基礎組件之間的關系，比如應用與緩存，應用與消息、應用與 DB 等等之間的關系。

• 第四步，識別應用的運維場景。

這個就會比較多了，比如應用創建、持續集成、持續發布、擴容、縮容、監控等；再復雜點的比如容量評估、壓測、限流降級等。

好，這里我們先收一下，聚焦到標準化的層面，通過基礎設施和應用層面標準化的示例，我想你應該可以掌握基本的建模思路了，這樣的思路可以應用到其它的運維對象上 。

同時，通過上面這些內容，你應該可以比較清晰地看到，我們的每一個運維操作都是針對某個運維對象的，這一點在規劃運維體系時非常重要。

而在這些對象中，應用又是重中之重，是微服務架構下的核心運維對象。

從應用標準化的過程中我們也可以看到，針對應用的識別和建模，明顯復雜很多。所以，后面我還會從理論和實踐的角度來繼續強化和分析這個概念。

今天，我繼續跟你聊基礎架構標準化的問題，但是今天我計劃不談如何進行架構標準化的細節，而是想強調一下基礎架構標準化的重要性，因為從我個人的經歷和我實際觀察到的情況來看，這塊的問題會更普遍一些，而這一部分又影響著后續一系列效率和穩定性平臺的建設方案。

同時，如果說上次我們講的基礎設施和應用標準化是運維團隊職責的話，那今天的內容就是架構、開發和運維共同的職責。

常見的分布式基礎架構組件

讓我們先一起列一下，微服務的分布式架構下，涉及到的主要基礎架構組件有哪些。

• 分布式服務化框架?，業界開源產品比如Dubbo、Spring Cloud這樣的框架；

• 分布式緩存及框架?，業界如Redis、Memcache，框架如Codis和Redis Cluster；

• 數據庫及分布式數據庫框架?，這兩者是密不可分的，數據庫如MySQL，MariaDB等，中間件如淘寶TDDL（現在叫DRDS）、Sharding-JDBC等。當前非常火熱的TiDB，就直接實現了分布式數據庫的功能，不再額外選擇中間件框架；

• 分布式的消息中間件?，業界如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等；

• 前端接入層部分?，如四層負載LVS，七層負載Nginx或Apache，再比如硬件負載F5等。

上面是幾類主要的基礎架構組件，為了便于理解我以開源產品舉例。但在實際場景中，很多公司為了滿足業務上的個性化需求，會自己研發一些基礎組件，比如服務化框架、消息中間件等，這個情況在有一定技術實力的公司里比較常見。不過大部分情況下，我們會基于這些開源產品做一些封裝或局部的改造，以適應我們的業務。

基礎架構組件的選型問題

關于基礎架構組件，業界可供我們選擇的解決方案和產品是非常多的，但是選擇多了就容易挑花眼，反而不知道從何入手。我們大概都會遇到同樣的問題，是自研還是選擇開源產品？有這么多的開源產品到底該選哪一個？

按正常的思路，一定是先組織選型調研，然后進行方案驗證和對比，最后確認統一的解決方案。

但是，由于開源產品的便利性，以及開發同學對技術探索的好奇心，實際情況往往是，整個大的技術團隊中，不同的開發團隊，甚至不同的開發人員，會根據開發的需要或個人喜好，選擇不同的開源產品，在沒有嚴格限制的情況下，甚至會嘗試去自研。

按照我的觀察，?這個問題特別容易出現在微服務架構引入初?期。在這個階段，團隊組織架構按照業務領域進行切分，產生一個個與業務架構匹配的小規模技術團隊。每個小團隊所負責的業務相對獨立，自主權就會變大，如果這個時候整個團隊中沒有一個強有力的架構師角色去做端到端的約束，就極其容易出現上面的這個問題，并且會一直擴散蔓延下去。

相比之下，成規模的大公司在這一點上做得就相對嚴格一些，當然也可能是因為之前嘗過苦頭，所以后來變得越來越規范了。所以這一點也是每個技術團隊在引入微服務架構時要提前關注的。

我們以分布式服務化框架為例，我之前遇到的一個實際情況就是，整個大的技術團隊選型時以Java技術棧為主，畢竟這塊有很多的業界經驗和產品可以借鑒參考。但是有的團隊對PHP特別精通熟悉，就想用PHP去做微服務，有的團隊對Go感興趣，就想嘗試Go的微服務。

從單純的技術選型上來看，選擇什么語言并沒有嚴格的標準。而且在技術團隊中，我們也應該鼓勵技術多樣性和嘗試新技術。不過這里要有個度，我暫時先不細說這個度在哪里，我們先來看看，假設沒有統一標準的約束會帶來什么問題。

技術的應用，一般都會隨著應用場景的逐步深入和業務體量的增長，逐步暴露出各種各樣的問題，我們分兩個層面來看。

總結

以上是生活随笔為你收集整理的运维体系框架标准化模型简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。