任何一個大型網站均是根據用戶的積累以及隨之而來的用戶數量增長,從一台服務器到多台服務器逐步架構支撐起最終的大型網站數據、用戶和頁面請求等業務的。任何的大型網站的系統架構並不是一開始設計時就已經完全的考慮了與其業務高度吻合的高性能、高可用、安全等特性的。由於隨着用戶量增加,業務功能一般會逐步細化甚至發生較大的業務方向轉變,所以一般在開發迭代過程中,總會發生大的開發模式、技術架構甚至設計思想的變化。最終,隨着業務穩定的擴展和確定,成熟的系統架構才會出現,並符合其業務特征。例如,同樣是web,淘寶要解決精准的商品信息搜索、下單、支付以及促銷活動時的並發處理;騰訊則首先考慮同一時間完成數億用戶的消息實時精准傳輸;百度則持續高並發處理數億人同時的海量搜索請求。不同的業務,由於側重點不同,系統架構則會有差異。但是也有共性。例如,美國常見的創業案例,一兩台電腦開始服務器,最終發展成現在的谷歌、Facebook等。本文將講述網站服務器從一兩台電腦到集群服務器的一些部署方案演化過程。
1、一台電腦的網站服務器架構
最初的架構就像我們每個人在學習時,將web應用程序、數據庫、靜態文件均部署在同一台服務器(例如個人電腦)上。
2、應用程序、文件、數據庫三者分離
隨着用戶量增加,業務發展,一台服務器無法滿足要求,需要分解壓力。一般此時最常規的做法就是根據功能將相應的模塊放置在不同服務器上——根據模塊功能選擇合適的硬件,然后將應用程序、文件和數據庫三者分離部署在獨立的服務器上來提升性能。
3、利用緩存改善網站性能
除了硬件上的優化,軟件設計肯定也有辦法改善網站服務器性能。我們都知道,訪問靜態頁面要比動態頁面快地多。為什么呢?一般很多動態頁面都需要應用程序服務器去后台數據庫服務器訪問並查詢數據結果,然后根據返回結果調用文件服務器或者自身應用服務器上的模板來生成動態頁面然后返回給瀏覽器或者客戶端。
假如我們將大多數用戶經常訪問的首頁等一些訪問量大但變動小的頁面在動態生成后的頁面緩存在應用程序服務器或者保存為靜態頁面供用戶索取,那數據庫的訪問頻次將大幅下降,網站性能得到提升,用戶體驗得到優化。常見的像微博一般將熱點數據(熱點話題)保存在redis中供用戶快速訪問。
兩種常見的軟件層次改善網站性能方式:
1、利用緩存
2、動態轉靜態
大多數網站設計時,都遵循訪問28原則——80%的訪問請求最終落在20%的數據上。這樣可以減少數據庫查詢操作,提升用戶體驗,改善網站性能。
緩存實現的常見方式有本地緩存、分布式緩存。除此之外還有CDN、反向代理等。
- 本地緩存是指將數據緩存在應用服務器本地的內存或者文件中,它的特點是訪問速度快,缺點是本地空間有限,僅能緩存部分數據。OSCache就是常用的本地緩存組件。
- 分布式緩存是指建立分布式緩存存儲來解決本地空間有限的問題。它可以緩存海量的數據,且易擴展,但速度較本地緩存稍慢。常見的分布式緩存有Memcached、Redis。
4、利用集群改善應用服務器性能——負載均衡服務器
盡管在后台我們分離了不同模塊並部署獨立的服務器,然后采用緩存的措施改善網站性能,但是隨着用戶數量達到一個級別,所有用戶都去訪問同一台應用程序服務器是不現實的,它會崩潰的。那怎么做呢?最直接的想法就是分解用戶的訪問。既然一台不行,我們搞N台來分擔用戶請求——即建立應用程序服務器集群來共同承擔大量請求。那如何有效合適的將用戶請求分擔給不同的應用程序服務器呢,畢竟它們功能都一樣?常見的做法是在應用程序服務器前面(即在用戶請求和應用程序服務器之間)部署一個負載均衡服務器來調度用戶請求,讓它根據分發策略將用戶請求合理的分發到應用程序服務器節點。
常見的負載均衡技術提供有:
- 硬件上:
- F5
- A10
- 深信服等
- 軟件上:
- LVS
- Nginx
- HAProxy等
5、數據庫讀寫分離
進一步隨着用戶數量的增加,數據庫中的數據越來越龐大,網站性能自然而然的瓶頸便是數據庫。我們知道,一般在大多數用戶業務中,數據庫中80%的操作都是在查詢數據——讀數據。那么改善性能的方向就一目了然——將數據庫分離,一些數據庫專門進行讀數據業務,一些數據庫專門進行寫數據業務,然后通過主備功能實現各數據庫同步。
6、數據庫分庫分表
除了數據庫在硬件上的讀寫分離能夠改善web服務器性能外,隨着用戶量的增加,我們也常常采用分庫分表來提高服務器的操作效率。
常見的分庫分表有:
- 水平切分
- 是指對數據庫中的特大表根據一定的方式進行行切分。
- 例如,幾億的用戶信息表如果在一個數據庫中的一個數據表中,如果查詢起來,會非常慢(就算采用數據庫的索引功能——並且它本身就降低了數據的性能)。此時我們可以采用水平切分——根據用戶注冊時間進行水平切分,增加數據表數量,但單個數據表行數減少,可以提高查詢速度。
- 是指對數據庫中的特大表根據一定的方式進行行切分。
- 垂直切分
- 是指根據業務模塊來分別建立數據庫及服務器,根據業務來切換查詢。
- 例如,一個大型電商網站,可以將用戶業務相關的表建立數據庫放在一個數據庫服務器上;訂單業務相關的表建立數據庫放在一個數據庫服務器上;商品業務相關的表建立數據庫放在一個數據庫服務器上。這樣可以實現查詢分離,其他模塊也可以直接調用這些基礎模塊的數據庫。
- 是指根據業務模塊來分別建立數據庫及服務器,根據業務來切換查詢。
7、利用CDN和反向代理提高網站性能
試想一下,如果我們的服務器部署在貴州,對於哈爾濱的用戶來說,要經過很多網關路由轉發才可以獲取信息。而對於貴州本地用戶則很快。那我們的業務在哈爾濱拓展起來會非常困難,畢竟網站體驗太差了。怎么辦呢?常見的方式是CDN和網站自建反向代理。兩者本質上均是在用戶請求到達應用程序服務器之前做一些網絡路徑優化的事情——若有緩存數據則直接返回給用戶,減短網絡請求路徑,降低應用程序服務器訪問頻次。
**CDN:**CDN的全稱是Content Delivery Network,即內容分發網絡。將一些緩存放在運營商的機房,這樣用戶訪問時先從最近的運營商機房獲取數據,若不存在,再訪問我們的web服務器。這種方式可以大大減少網絡訪問路徑,畢竟每個地區的用戶總有一些共性習慣,他們經常訪問的那些內容可以通過CDN緩存在他們所在地區運營商的機房,提高訪問速度。這和本地緩存是一個道理,只不過是寄存到運營商那里。常見的CDN運營商有:網宿、阿里雲、騰訊雲、白山雲、視界雲。這些適合沒有能力在各地建立本地服務器機房的網站。
目前CDN技術按照其側重點可分為穩定派、全能派、性能派等“三大門派”:
穩定派:
CDN服務應保持內容分發的穩定性,在一體化技術、弱網加速技術、服務質量性能波動監測、智能故障診斷等強化技術積累,而非刻意追求最新的功能特效,比如客戶有防盜鏈更新時可以第一時間告知客戶,並降低故障影響,對於賽事、演唱會等直播及短視頻場景中較有吸引力,主要代表廠商是網宿
全能派:
提供直播、點播的端到端的完整解決方案,除了CDN服務以外,還包括域名注冊、網站開發、IDC、雲通信、移動服務、雲安全、監控與管理等綜合化一站式服務,主要代表廠家就是阿里雲、騰訊雲等。
性能派:
即通過自研核心、優化節點選擇和網絡部署,達到提升性能的目標,同時穩定性兼顧
實際上,哪怕網速整體提升0.1秒,就需要在提升核心Cache的響應速度、提升調度系統的響應速度、降低網絡節點的延遲、提升下載速度、縮小網絡節點距離用戶的距離等方面進行研發和投入;而單一環節的性能提升可以滿足直播和短視頻平台對於CDN的苛刻需求,這方面的典型廠商是白山雲、視界雲。
**反向代理:**反向代理則是在自建機房里部署反向代理服務器(網站自身有能力建設本地化服務器機房等同於CDN)。在用戶訪問時,首先訪問反向代理服務器,若請求數據有緩存數據,則直接將緩存數據返回給用戶;若請求數據沒有緩存數據,再去訪問應用程序服務器。這樣既加快了訪問速度,也分擔了應用程序服務器的訪問壓力。常見的反向代理有:Squid、Nginx等。
軟件名稱 性能 功能 過濾規則配置 Squid 不能多核是硬傷;磁盤緩存容量有優勢;性能中等 多;支持ACL角色控制;支持ICP緩存協議 支持外部文件讀取及熱加載;支持熱啟動 Varnish 多核支持;內存緩存;性能強 夠用;支持集群,但不支持ICP集群;支持后端存活檢查 不支持外部文件讀取;需要轉義;支持熱啟動 Nginx 多核支持;支持代理插件;性能較強 多;支持集群,但不支持ICP集群;支持后端存活檢查;通過插件可以充當多角色服務器 不支持外部文件讀取;需要轉義;支持熱啟動 Apache TS 多核支持;磁盤/內存緩存;性能強 夠用;支持后端存活檢查;支持ICP協議,Cluster不穩定;支持插件開發; 支持外部規則文件讀取及熱加載;支持熱啟動 HAProxy 多核支持;無緩存;支持HTTP頭部解析;性能強 少,只專注HTTP頭部解析和轉發功能;支持ACL角色控制;支持后端存活檢查 支持外部規則文件讀取及熱加載;支持熱啟動;支持會話粘滯和長連接
- HTTP防御性能:HAProxy在應對大流量CC攻擊時,做正則匹配及頭部過濾時,CPU消耗只占10%~20%。其它軟件均狂占CPU資源約90%以上,容易成瓶頸導致整個系統無響應。
- 反向代理性能:單純轉發效率以內存緩存型的Varnish性能最強,ATS和Nginx次之,考慮大容量緩存因素,ATS也是個不錯的選擇。Nginx是專門針對C10K的產物,性能不錯,配合自己編寫插件,業務可塑性很強。
- 過濾規則的可配置性:HAProxy,ATS,Squid均支持規則文件讀取、ACL定制和熱加載、熱啟動。Nginx則不支持外部文件正則匹配,略差一點,但可塑性強。
8、使用分布式存儲系統
隨着用戶數量的增加,像微信等這類網站,用戶每天都在發朋友圈,上傳大量的照片,產生的文件越來越多。單台服務器肯定存儲空間不足且性能會崩潰的。那怎么辦呢?思路是一樣的,分解壓力,建立分布式文件系統。常見的分布式文件系統有:FastDFS、HDFS(hadoop)、NFS等。
技術 優點 缺點 總結 HDFS 1、大數據批量讀寫,吞吐量高;2、一次寫入,多次讀取,順序讀寫; 1、交互式應用,低延遲很難滿足;2、不支持多用戶並發寫相同文件。 如果是很多小文件,nameNode壓力大 googleFs 1、成本低,運行在廉價的普通硬件上 1、不開源 不開源,使用困難 Tfs 1、淘寶開源 1、小於1M的文件 2、TFS內部是沒有任何數據的內存緩沖的 適合單個文件比較小的系統 Lustre 1、開源 2、 支持POSIX 3、 文件被分割成若干的Chunk,每個chunk是一般為1MB-4MB Ceph 1、支持POSIX 2、開源 1、 在Linux主流內核中找到ceph 2、不成熟,處於測試推廣階段 MogileFs 1、開源 比FastDFS 差 FastDFS 1、 開源 2、 適合以文件為載體的在線服務3、 FastDFS沒有對文件做分塊存儲4、 不需要二次開發即可直接使用5、 比mogileFS更易維護和使用6、 直接使用socket通信方式,相對於MogileFS的HTTP方式,效率更高。 1、文件訪問方式使用專有API,不支持POSIX swiftfs 基於HDFS NFS 1、用戶和程序可以象訪問本地文件一樣訪問遠端系統上的文件
9、使用搜索引擎和NoSql
此時,我們已解決了用戶上傳的海量文件的存儲。那我們還需要解決海量文件的查詢。如果查詢太慢,朋友圈刷不出來豈不是很尷尬。目前常見的方式是采用NoSql數據庫加上搜索引擎來提高查詢性能。一般將文件存放在分布式存儲系統和服務器,而建立非關系型數據庫來存儲相應的一些路徑等其他信息,然后再使用搜索引擎建立數據庫的本地索引,這樣可以極大的提高文件查詢性能。常見的NoSQL有Mongodb和Redis,搜索引擎有lucene、whoosh等。
關系型數據庫查詢也需要搜索引擎提升查詢性能
10、應用程序服務業務拆分
在第四節,我們通過多個相同的應用程序服務器來分擔請求壓力,這本質上是以硬件換性能的方式。為了提高請求處理效率,我們也可以像數據庫讀寫分離那樣,通過業務拆分來分擔不同的應用請求。例如百度、騰訊將業務拆分為新聞、網頁、圖片、貼吧等,每個業務應用負責相對獨立的業務運作,然后各業務之間可以進行通信或者數據庫共享來實現整體的應用程序服務。
11、搭建分布式服務
除了業務拆分,就像代碼復用一樣,我們也可以將各業務都需要使用的基本業務服務抽取,以供所有應用來使用。這邊是分布式服務。例如網站常見的用戶服務、訂單服務、支付服務、安全服務等服務常常是各業務應用的基本組成,我們便可以抽取搭建分布式服務;阿里的Dubbo分布式服務框架便是這樣。
最后,隨着業務繼續增長,服務器根據各地業務特色,可以基於以上措施建立合適的本地服務器,最終由網站統一協調調度全球的服務器資源實現資源最大化利用。
本文參考了:
在首席架構師手里,應用架構如此設計
在上一章主要從硬件組成上介紹了服務器架構部署,接下來轉載前1號店首席架構師王慶友的一篇博文來講述應用架構的發展。
在首席架構師手里,應用架構如此設計
無架構,不系統,架構是大型系統的關鍵。從形上看,架構是系統的骨架,支撐和鏈接各個部分;從神上看,架構是系統的靈魂,深刻體現業務本質。
架構可細分為業務架構、應用架構、技術架構,業務架構是戰略,應用架構是戰術,技術架構是裝備。其中應用架構承上啟下,一方面承接業務架構的落地,另一方面影響技術選型。
如何針對當前需求,選擇合適的應用架構,如何面向未來,保證架構平滑過渡,這個是軟件開發者,特別是架構師,都需要深入思考的問題。本文基於作者在大型互聯網系統的實踐和思考,和大家一起探討應用架構的選型。
本文主要內容包括:
- 應用架構本質
- 單體式
- 分布式
- SOA架構
- SOA落地方式
- 應用架構進化
應用架構本質
應用作為獨立可部署的單元,為系統划分了明確的邊界,深刻影響系統功能組織、代碼開發、部署和運維等各方面,應用架構定義系統有哪些應用、以及應用之間如何分工和合作。
分有兩種方式,一種是水平分,按照功能處理順序划分應用,比如把系統分為web前端/中間服務/后台任務,這是面向業務深度的划分。另一種是垂直分,按照不同的業務類型划分應用,比如進銷存系統可以划分為三個獨立的應用,這是面向業務廣度的划分。
應用的合反映應用之間如何協作,共同完成復雜的業務case,主要體現在應用之間的通訊機制和數據格式,通訊機制可以是同步調用/異步消息/共享DB訪問等,數據格式可以是文本/XML/JSON/二進制等。
應用的分偏向於業務,反映業務架構,應用的合偏向於技術,影響技術架構。分降低了業務復雜度,系統更有序,合增加了技術復雜度,系統更無序。
應用架構的本質是通過系統拆分,平衡業務和技術復雜性,保證系統形散神不散。
系統采用什么樣的應用架構,受業務復雜性影響,包括企業發展階段和業務特點;同時受技術復雜性影響,包括IT技術發展階段和內部技術人員水平。業務復雜性(包括業務量大)必然帶來技術復雜性,應用架構目標是解決業務復雜性的同時,避免技術太復雜,確保業務架構落地。
常見的應用架構有多種,下面根據系統拆分方式,以及如何平衡業務與技術的角度進行分析,討論各自的適用性,給企業應用架構選型提供參考。
單體式應用
- 架構模型
系統只有一個應用,相應地,代碼放在一個工程里管理;打包成一個應用;部署在一台機器;在一個DB里存儲數據。單體式應用的架構如下圖所示:
單體式應用采用分層架構,按照調用順序,從上到下一般為表示層、業務層、數據訪問層、DB層,表示層負責用戶體驗,業務層負責業務邏輯,數據訪問層負責DB層的數據存取。
單體應用在水平方向上,上下層之間職責划分清晰;但垂直方向上缺乏清晰的邊界,上下層模塊之間是多對多的依賴關系,比如業務模塊1 (圖中BO1)可能調用數據層所有模塊DAO1
3, DAO1也可能被業務層所有模塊BO13調用。單體應用通過水平分層,降低了業務復雜性;同時模塊之間是進程內部調用,技術實現簡單。
但單體應用對系統的切分不徹底,只有水平切分,並且是邏輯上,因此適合業務比較單一,但深度上比較復雜的系統,比如TCP/IP網絡通訊,從應用層/傳輸層/網絡層/鏈路層,層層推進,類似這樣的系統可以方便地增加水平層次去適配。
對於廣度上復雜的業務,由於缺乏垂直切分,強行把不同業務綁定在一起,整個系統神散形不散,帶來一系列問題。比如OTA網站包含機票/酒店/旅游等多個垂直業務板塊,每塊都比較獨立,就不適合放在一起開發維護。
- 優缺點
單體式應用的優點和缺點都很鮮明,如下圖所示。
單體式應用的優點明顯:
- 現有IDE都是集成開發環境,非常適合單體式應用,開發、編譯、調試一站式搞定。 一個應用包含所有功能,容易測試和部署。
- 運行在一個物理節點,環境單一,運行穩定,故障恢復簡單。
單體式應用的缺點也明顯:
- 業務邊界模糊,模塊職責不清晰,當系統逐漸變大,代碼依賴復雜,難以維護。
- 所有人同時在一個工程上開發,容易發生代碼修改沖突,依賴復雜導致項目協調困難,並且局部修改影響不可知,需要全覆蓋測試,需要重新部署,難以支持大團隊並行開發。
- 當系統很大時,編譯和部署耗時。
- 應用水平擴展難,一方面狀態在應用內部管理,無法透明路由;另一方面,不同模塊對資源需求差異大,當業務量增大時,一視同仁地為所有模塊增加機器導致硬件浪費。
作者之前曾在一家大型電商公司工作,當時整個網站是一個單體應用,有數百萬行代碼,有專門的團隊負責代碼合並,有專門的團隊負責編譯腳本開發,有一套復雜的火車模型協調不同團隊,整套流程體系很精密很復雜,但這何嘗不是單體應用的無奈和代價。
分布式架構應用
- 架構模型
在分布式應用架構中,應用相互獨立,每個應用代碼獨立開發,獨立部署,應用通過有限的API接口互相關聯。API接口屬於應用一部分,一般和表示層處於同一層次,兩者共享業務邏輯層,API和表示層采用同樣的web端技術,通訊協議一般使用HTTP,數據格式是JSON,應用集成方式比較簡化。
分布式架構首先對系統按照業務進行垂直切分,對廣度上復雜的業務實現物理解耦,應用內部還是水平切分,對深度上復雜的業務實現邏輯解耦。分布式架構也可以解決業務量大的問題,對於某些高並發/大流量系統,把系統切分為不同應用,針對資源需求特點(比如CPU/IO/存儲密集型),通過加強硬件配置滿足不同應用的需求,避免一刀切方式帶來的資源浪費。
技術上,API采用標准的HTTP/JSON進行通訊,調用雙方實現難度都不大,但是API 一般是“裸奔”的,在系統層面,調用依賴關系不透明,調用可靠性缺乏保障,因此只適用應用之間依賴鏈路少,調用量不大的系統,即應用之間耦合確實夠松的系統。
- 優缺點
分布式架構每個應用內部高內聚,獨立開發、測試和部署,支持開發敏捷;同時應用之間松耦合,業務邊界清晰,業務依賴明確,支持大項目並行開發,實現業務敏捷。
在分布式架構中,應用的表示層和API沒有物理分離,需要同時滿足自身業務需求和關聯業務需求,相互影響,比如API接口會隨着外部應用的需求經常變化,這會導致整個應用重新部署。
運行時,API以HTTP/REST方式通過網絡對外提供接口,其通信可靠性和數據的封裝性相對於進程內調用比較差,如果沒有一些可靠的技術機制,如路由保障/失敗重試/監控等, 裸奔的API方式將嚴重影響系統整體可用性。
SOA架構
- 架構模型
廣義上,SOA也是分布式應用架構一種,但內涵不同。
這里有兩種類型“應用”,應用1
N是前端應用,面向用戶,服務1N是service,只提供業務邏輯和數據。這些應用都是獨立部署,前端應用不再通過API直接關聯,而是通過后端服務共享業務邏輯。此外相對於“裸奔”的API,SOA架構提供配套的服務治理,包括服務注冊、服務路由、服務授權、服務降級、服務監控等等。這些功能通過專門的中間件支持,有中心化和去中心化兩種方式,具體技術實現機制和適用場景,網上有很多專門介紹,這里就不展開了。
SOA架構在分布式架構垂直切分的基礎上,進一步把原來單體應用的業務邏輯層獨立成service,做到物理上的徹底分離。
每個service專注於特定職責,實現系統核心業務邏輯,service之間通過互相調用,可以完成復雜業務邏輯,解決業務深度上的問題;同時service面向眾多的應用,以共享的方式支持邏輯復用。所以,SOA架構既體現業務的分,又體現業務的合,更多地從業務整體上考慮系統拆分。
相比分布式應用架構,基於SOA的系統有大量的service應用,整個系統基於服務調用,所以對服務依賴的透明性和服務調用的可靠性提出很高要求,需要專門的SOA框架支持,還需要配套的監控體系和自動化的運維系統支持,技術復雜性高,SOA架構可以集中體現一個企業的IT技術能力。
- 優缺點
SOA架構優缺點如下圖所示:
相比較普通API方式,SOA架構更進一步:
1)每個service都是濃縮的精華,聚焦某方面核心業務,同時以復用的方式供整個系統共享。 2)服務作為獨立的應用,獨立部署,接口清晰,很容易做自動化測試和部署。 3)服務是無狀態的,很容易做水平擴展;通過容器虛擬化技術,實現故障隔離和資源高效利用,業務量大的時候,加機器即可。 4)基於SOA的系統可以根據服務運行情況,靈活調控服務資源,包括服務上下架、服務升降級等,使系統真正具備可運營的能力。
當然天下沒有免費的午餐,SOA也帶來了額外復雜性和弊端:
1)系統依賴復雜,給開發/測試/部署帶來一系列挑戰。 2)端到端的調用鏈路長,可靠性降低,依賴網絡狀況、服務框架及具體service的質量。 3)分布式數據一致性和分布式事務支持困難,一般通過最終一致性簡化解決。 4)端到端的測試和排障復雜,SOA對運維提出更高要求。
SOA落地方式
在實踐中,SOA架構不斷深入發展,具體落地形式也多種多樣。
1)面向外部SOA
SOA的前身是web service,web service初衷是企業之間通過Internet進行互聯,如下圖所示:
每個公司把自己的優勢資源通過web service發布,如圖中天氣服務/機票服務/酒店預訂服務來自不同公司,其他企業可以直接調用服務或整合多個服務,實現企業間資源共享。
2)面向應用SOA
面向應用SOA把原單體應用里的業務邏輯層剝離出來,作為單獨的服務對外提供。 舉一個電商的例子,這里有兩個應用,顧客使用的商品詳情頁,展示商品的信息、商品庫存,商品價格;內部客服人員使用的客服系統,根據顧客來電要求,修改訂單,同時也需要獲取商品的基本信息、價格信息等。
經過SOA改造后,應用架構如下圖所示:
這里的service實現底層數據對於前端頁面的透明化,表示層和業務邏輯各自獨立維護,同時全部業務邏輯對其他應用開放,新應用可以自由整合來自多個服務的接口,快速支持業務創新。
面向應用的SOA架構對系統進行物理上的水平切分,結果是表示層單飛,邏輯層對外全開放。但每個service是原系統業務邏輯的封裝,接口設計面向原應用的業務case,如果其它應用的需求有差異,則自己創建service訪問底層數據。如此導致service職責不夠聚焦,類似的接口分散化,同時底層數據表被多方訪問,數據模型修改困難,數據一致性難以保障。
最終系統整體依賴復雜,容易形成網狀結構,修改時,往往牽一發動全身。
3)微內核SOA 每個企業都有自己的核心數據,比如對於電商系統來說,用戶/商品/訂單/庫存/價格都是核心數據,稱之為主數據。微內核SOA聚焦各類主數據,封裝相關表的所有訪問,架構示意如下:
每個服務獨占式地封裝對應主數據表的訪問,這些服務構成系統的基礎服務,一起組成系統的微內核,供所有上層應用共享。
微內核服務是原子服務,接口粒度比較細,可以在其上構造聚合服務,為上層應用提供粗粒度服務。可以是信息聚合,比如圖中商品聚合服務整合商品的基本信息/庫存/價格;也可以是流程聚合,比如下單接口,調用來自多個服務的接口,共同完成復雜的下單操作。
這里服務是分層次的,聚合服務是上層,基礎服務是底層,依賴規則如下:
- 上層服務可以調用同層服務和基礎服務
- 基礎服務是原子服務,不可相互調用
- 前端應用可調用聚合服務和跨層調用基礎服務
微內核的微表示服務數量有限,接口粒度細;內核表示這些基礎服務處於調用底層,負責核心數據和業務,這和操作系統的內核概念上類似,主數據相當於核心的硬件,如cpu/內存/外存等,微內核的各個基礎服務分別負責這些核心資源的管理,屏蔽底層的復雜性,對上層應用提供統一入口和透明化訪問。
最近微服務很火,其特征是職責單一、接口粒度細、輕量級通訊協議等,微內核SOA架構有微服務的形,同時有業務內核的神,是架構形散神不散思想的很好體現,這個在淘寶、京東、一號店等大型電商系統都已有豐富實踐。
4)方式比較
面向企業外部SOA,業務場景有特殊性,不深入分析,這里主要比較面向應用SOA和微內核SOA的區別,一個大型B2C電商系統,應用和主數據是多對多依賴關系,如下圖所示:
面向應用的服務從特定應用出發,整合應用對相關數據的訪問需求;微內核服務從特定主數據為中心,收斂各個業務對數據的訪問需求。
在面向應用的服務設計下,數據表的訪問入口是發散的,來自多個應用,這帶來一系列弊端: 1)數據模型碎片化 每個應用都會基於自己的需求,往表里加字段,很多電商的商品表/訂單表有多達200個字段,都是野蠻增長,缺少控制的結果。 2)數據模型修改困難 類似的訪問需求散布在多個服務,缺乏整合,同時表schema修改會影響很多服務和應用。 3)連接資源利用率低 多個服務直連數據庫,並且每個服務會盡可能多地配置連接數,在應用數量多,業務並發量大的情況下,往往導致數據庫連接數不夠。
微內核SOA通過收斂對主數據的訪問,保證數據模型一致性、優化接口和有效利用數據庫連接資源。同時通過服務分層,簡化系統依賴關系。更為重要的是,微內核服務保證了業務模型的一致性,比如電商系統的商品體系,包含單品/系列商品/組合商品/搭售商品/虛擬商品等一系列復雜概念,這些復雜邏輯在基礎商品服務里處理,對上層業務透明一致。
如果業務模式簡單,應用數量少,特定主數據的訪問絕大多數(比如說80%)來自某個應用,則服務設計以應用為中心是可以的,不利影響比較小。
對於大型互聯網系統,業務廣度和深度都復雜,但無論多復雜的系統,主數據類型都是有限的,可以通過聚焦有限的基礎業務,以此支持無限的應用業務,結果是底層業務模型穩定,上層業務可以靈活擴展。
面向應用的服務設計是SOA初級階段,從具體業務着手,自底向上,難度小;微內核服務設計是SOA高級階段,從全局着手,對業務和數據模型高度抽象,自頂向下,難度大。
值得注意的是,在提供基礎服務同時,每個應用也可以創建自己需要的服務(但主數據的訪問必須通過基礎服務),所以微內核的服務和面向應用的服務可以有機結合在一起,當業務應用變得很多,並且不斷增長,可以考慮逐步往基礎服務過渡,整合特定主數據有關的業務邏輯。
順便提一下,應用架構會影響組織架構,如果采用面向應用的服務設計,具體service一般由相關應用的團隊負責;如果是微內核的服務設計,一般由單獨的共享服務部門負責所有基礎服務開發,和各個業務研發部門並列,保證設計的中立性和需求響應的及時性。
應用架構的進化
軟件是人類活動的虛擬,業務架構是生產活動的體現,應用架構是具體分工合作關系的體現。 單體應用類似原始氏族時代,氏族內部有簡單分工,氏族之間沒有聯系;分布式架構類似封建社會,每個家庭自給自足,家庭之間有少量交換關系;SOA架構類似工業時代,企業提供各種成品服務,我為人人,人人為我,相互依賴。微內核的SOA架構類似后工業時代,有些企業聚焦提供水電煤等基礎設施服務,其他企業在之上提供生活服務,依賴有層次。
業務架構是生產力,應用架構是生產關系,技術架構是生產工具。業務架構決定應用架構,應用架構需要適配業務架構,並隨着業務架構不斷進化,同時應用架構依托技術架構最終落地。
企業一開始業務比較簡單,比如進銷存,此時面向內部用戶,提供簡單的信息管理系統(MIS),支持數據增刪改查即可,單體應用可以滿足要求。
隨着業務深入,進銷存每塊業務都變復雜,同時新增客戶關系管理,以更好支持營銷,業務的深度和廣度都增加,這時需要對系統按照業務拆分,變成一個分布式系統。
更進一步,企業轉向互聯網+戰略,拓展在線交易,線上系統和內部系統業務類似,沒必要重做一套,此時把內部系統的邏輯做服務化改造,同時供線上線下系統使用,變成一個簡單的SOA架構。
緊接着業務模式越來越復雜,訂單、商品、庫存、價格每塊玩法都很深入,比如價格區分會員等級,訪問渠道(無線還是PC),銷售方式(團購還是普通)等,還有大量的價格促銷,這些規則很復雜,容易相互沖突,需要把分散到各個業務的價格邏輯進行統一管理,以基礎價格服務的方式透明地提供給上層應用,變成一個微內核的SOA架構。
同時不管是企業內部用戶,還是外部顧客所需要的功能,都由很多細分的應用提供支持,需要提供portal,集成相關應用,為不同用戶提供統一視圖,頂層變成一個AOA的架構(application orientated architecture)。
隨着業務和系統不斷進化,最后一個比較完善的大型互聯網應用架構如下圖所示:
最終整個系統化整為零,形神兼備,支持積木式拼裝,支持開發敏捷和業務敏捷。
應用架構,需要站在業務和技術中間,在正確的時間點做正確的架構選擇,保證系統有序進化。