[[145060]]

服務公共化也算是一種標準化，它是線上的技術架構標準化。

　　之前有一篇講了運維標準化是運維的基礎，更是運維自動化的基礎。但我覺得高效運維的關鍵是第二階段---架構服務化更是關鍵，此項工作的深入推動需要運維和研發強力配合，這種配合不僅僅是技術和執行層面上的配合，有時候還需要一些部門文化和目標層面上的配合。為了強力推進這部分的工作，有時候甚至需要運維自己組建公共服務的研發團隊。在小的IT企業中，大家對這塊的認識應該不會太深刻，到一個中等規模(比如說多個產品線、服務器千臺規模以上等等)，此時更需要架構的公共能力服務化來形成技術架構的標準化，從而解決IT服務的效率和運維問題。有時候，你可以把這個服務化理解成PAAS平臺化的一部分。　

　　備注：相同服務的多組件會導致服務質量下降，組件引入的越多，對研發、測試和運維的要求越高，很難找到這種多組件能力的維護團隊；業務的敏捷性要求越來越高，傳遞給后端技術服務能力也要越來越敏捷，這個時候只能公共化服務能力才能滿足這一要求，把這種服務能力變成一種自服務的能力，變成一種api的能力；運維管理必須以可運維性為目標，把技術架構中的公共服務能力打造到極致，比如說mysql、cache、文件存儲的服務等等。

　　備注：這是一個通用的互聯網技術架構，不做詳述。　　

　　備注：在通用架構中，架構中的點和線如果選型不當或者技術把控不足，就會帶來以上的技術失控(Out Of Control)。對于每一層的技術架構來說，我們組件選型會泛濫，其實這種泛濫許多時候都是基于團隊或者個人的偏好來進行的，而不是真正的合理評估。在一個完全沒有接維的IT組織中，這種情況更是比比皆是，所以說有時候還是需要中心化的管理。一個離散式的組織中，必然會打來混亂和選型失控的情況。這個地方要注意線的失控，所謂線的失控就是服務間調用的失控，有些是通過lvs、有些是通過dns、有些是通過配置文件等等，如果有可能完成統一的標準制定，比如說我現在在UC用的就是名字服務中心。

　　備注：我在統計學的角度也做了一個解釋，組件越多，每個組件的維護能力下降，帶來的可用性必然是很低，由此多組件構建的技術架構可用性是一個乘積效應。在失控組件數量N大于可控組件數量M的情況下，前者的可用性必然是低于后者的。　　

　　備注：公共服務化也有標準的實現路徑可循，對于一個不復雜的業務來說，其實基本上可以按照1.識別--》2.抽象--》3.選型--》4.實現--》5.接入推廣幾個階段來完成。其中關鍵是第四步實現，這個地方就需要一個很強有力的技術實現小組來完成，肯定會出現的一種情況是，初步實現沒法滿足所有業務的需求，甚至是有些業務的需求根本就沒有預估到，那么需要技術實現小組，邊接入邊優化。這次我們在把MC切到內部的分布式cache服務上就遇到了這類問題，只能在接入過程中，快速實現。這也是公共服務化的一個好處，研發能力的快速支持，當作一個產品來做。　

#p#

　　備注：核心能力是【可運維性】，可以分解到不同維度上【服務透明】【可管理性】與【自服務】。【服務透明】是提供一種內在的容錯機制、去狀態的位置透明服務能力；【可管理性】，需要把運維的核心場景可視化實現，比如說數據遷移、cache擴縮容等等；【自服務】是想把這種服務能力提供給所有人，甚至給周邊的一些業務系統，供其api直接調用。　　

　　備注：在來UC的一年多時間里，基本上把技術架構中公共需求都統一切到公共服務平臺上。目前這些平臺對某個運維人的依賴越來越低。在非運維主導的這塊，還有服務間調用解耦用到的【飛鴿系統】與統一消息推送系統【飛雁系統】。在技術架構里面，我們正在和研發推動統一的業務灰度發布系統、統一服務降級系統、語音實時消息公共平臺。

　　備注：以上兩個圖，是我們的統一分布式cache服務---浮云，用來替換memcache，傳統的memcache散落在各個業務的服務器上，完全的組件化能力，需要每個人掌握memcache的運維能力，切換到統一的浮云后，一切運維能力可視化，在線管理變更、在線狀態查詢、在線統計的分析等等。最關鍵的是，這套技術架構更考慮可運維性的要求，比如說容災容錯等等，甚至是跨機房之間的cache數據同步都在這層解決。　　

　　備注：

　　【公共架構團隊】，必須要有一個公共架構團隊，不過這個公共架構團隊，適當的需要納入業務研發團隊的成員，避免需求偏離。

　　【強有力的領導】，沒有強有力的領導，這套技術標準很難推行。

　　【架構和運維的深度融合】，不管是技術上的融合，還需要在團隊間合作上的融合。

　　【一致的方向理解】，大家需要形成一致的方向理解能力，認同統一的目標和方向。這個一致的理解不僅僅是在研發和運維之間，甚至是研發團隊之間。

　　【持續的目標認同及滾動】，不可避免在切換的過程中或多或少會出現一點問題，前提是我們必須做好灰度控制。過程中出現的問題，不應該成為阻礙，我們需要承認這種臨時的不完美，然后持續向前滾動。　　

　　備注：以前想在九游這邊所有業務推動webP圖片壓縮，碰到一個現實的問題，圖片存儲不集中，沒法要求所有的研發團隊處理。現在我們把所有的圖片能力接管以后，我們做webP圖片的壓縮，完全不依賴業務方的實現，由圖片云統一處理。這是一個公共服務化后，讓IT組織技術成本更低的一個例子。

　　總結：一定要記得避免選型泛濫，這個泛濫后面就需要來打掃戰場，非常痛苦。服務公共化是運維團隊必須邁出去的一步，這一步事關后面的無狀態的技術架構實現。在運維側，基本上現在我們公共服務的維護都只需要一個人負責，大大降低了運維成本。在研發側，他們對運維的需求接口更簡單了，服務更專業化。最終我們想做到的目標是，研發只需要編寫業務邏輯代碼就好了，其他的各個專業服務基于客戶端Library的Api調用即可。