微服務和組織該如何搭配？

　　在設計系統技術架構的時候，我會思考，這個技術架構能給企業或者市場帶來什麼價值，技術架構能像其餘產品那樣賣錢嗎？我也常常會聽到相似於「這個架構很牛X」，「這個架構很先進」以及「這個架構能抗萬級併發」這樣的評價，再回到市場角度想一想，這個「牛X」或者「先進」有哪一個老闆真正願意買單？「能頂住千萬級併發」是否是每一個企業的核心需求？多年的工做經驗告訴我：絕地有，且不在少數。

 

　　多年下來吧，找上門的客戶不少都是十萬火急地想找一個牛X、先進和穩定的技術架構，有一些並非什麼互聯網公司或科技企業，但他們的信息化建設問題已經嚴重影響了企業的核心業務，甚至這個問題已經上升到了他們企業最頂層的緊急事務。緣由並非他們沒有技術團隊作支撐，而是由於他們使用了所謂「牛X且先進」的技術架構，而被迫讓「技術架構」成爲企業當前的「核心需求」。

 

　　 「我據說微服務架構很先進，大家公司正好有這樣一個研發框架，並且還有千萬級用戶和上萬級併發量支撐的案例驗證過了，可否賣給咱們」。我很能理解他們的困境，但曹老闆說過：「作人要真誠和藹良」。因此，我很誠懇地表達了簡單地買套代碼是沒有什麼效果的，甚至還有可能變本加厲，最終用很差，砸壞的但是我本身的招牌。

 

　　這些領導或企業管理者對微服務架構的渴望無非就是對提升企業競爭力利益最大化的渴望。處於這樣一個信息化時代，就算企業沒有「互聯網」或「科技」字眼，但他們始終都離不開信息化建設這個基石，由於信息數據化的優點太大了。因此，從市場角度看，一個好的技術架構真正能給企業帶來的核心價值是「增效降本」。再結合前面的問題，「牛X」和「先進」是否是等同於「增效降本」？這個問題留給你們去踐行思考了。有的企業聲稱本身使用了大型互聯網公司級別的技術架構，但到頭來成本卻愈來愈高。據我對他們的瞭解，緣由不少，但最爲突出和迫切的，仍是他們缺乏一個與之匹配的技術組織架構，這是他們沒能真正「牛X」起來的直接緣由。

 

　　做爲一個「增效將本」的企業內部組織，首先，最基本要確保的是給企業所帶來的價值必須大於自身組織的投入成本，這也應該是技術員工最基本的價值觀念。但能真正遇到具有這種價值觀的技術人員很少，他們更多地是埋頭對「牛X技術」的追求，忘記了技術的本質。其實，這個現象跟目前的行業狀態有關，那些什麼「青春飯」、「35歲危機論」等迫使他們必須在短期內賺取足夠的金錢，而IT行業最能賺錢的手段就是跳槽，而跳槽最容易漲身價的就是保持本身擁有「牛X」的技術。因此他們內心不會想太多如何幫助本身當前所在的這個企業能賺多少錢，更可能是藉助在這個企業的短暫時光練練本身牛X的技術技能。因此不少應聘者都會問「大家公司用的是什麼技術」而不是問「大家是如何經過技術手段去幫助公司增效降本」。以上所描述的技術人員不限於技術高管，因此企業很難有一個穩健且可持續發展的技術架構以及組織規範。

 

　　仗着互聯網趨勢，技術組織不少時候都自覺得是「大爺」級別的，但技術組織自己是一種成本投資，技術組織存在價值的公式很簡單：技術價值=爲企業總體利益的增效-自身技術組織的成本。技術能增效，主要仍是根據企業價值鏈結合業務架構和技術架構的搭配去提升企業自身的市場競爭力，因此如今不少企業會有業務架構師一說。而技術組織的成本控制不在於本身使用了多牛X的技術，仍是那句老話：要發展，先自知，沒有最好，只有最合適，作人作企業亦是如此。

 

　　以本身所在公司爲例，從2011年5月我還沒正式畢業就進入公司接手技術管理以來，一切都是從零開始。隨着移動互聯網的發展趨勢，迫使咱們必須進行架構改造，從2014年開始咱們進入「服務化V1.0」模式，也就是咱們如今微服務架構的前身。這些技術發展史都能從我之前的文字中找到，但對於咱們自身組織的描述得很少，但技術架構自己不會獨立存在，跟組織架構仍是有很密切相關，因此，我以爲仍是有必要介紹一下。這僅僅只是一個經驗分享，並不表明咱們就是成功的榜樣或標準。

 

● 技術員工

　　從上圖的技術與組織架構對比能夠知道，組織技術員工比如技術的物理服務器，都是架構的基建，一個員工的品質比如服務器的質量，並非說有了上層對基礎資源的統一管理，淡化了每個獨立個體的重要性就不表明不須要好的員工或服務器了。固然，好的東西都貴，但性價比高的仍是值得不斷去追求的。

 

● 技術部門

　　技術部門比如LaaS，是對全部獨立個體的統一管理和協調，最對資源效能最大化的手段。部門有企業級別的實踐方針和指南，結合企業的目標定製了一套最適合本身的組織與技術管理辦法，這些規章制度並不是一成不變，是站在企業的角度跟隨市場不斷去完善和修正的。因此，組織並不是一成不變，既然技術與架構是相互的，那麼技術架構的穩健、靈活、易擴展等特性應該一樣要應用於組織架構。

 

● 研發小組

　　研發小組跟PaaS同樣，是技術組織效能的「加速器」，增長了上層的業務或應用的靈活性和增長快速適應市場的能力。咱們研發小組的貢獻主要集中在兩個層面。一方面是不斷完善和提升本身組織的內部效能，主要體如今咱們當前自主研發的「統一工做臺」，這個統一工做臺主要是結合咱們各類職能流程和軟件工具（如SVN，Docker等）打造的一個統一規範工做流平臺。另外一方面是不斷經過業務驅動積累咱們研發的業務產品（如咱們「微服務應用中臺」的服務沉澱），爲企業增效，提升市場競爭力。

 

● 職能小組

　　咱們部門的人員架構是一個「矩陣型」架構，橫向爲技術職能小組，縱向爲以項目經理帶領的項目小組（下面會介紹）。按職能維度，整個部門劃分爲項目經理組、需求組、UIUE組、前端組、後端組，測試組、實施維護組等職能小組。有點相似於微服務架構裏面的服務同樣，分工合做，獨立部署獨立運行。職能小組內部會根據規模而進一步細分小小組。這些小小組會隨企業發展而又有可能歸類爲事業線小小組或業務領域小小組。組員到組長一層層向上按本身領域範圍的技術規範和項目質量負責。

 

● 項目小組

　　項目小組是咱們「矩陣型」架構的縱向劃分維度，由各職能小組成員組成，由項目經理以業務爲統籌和主導。在縱向維度，職能會存在一個「項目職能負責人」，確保本身的職能價值在項目中最大化體現。哪怕項目再小，職能只需分配一我的或半我的，而那我的就默認充當了這個「項目職能負責人」的角色。就像微服務架構同樣，有了咱們「微服務應用中臺」的支撐，頂層的應用場景能夠更加靈活、高效、快速地實現。咱們的項目小組在職能小組明確分工的基礎上，一樣也能靈活、高效、快速組件出打造頂層應用場景的項目團隊。

 

　　看到這裏，可能有人會有疑問，咱們只是一個小企業，那有這麼多人。其實問這個問題的人，等同於問「微服務是否只能適用於大型系統」的問題同樣。我在《小型系統如何「微服務」開發》中也作過介紹，微服務是一種方法，適用於任何應用和項目，跟項目規模沒有關係，哪怕我目前只有一臺物理服務器，或者我只有一個技術人員，都徹底能按照咱們以上的「技術與組織結構」方式去運行和操做。要明確一點的是：方法跟規模沒有關係。當今在技術圈比較流行的一個詞叫作「DEVOPS」，其實就是一種「降本」手段。咱們的組織架構是跟人數沒有關係的，更可能是咱們的管理辦法，由於作事情須要頂層方法去引導咱們更好地執行。就算咱們技術組織只有我一我的，也不妨礙我屬於研發人員，同時又兼容前端、後端、測試、實施、維護的職能，以及做爲項目經理主導本身去開發項目。

 

　　方法還只是屬於「虛幻」層面的東西，具體仍是要考本身的實踐去驗證和發展，就算我說得多牛X，若是不親自去體會、感覺和總結，咱們持續實踐了千萬級用戶數應用平臺近10年的時間，以及咱們所開發的應用系統足足比別人下降數倍乃至數十倍的時間和金錢成本，都不關大家的事，這是咱們每一個同事經過汗水和努力所換來的成效。但咱們的不足還不少，沒事，時間還很漫長，一步步主動去學習、改變和完善就是了。