- 企業中臺,成就智慧品牌
- 百勝智庫
- 4187字
- 2020-04-10 11:57:43
3.1.3 技術中臺
不管是業務中臺還是數據中臺,都離不開技術架構的支持。脫離了技術,所有我們談的業務與數據能力都無從實現。
3.1.3.1 技術演進路線
在談技術中臺時,我們不妨先來看一下技術架構的演進路線。
隨著互聯網業務的發展,應用的規模不斷擴大,常規的企業級垂直應用架構已無法應對,服務式的應用架構以及分布式服務框架勢在必行,用戶亟須一個治理系統確保架構有條不紊地演進。
從企業架構演變路線來看主要有單一應用架構、垂直應用架構、服務式應用架構和分布式服務架構,目前基本演進到第四階段,當然國外已經開始研究第五階段,但是分布式服務框架還有很長的生命周期。

架構演變路線
第一階段:單一應用架構

單一應用架構模式
當使用量不大時,只需一個應用,就可將所有功能都部署在一起,以減少部署節點和成本。此時,用于簡化增刪改查工作量的數據訪問框架(ORM)是關鍵。這是企業為了增加效益而開發的應用,這種架構下沒有做任何拆分,應用系統很臃腫,維護和版本升級開銷非常之大,一旦出問題就是整體的崩潰。但其實現在有很多企業應用系統仍然停留在第一階段。
第二階段:垂直應用架構
當訪問量逐漸增大,單一應用增加機器帶來的加速度越來越小,將應用拆成互不相干的幾個應用,以提升效率。此時,用于加速前端頁面開發的Web框架(MVC)是關鍵。
隨著企業運維的復雜性的提高,WEB容器、B/S結構出現,企業給予部門或業務開發了許多垂直應用,采用了一些除數據庫之外的中間件技術。
在這個階段很多企業是把應用服務和數據完全隔離,對企業來說有了一定的能力去增加吞吐量。這些垂直應用提升了企業效率,加強了企業管理。但是,各應用中存在重復的業務功能和代碼,甚至在一個應用中也會存在冗余的代碼邏輯,應用系統依然很臃腫,業務邏輯處理和界面交互的代碼還是堆放在一起,維護和版本升級開銷都很大,穩定性不夠理想。
這是企業架構的第二個階段——垂直應用架構。

垂直應用架構模式
但是當垂直應用越來越多,應用之間交互不可避免,這個時候企業面臨著進行業務融合,數據打通的問題,因此催生了面向服務架構(SOA),用以解決企業應用、業務調整和數據共享的問題。服務式應用架構階段將核心業務抽取出來作為獨立的可以復用的服務,使前端應用能更快速地響應多變的市場需求。
但是各應用中存在許多重復的業務功能和代碼,甚至在一個應用中也會存在冗余的代碼邏輯,應用系統很臃腫,業務邏輯處理和界面交互的代碼放在一起,在信息化的維護和版本的升級層面開銷都很大,穩定性不夠理想。
第三階段:服務式應用架構

服務式應用架構圖
當垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來作為獨立的可以復用的服務,使前端應用能更快速地響應多變的市場需求。此時RPC技術是關鍵。
在服務式應用框架中,把冗余的代碼和可以服用的業務應用進行拆分提取,封裝成服務。這樣系統架構更加清晰,代碼質量提高,利于升級和維護,穩定性高。應用層可以更專注在與前端用戶如何交互,業務處理放在服務層來進行,服務和應用的管理不是自動化,服務層能夠實現HA的功能。
但是,在服務式應用的階段,仍然存在實施過程只站在局部業務,單個項目角度考慮的問題,缺乏全局思維,業務系統之間更多的是交換,而缺乏共享和協同。
第四階段:分布式應用架構
第四階段能夠監控原來看不到的服務狀態,把分布式服務架構做到自動化注冊和解析的過程當中。在這個過程中,企業橫向擴展變得越來越靈活,這也是很多互聯網公司在高峰期能支撐那么多訂單量的原因。

分布式服務架構
當服務越來越多,容量的評估,小服務資源的浪費問題逐漸展現,此時需要增加一個調度中心基于訪問壓力實時管理集群容量,提高集群利用率。此時,用于提高設施利用率的資源調度和治理中心(SOA)是關鍵。基于服務式應用架構基礎上,引入服務注冊中心,用于保存服務列表,實現自動化服務體系框架。
分布式服務架構的優勢:
首先,分布式架構,應用層和服務層可根據需求進行動態水平擴展,應用與服務實現負載均衡,通過隨機、輪詢、權重等策略。
其次,開放式、標準化的框架,滿足接口調用的服務都可以接入服務框架(RPC)。
最后,監控服務調用情況,可進一步對服務層再分層,根據業務需求和對服務運行情況對服務進行編排和梳理,以及服務治理。
3.1.3.2 技術中臺架構支撐
我們看到,隨著互聯網業務的發展,應用的規模不斷擴大,常規的企業級垂直應用架構已經無法應對,服務式的應用架構以及分布式服務框架勢在必行,用戶亟須一個治理系統確保架構有條不紊地演進。企業必然走向互聯網的分布式服務和架構,而這套架構已經在多個行業中遍地開花,這是互聯網技術的紅利在慢慢向企業賦能的表現。
分布式服務架構解決的核心問題就是服務調用,未來企業新增加一項業務或服務,通過整個服務中心可以很好地對外發布,調用者可以迅速地完成相應的調用,整個過程變得非常敏捷。這也是為什么很多互聯網公司能夠快速地適應業務的變化,能夠做敏捷的交互的原因,因為拆分得很細。如果哪一個服務出現不好的問題,可以做服務的升降級,可以做平滑的切換,系統應用整體感受會有很大提升。
通過分布式架構,一方面是在解決業務支撐能力的問題,另一方面,實現真正地去中心化系統實現系統的彈性,降低耦合性,突破系統“瓶頸”,提升靈活性,以便使業務能夠不受技術能力的約束實現快速創新,從而形成“技術拓展商業邊界”的能力。
數據中臺要求可以對數據進行海量的數據化運算,海量的數據化處理和分析,對于傳統的系統架構來說,很難滿足海量的采集、計算、存儲等一系列的大數據操作。另外,在數據的基礎上,還需要對數據進行數據模型、算法服務、數據產品、數據管理。這些數據跟業務中臺具有很強的關聯性。所以為了滿足數據中臺的實時、在線、高效地數據化處理和運營分析,對于技術架構提出了分布式、高并發等大數據的處理要求。
所以說,技術中臺是能力支撐。通過分布式服務架構來實現,解決傳統煙囪式的問題。在中臺設計的過程中,技術是核心的一環。而我們現在談的中臺,在技術能力上,有著異于傳統的改變。
這種改變在技術中臺上還表現為技術架構要超前于現有業務。業務布局在現時變化太快,但系統不能實時跟隨變化。從技術架構上要支持中臺的業務沉淀和服務復用,實現前臺業務的快速組合和低成本創新。
3.1.3.3 技術中臺能力
以百勝軟件的企業中臺為例,我們可以看到,百勝軟件的中臺技術架構可以分為四層:資源層、公共服務層、應用層和用戶訪問層。聚焦于公共服務層來看,將開源的、基礎的能力封裝成核心技術層;在技術層之上是與行業無關的核心業務,因為每個行業都會有訂單、庫存、營銷等業務,封裝起來形成核心業務層;在業務層之上還有一些服務,我們給它賦予行業的屬性,形成了行業層服務,針對鞋服、珠寶、日化等行業都有相關的服務。這樣的分層體系相對來說比較清晰,具備較強的專業度,同時能夠聚焦不同行業。
百勝軟件中臺技術架構為了滿足業務發展還具備以下特性:

分布式服務響應模式
分布式服務架構:當服務越來越多,容量的評估,服務資源的浪費等問題逐漸顯現,此時需增加一個調度中心基于訪問壓力實時管理集群容量,提高集群利用率。此時,用于提高設施利用率的資源調度和治理中心(SOA)是關鍵。
基于服務式應用架構基礎上,引入服務注冊中心,用于保存服務列表;實現自動化服務體系框架。
分布式架構,應用層和服務層可根據需求進行動態水平擴展,應用與服務實現負載均衡,通過隨機、輪詢、權重等策略。
開放式、標準化的框架,滿足接口調用的服務都可以接入服務框架(RPC)。
監控服務調用情況,可進一步對服務層再分層,根據業務需求和對服務運行情況對服務進行編排和梳理,以及服務治理。
分布式服務管理:通過分布式服務管理,統一了RPC調用框架,從技術上讓開發人員提升開發效率,保障我們的開發質量。

分布式服務管理
服務監控管理:有了自動化的服務治理之后,就可以對服務進行有效的監控,這樣很容易發現哪些服務是存在并發壓力的,哪些服務會容易產生故障,哪些服務可能耗時比較長,存在系統“瓶頸”。更深入地,我們可以把服務監控到在哪個時間段,針對哪個物理區域的服務器。到最后我們還可以針對某一個單臺服務,監控它的整體資源的情況。

服務監控管理
異步解耦:同時我們還利用互聯網的技術去解決平常業務中的一些痛點。傳統軟件有一個很大的痛點是業務操作都是同步的,同步之后容易形成堵塞,往往容易形成系統的崩潰,我們通過基于MQ的消息機制,把同步的機制解耦變成異步機制,保障在電商活動期間,當海量訂單紅利來的時候,可以緩沖訂單紅利,避免系統崩潰。

異步解耦
一對多,多對多異步解耦:基于發布訂閱模型,分布式應用異步解耦,可以增加應用的水平擴展性,增加前端應用快速客戶反應能力。
削峰場景:大促等流量洪流突然來襲時,MQ可以緩沖突發流量,避免整個系統崩潰。
日志監控:作為重要日志的監控通信管道,將應用日志監控對系統性能影響降到最低。
數據緩存:我們通過像Redis這樣的緩存機制減少數據庫的壓力,通過內存計算提高計算效率,我們還可以通過MQ消息機制實現事務補償,同時我們通過一些集群技術去增加系統健壯性。這里有一個很經典的場景,即大促活動(例如“雙11”)這時候有海量的訂單進入,而大量的訂單處理都要去訪問數據庫庫存這張表,要進行頻繁的訪問并交互,數據庫的壓力是顯而易見的,很容易導致數據庫壓力傳導到系統上,導致系統卡頓,變得特別慢或者崩潰,而像“雙11”時期系統卡頓對業務造成的傷害是很大的。現在如果品牌幾百萬訂單可能還可以接受,但是到千萬訂單的時候,現在的機制肯定解決不了,就需要這種新的機制,所以未來只有這樣一種數據緩存的機制能解決這個痛點。

數據緩存
庫存緩存:通過緩存減少數據庫讀寫壓力,通過內存計算提高計算效率。
消息推送:MQ異步處理數據庫庫存增量變更,實現事務補償,解決數據一致性問題。
集群部署:緩存集群部署,和數據庫讀寫分離;增加系統健壯性。
數據庫水平拆分:單表的業務容量到千萬級或者更高的時候,就需要對表進行拆分,因為單表已經支撐不了,整個訪問會導致它的數據衰減很快。現在有一些工具能幫我們進行這樣的水平拆分,當然具體拆分還要跟我們的業務規則結合。

數據庫水平拆分
技術開放共享:對于企業中臺來說,由于涉及面廣,百勝軟件的中臺技術未來是能給其合作伙伴開放共享的,通過這樣一個體系,未來能夠跟品牌、平臺與合作伙伴共享,一起推動中臺發展,發揮各自的力量,不斷優化完善企業中臺。

E3+技術開放共享平臺