讀阿里巴巴中台戰略筆記
上周閱讀了阿里巴巴中台戰略思想與架構實戰一書,獲益良多,尤其是前幾章寫得非常好,現將個人認為的主要思想總結如下,方便大家快速查閱:
1、2015年底,阿里巴巴啟動中台戰略,構建符合DT時代的更具創新性、靈活性的「大中台、小前台」的組織機制和業務機制。中台戰略啟動之前,馬雲等高管曾經到芬蘭supercell遊戲公司參觀,2015年全球top10 app遊戲中該公司佔據大半江山,馬雲對supercell公司所構建的中台能力給予很高的評價,正是由於supercell公司的中台支撐了該公司迭代創新、快速試錯的能力。
2、阿里巴巴目前已經構建了業務中台,實現了服務重用和業務沉澱。對於服務重用:服務重用將比數據重用帶來更多好處,數據是生產資料,服務則包括邏輯,如果加工過程也能復用,講帶來生產效率的大幅度提升。先上一張圖,展示一下當前阿里巴巴的業務中台(共享業務事業部正是業務中台的真實體現):
3、回顧一下,目前很多企業的信息系統建設採用「煙囪式」建設方式,有三大弊端:
1)重複功能建設和維護帶來的重複投資。
2)打通「煙囪式」系統間交互的集成和協作成本高昂。而且很多企業僅僅是實現了多個系統間的介面集成,完全沒有做到SOA架構的核心價值--服務重用。
3)不利於業務的沉澱和持續發展。系統上線後就進入運維相對穩定階段,當新的業務需求出現後,服務提供者團隊可能存在兩種情況:第一種情況是配合不好,可能直接告訴你「我們目前僅能提供這樣的服務」,第二種情況是配合態度不錯,但由於前期設計的通用性和前瞻性不夠,導致改造工作量比較大,這個時候很可能會放棄改造,其結果跟第一種情況完全一樣。完全無法通過服務重用對業務進行持續沉澱和發展。
前兩者是基於成本和效率的角度,第三個則是基於發展的角度,因此第三個對企業的傷害最大。
4、再回顧一下,目前很多企業的信息中心的組織職能往往是業務支持,其核心原因是IT部門的人員不懂業務,無法對業務的下一步發展有著自己的理解和看法。而IT人員不懂業務的根本原因是因為傳統上採用項目制的系統建設模式。項目制的弊端是:
A)從員工層面,員工主要是進行項目管理,對業務的參與及沉澱有限,員工能力提升與工作時間的長短並不是呈線性增長的,無法在某一專業領域得到知識和經驗的沉澱,從而隨著時間的流逝,越來越多的人會慢慢失去最初的工作積極性和創造性;
B)從系統層面,項目制導致當新需求提出時,可能項目組已經解散或者KPI考核已經結束,員工的主觀積極性不夠,如果當初通用性和擴展性設計得不夠好,或者系統穩定的需要,新需求的支撐往往有心無力,從而導致事實上的穩定。
5、企業中台:重點關注業務中台的這幾個點,其他的請親自閱讀原書--服務是最不需要穩定的,服務需要不斷的業務滋養;共享服務體系是培育業務創新的土壤,能夠賦予業務快速創新和試錯能力;改變組織陣型會帶來組織效能的提升;共享服務中心的劃分原則;業務中台與前端應用協作;業務中台績效考核。
A)服務是最不需要穩定的,服務需要不斷的業務滋養。一個固步自封的服務,遲早逼著比它更好的替代服務出現,屆時就是這個服務離開歷史舞台的時刻了。服務只有在業務滋養中才逐漸成為企業寶貴的IT資產,這種業務滋養正是來自新的業務不斷進行服務的接入。
B)傳統上流水線的弊端是對於不同角色人員的技能持續提升是會出現發展瓶頸的,做了3年的開發人員可能跟做了5年的開發人員可能在開發能力上沒有太大的區別,根本原因是這兩年的差別僅僅是用自己熟練的技能多生產出幾個不同的系統。
C)針對這種情況,阿里巴巴從組織形態上進行了調整,如下圖。這樣,小團隊的成員有足夠的時間和機會對該服務相關的業務領域進行更深入的理解,從而為團隊培養出既懂技術,也懂業務的複合型人才創建良好的土壤。
D)共享服務中心的劃分原則:高內聚、低耦合;數據完整性原則(是第一個原則穿透到數據層面的體現);業務可運營性原則;漸進性的建設原則。
E)業務中台的平台穩定性:限流和降級、流量調度、業務開關、容量壓測及評估規劃、全鏈路壓測、業務一致性。
F)業務中台與前端應用協作
- 業務中台對前端核心業務的緊密溝通機制,比如定期參與前端的業務周會
- 建立分歧升級機制,解決有分歧的情況
- 崗位輪轉推動真正換位思考
- 業務持續沉澱及共建模式
G)業務中台績效考核
- 服務穩定是重中之重
- 業務創新推動業務發展
- 服務接入量是衡量服務價值的重要考核
- 客戶滿意度促動服務的提升
6、關於SOA:SOA是一種理念,它的主要特性--面向服務的分散式計算,服務間鬆散耦合,支持服務的封裝,服務註冊和自動發現,以服務契約方式定義服務交互方式。但是,SOA並沒有定義出具體的實現方式,目前有兩套SOA理念的實現方式:中心化和去中心化,這兩套架構並沒有優劣之分,還是要針對企業的根本訴求。
A)ESB模式中心化服務架構的根本訴求:實現異構系統之間的互聯。
B)去中心化分散式服務架構解決的問題:首要解決的問題是系統擴展性的問題。下面這張圖是阿里巴巴分散式服務框架HSF:
地址伺服器:提供部署環境中配置伺服器和Diamond伺服器列表信息。
配置伺服器:服務列表信息,包括服務名稱、介面、權重等。
Diamond伺服器:類似Zookeeper,在HSF框架中主要保存服務管控規則。
服務提供者:一個服務對應一個tomcat、一個虛擬機。
7、關於微服務:微服務架構的典型特徵包括--分散式服務組成的系統,按照業務而不是技術來劃分組織,做有生命的產品而不是項目,智能化服務端點與傻瓜式服務編排,自動化運維,系統容錯,服務快速演化。
A)從本質上說,微服務是SOA的一種演變後的形態,與SOA的方法和原則沒有本質上的差別。
B)隨著容器化技術Docker的盛行,一些文章將微服務和Docker關聯到一起,甚至划上等號,這就有點誤導的嫌疑。從技術角度,Docker完全有能力而且適合微服務體系中給服務提供實際的運行容器以及進行部署運維的平台,但Docker本身提供的核心能力僅僅是計算資源層面,對於微服務架構所需的應用服務層面還存在不小的空缺,而這些空缺不是單單Docker平台能解決的問題。
- 服務管控:在分散式服務體系下,服務鏈路跟蹤、鏈路分析、實時業務指標的監控等問題,也都是實現微服務架構時一定會面臨的問題。
- 分散式事務問題。
- 自動化運維和平台穩定性。
C)微服務不是免費的午餐,帶來好處的同時,也帶來一系列問題,需要一個專業的團隊和平台來保障微服務架構的成功落地。
D)阿里巴巴共享服務體系的實踐,稱得上是微服務架構在大型互聯網公司中的最佳實踐。
推薦閱讀:
※在輿情引導中發揮大數據技術優勢
※大數據計數原理1+0=1這你都不會算(四)No.52
※大數據架構師技能
※大數據計數原理1+0=1這你都不會算(二)No.50
TAG:大數據 |