1、一些數據
電商的業務復雜度,可以通過些數據來說明。單一個很明顯的例子,2009年左有,當時商品詳情系統的PV才1億左有,到了2016年已經近50億了,翻了50倍。而當時的系統架構和現在的架構完全不可同日而語。
2.系統規模的復雜度
一個復雜網站的系統架構一般會經歷如下的演變過程。
(1)單系統。早期業務簡單,定,每天晚上都需要把系統重新啟動下。 單系統階段也可分成兩段:最早是花50 幾臺機器就支撐了一個業務系統。剛開始系統不穩萬元買的一個PHP系統;隨著業務的發展,系統逐步改造成了Java技術體系, 名字叫Denali。
(2)分布式業務系統。到了2007年,團隊已經有了上千人,項目支撐面臨巨大的挑戰,系統架構必須升級進化。這就開啟了第二個階段:分布式業務系統階段。我們開始做分布式戰略,把原來的單系統拆分成多個高內聚、 低耦合的中心化系統。現在大家耳熟能詳的用戶中心、商品中心、交易中心、店鋪中心都是這個階段出現的。這同時也意味著把上千人的團隊拆分成了業務相對比較集中的小團隊。每個獨立的系統可以獨立設計、獨立接需求、獨立發布,整個研發效率和系統穩定性都上了一個臺階。
(3)業務平臺。電商發展的速度實在太快了,到了2011年,隨著各種B2C網站、各種導購網站的出現,可能會把一個大型網站從組織架構上拆成幾個獨立的事業部。多個獨立事業部的業務決策鏈路更短、業務發展更快,技術人員也快速增長。事業部的定位不一樣、業務發展方向不一樣、業務的管控規則不一-樣,甚至在一-些業務規則上 還可能相互沖突。
我們都知道,在做業務系統的時候,為了快速應對每天的業務需求變更,很多時候都是通過代碼來寫業務邏輯的,而在業務抽象建模,系統架構的開放性方面都很不成熟這會導致業務邏輯之間的耦合 和相互影響,大幅降低研發效率。系統架構必須升級,這就開啟了第三個階段:業務中心平臺化階段。什么是平臺?就是要把基礎能力和每個業務方的特性業務拆分,隔離業務和業務之間的邏輯。比如說兩個相似的業務方業務有可能是沖突的,但他們需要在同一個平臺上執行,這時我們必須把業務的邏輯分開。這個階段開始升級會員平臺、商品平臺、交易平臺等等。平臺化最核心要點的是業務抽象建模和系統架構的開放性:業務抽象解決80%的共性問題,系統架構開放性解決20%的個性化問題。
(4)業務中臺。隨著生態的復雜度、業務的復雜度、系統復雜度的升級,又遇到了新的問題。領域的平臺化雖然解決了領域內部的問題,但是每一個業務的執行都是跨領域的,涉及會員、商品、交易、營銷、店鋪、評價、支付、物流、售后等等.....一套業務邏輯橫跨幾十個系統。比如一件衣服的商 品發布規則、交易規則和營銷規則均分散在不同的系統中,而且相互關聯,時間一長就沒有人能說清全局了。如果程序員通過翻查代碼還原出所有的邏輯,代價極大。事態發展到后來,我們會發現評估需求的成本可能會大于實際開發的成本,而真正有效的工作占比很少,導致整個研發效率和業務響應速度都比較差。這已經不是單純的技術問題了,而是復雜生態的協作問題。這時,我們開啟了第四個階段:業務中臺化階段。此階段主要解決信息獲取成本高、互聯互通成本高、服務具有不確定性和低水平重復建設這四個問題。
那么,如何來解決這些問題呢,我們可以了解下傳統的建 筑行業和互聯網本身的基礎設施建設,基本上都要靠三樣東西來共同解決復雜生態的協作問題:
協議標準、運行機制。
滿足標準的分布式執行單元。
中心化的控制單元。
比如移動互聯網,我們現在之所以上網能用手機,它的根本是什么呢?網絡的協議,也就是我們對網絡的理解,它是基石。在這個前提下,我們的各種設備,不管是什么品牌的手機,只要滿足3G協議、4G協議,就可以插卡上網。也就是這張SIM卡確定了我們的身份,從運營商控制網絡上獲取了控制信息,它知道我們是誰,能不能上網,網絡速率等等信息。再回頭來看我們的電商生態,就是要根據我們對商業的理解,把一些基礎協議梳理出來。例如什么是業務?什么是業務身份?各個業務領域的邊界是什么?每個領域提供的基礎服務是什么?領域服務和領域服務之間的流程鏈接標準是什么?之后,再在這些思想的指導下建立業務平臺化的實施標準和業務管控標準。因此,電商業務中臺是一套由業務能力標準、運行機制、業務分析方法論,配置管理和執行系統以及運營服務團隊構成的體系,能夠給各業務方提供快速,低成本創新的能力。
(5)構建基礎平臺。從業務開發角度來看,中臺主要是為了提升業務的開發效率,此處的開發效率主要是指個人協作的效率。如果換成從機器維護的角度來看分工協作,那么技術要解決的無非就是數據、算法和計算三方面的問題。
數據。哪些數據有效,哪些數據重復,數據該放在哪個數據中心;
計算資源如何利用。平時大部分機器的負載都比較低,如何有效利用這個計算資源,在高峰和低谷都能充分發揮它的作用;,計算和數限的協作。計算和數據是香放在一 起?如果不放在一起,遷移數據就要考慮帶寬問題,會增加新的成本變量;,計算性價比的評估,依賴于算法。
數據、計算資源和好算法才能構建出優秀的基礎設施,在此基礎上才能給上層業務提供更好、更穩定的基礎,所以搭建高效的基礎平臺是非常重要的。
3.組織管理的復雜度
其實復雜的問題都不是技術上的,往往是人和組織上的,所以如何提升人和組織的效能就比較關鍵了。
(1)呼喚全能工程師。在幾十個人維護一個單系統的情況下,決定效率的就是這幾十名工程師的技能水平,每個人的效率往往就決定了整體的效率。這種情況下Superman能發揮很大的作用。
(2)呼喚系統架構師。當一個團隊達到上千人時,單系統肯定搞不定了,必須要構建分布式系統了,工程師必須要分工了。這個階段最容易從業務開發團隊中誕生中間件團隊,他們專「]解決系統之間的連接問題。這個時期也會誕生一批能力比較強的系統架構師,他們決定系統該如何設計以保持高可用、高性能和高擴展性。從組織建設上,整個團隊會按照技術分工的維度進行細化拆分,如:
產生架構團隊即系統架構師,對整體的系統架構進行規劃, 保障總體設計的高可用、高性能和高擴展性;
產生業務開發團隊即業務開發工程師,專注實現業務邏輯的開發;
產生中間件團隊,專注開發和維護系統中一些通用技術組件,為業務開發提供支持,提升開發效率;
產生UED團隊,解決界面交互問題;。產生測試團隊,保障開發的可用性問題。
(3)業務平臺團隊誕生。當團隊達到幾千人時,光靠技術角色分T已經無法解決問題時,就必須開始平臺化建設,也就是業務架構師要發揮作用的時候了。公司的每個業務領域必須進行平臺化建設,如電商業務中進行商品平臺、交易平臺、營銷平臺、會員平臺的拆分。這些拆分后的平臺再為上層業務提供基礎的服務,便于上層業務進行更多元化的組合。在這個階段組建業務平臺團隊是最合適不過的了,這樣可以解決公共基礎業務的集中管控問題,避免基礎服務的重復和無序建設。
(4)業務中臺組織誕生。當公司規模達到幾萬人時,一般公司都會采取多個垂直化事業部的組織形式,每個事業部-般都是全編制的技術團隊,這其實也是重復造輪子最嚴重的時期。但是,一些基礎的業務能基于業務平臺中的service構建業務嗎?其實也很難!因為人員一旦增多,再靠人與人之間的信息傳遞已經不可能有效運轉了。例如你甚至很難知道公司當前到底提供哪些服務了,因為如果沒有機制保障服務的注冊和發現的話,它的獲取成本會非常之高。此階段影響效率的主要就是信息獲取成本、互聯互通成本和違約成本。
當公司達到上萬人甚至幾萬人規模時,必然存在以下兩種情況。后中管第一,沒有一個平臺型的業務部門,例如公共業務平臺、中間件、基礎技術平臺。在這種情況下,各垂直業務部必然會建設各自的平臺,產生大量重復建設,導致某些技術基礎設施和業務基礎服務不統一,甚至公司的技術棧都不一致,嚴重影響公司的效率和長遠發展。
第二,有一個平臺型的業務部門,但是也會出現各種問題。
不知道誰有什么樣的服務能力、由誰提供支持、服務質量如何,團隊信用度如何;
找到了有能力的團隊,但BU目標不一致,不一定會獲得支持;
溝通不暢、對同一個名稱的理解各異(“多國語言”),需要“翻譯”;支持的質量與個體能力有差異,具有不確定性;
系統間協同難:同一個需求需要在多個系統中實現,相互連接需要定制,導致成本高;
后續支持不可控:開始支持,后續不支持了,沒有顯性違約成本;。支持方即便做得好也沒有可度量的標準,缺乏長遠的動力。
顯然第種情況我們是不提倡的, 無法持續發展;但是第種情況也會存在各種問題,這些問題也正是構建深圳網站建設業務中臺需要解決的問題。
本文地址:http://m.murenxiang.com.cn//article/4464.html