[[145060]]

服務(wù)公共化也算是一種標(biāo)準(zhǔn)化，它是線上的技術(shù)架構(gòu)標(biāo)準(zhǔn)化。

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

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

　　備注：這是一個通用的互聯(lián)網(wǎng)技術(shù)架構(gòu)，不做詳述。　　

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

　　備注：我在統(tǒng)計學(xué)的角度也做了一個解釋，組件越多，每個組件的維護能力下降，帶來的可用性必然是很低，由此多組件構(gòu)建的技術(shù)架構(gòu)可用性是一個乘積效應(yīng)。在失控組件數(shù)量N大于可控組件數(shù)量M的情況下，前者的可用性必然是低于后者的?！　?/p>

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

#p#

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

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

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

　　備注：

　　【公共架構(gòu)團隊】，必須要有一個公共架構(gòu)團隊，不過這個公共架構(gòu)團隊，適當(dāng)?shù)男枰{入業(yè)務(wù)研發(fā)團隊的成員，避免需求偏離。

　　【強有力的領(lǐng)導(dǎo)】，沒有強有力的領(lǐng)導(dǎo)，這套技術(shù)標(biāo)準(zhǔn)很難推行。

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

　　【一致的方向理解】，大家需要形成一致的方向理解能力，認(rèn)同統(tǒng)一的目標(biāo)和方向。這個一致的理解不僅僅是在研發(fā)和運維之間，甚至是研發(fā)團隊之間。

　　【持續(xù)的目標(biāo)認(rèn)同及滾動】，不可避免在切換的過程中或多或少會出現(xiàn)一點問題，前提是我們必須做好灰度控制。過程中出現(xiàn)的問題，不應(yīng)該成為阻礙，我們需要承認(rèn)這種臨時的不完美，然后持續(xù)向前滾動?！　?/p>

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

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