在前面《有了CMDB，為什麼還要應用配置管理》一文中，描述了CMDB和應用配置管理的關係，這裡面提到了非常核心的一個概念：應用，。但是，上篇中更多的是從運維的角度看待這兩個概念，不過從根源本質上，這個應該是分散式架構中的核心概念才對，只不過是我們在運維過程中整天要面對它，管理它，所以貌似感覺好像這個概念只跟運維相關一樣，其實不然，本文詳細描述下。

關於服務化

在講釋出系統《XXOps實踐：持續釋出和部署》的時候提及過，隨著業務體量和業務複雜度的上升，單體工程因為緊耦合的原因，會慢慢地無法滿足快速迭代的要求，特別是開發人員增加到一定規模的時候，程式碼的開發和維護變得非常頭疼，這個時候必然要對單體工程進行拆分，也就是我們常說的服務化拆分的過程。

以Java為例，我們根據業務模型拆分出不同職責的模組或工程（可獨立執行的一套程式碼），叫做一個應用，在應用裡我們會設計很多類出來，其中對外提供業務功能邏輯的類，我們通常定義為服務，也就是我們常見到的xxxxService，這個Service裡面我們又可以提供很多的具體呼叫方法出來，我們叫做API或者Method。大致的邏輯可以用下圖表示：

比如電商裡面的商品Item，最典型的就會有SKU、Detail、Snapshot、Tag等等的服務，以SKU為例，我們定義為SKUService，做過服務設計和開發的同學肯定都很清楚，接下來我們就要為SKUService提供各種get、list、query、update等方法，有時候為了提供統一的查詢或寫服務，可能還會專門設計出SKUReadSevice提供統一的各種的query方法。

以應用為核心的運維體系建設

這裡面Item就是一個應用的定義，所以我們可以從這裡看到，從源頭上講，應用這個標示是在引入服務化，進行架構拆分的時候就應該定義下來的。

但從我個人實際觀察到的情況看，大部分的公司在這塊的統籌設計上是不夠的，我經常看到的場景是，RPC的服務註冊或配置中心上，有自己的一套應用名標示，開發要獨立去填寫；做釋出系統的時候，又單獨搞出一套應用標示，開發又要填一遍；同理，做監控的時候，監控自己也整一套，到了運維這裡，為了維護資源的分配，為了應用跟資源的對應關係，搞不好也會有一套。有時候為了保持各個系統能夠很好的協作，又得搞出一個對映關係來，比如運維的應用標示跟監控的應用標示做個對應，或者跟服務化的應用標示做個對應，但是這樣做就很難形成統一的體系。所以，我看到的很多平臺就都會變成一個個的孤島，無法成為體系。

所以，在這塊的建設上，必須在服務化階段就得明確應用標示的統一，後續的資源分配、釋出、監控、穩定性體系等等，都以此標示為準。這塊我們CMDB的文章中已經提到了基於應用為核心，如何去建立CMDB和應用配置的模型，下面直接上圖，說明從運維的角度如何去建立應用服務和穩定性體系的模型。

對於服務化的應用：

1、首先是應用，這個要根據產品業務場景去設計。然後拆分出對應的服務，也就是Service這一層，服務裡面再設計出對外暴露的方法。這個過程，主要是業務技術架構師和開發Owner要去做。但是應用的標準，要麼架構師一開始就能夠全域性確認下來，否則，運維就必須參與進去跟開發一起明確指定下來。

所以這裡的路徑就是，應用—服務Service—方法Method

2、基於應用，有了CMDB、應用配置，以及服務的管理，就可以去完成類似於持續整合和釋出、自動化擴縮容這些動作了，具體可以結合《XXOps實踐：持續釋出和部署》

3、有了應用服務管理，接下來可以做的另外一件事情，就是穩定性體系的建設，比如全鏈路跟蹤、容量評估、開關、限流、降級等等。這塊後面專門整幾篇文章出來。這裡特別要說明的一點，所有上面提到的這些技術手段，準確的講，都應該要加幾個定語，就是基於應用的xxxx，或者基於服務的xxx。比如，降級策略，就以Cache故障，自動降級到DB為例，最終這降級策略是要通過配置的方式，下發到應用或服務層面來執行的，具體可以看下上述圖示。

最後，有了這樣一套基於應用的模型之後，就可以通過應用把這些管理環節給整合起來，放在統一的門戶裡提供出來，至此，應用為核心的運維體系雛形就有了。簡單的示例：

關於微服務和服務化，多說兩句：

前兩天跟公司一個開發Leader還在探討是否有必要拆分微服務的問題，這裡也分享一下，服務化和微服務的的爭議主要是個粒度問題，我們在設計時到底是把應用拆分成粗粒度的一組服務形成一個應用，比如上面提到的Item商品，形成一個單獨應用，還是將更細粒度的Service獨立成一個個的應用，比如上面提到的Item裡面的SKUService這個服務，還是再微服務化一點，甚至可以SKU這個服務裡面的讀寫服務，SKUReadSevrvice和SKUWriteService分別獨立出來分別獨立出來作為一個應用。

這個說實話沒有什麼嚴格標準，橫著切也好，豎著切也罷，粒度大也好，粒度小也好，關鍵還是看這個應用和服務的Owner怎麼來把握，或者團隊有統一的架構師來定義標準。

不過，個人觀點，對於微服務還是持一點保守態度，不要做過細粒度的拆分，也並不是越細越好，這裡面有個度的問題。粒度過細就會有大量的應用獨立出來，應用之間又會有相互呼叫，應用的管理和呼叫鏈管理就變的異常的複雜，最終意味著管理成本就會非常高。這個時候是需要有非常完善的運維體系來保障的，比如持續整合和釋出、全鏈路保障、容量和效能評估手段等等，而這些保障體系說實話有一定的技術門檻，也需要一定的技術和人才積累，需要有一個迭代的週期來完善，這必然是一個逐步演進的過程，所以這些配套手段跟不上的情況下，過度的微服務化是沒有意義的。

文章來自微信公眾號：Forrst隨想錄