前言
如何針對當(dāng)前需求,選擇合適的應(yīng)用架構(gòu),如何面向未來,保證架構(gòu)平滑過渡,這個是軟件開發(fā)者,特別是架構(gòu)師,都需要深入思考的問題。
無架構(gòu),不系統(tǒng),架構(gòu)是大型系統(tǒng)的關(guān)鍵。從形上看,架構(gòu)是系統(tǒng)的骨架,支撐和鏈接各個部分;從神上看,架構(gòu)是系統(tǒng)的靈魂,深刻體現(xiàn)業(yè)務(wù)本質(zhì)。
架構(gòu)可細(xì)分為業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu),業(yè)務(wù)架構(gòu)是戰(zhàn)略,應(yīng)用架構(gòu)是戰(zhàn)術(shù),技術(shù)架構(gòu)是裝備。其中應(yīng)用架構(gòu)承上啟下,一方面承接業(yè)務(wù)架構(gòu)的落地,另一方面影響技術(shù)選型。
如何針對當(dāng)前需求,選擇合適的應(yīng)用架構(gòu),如何面向未來,保證架構(gòu)平滑過渡,這個是軟件開發(fā)者,特別是架構(gòu)師,都需要深入思考的問題。本文基于作者在大型互聯(lián)網(wǎng)系統(tǒng)的實踐和思考,和大家一起探討應(yīng)用架構(gòu)的選型。
應(yīng)用架構(gòu)本質(zhì)
應(yīng)用作為獨立可部署的單元,為系統(tǒng)劃分了明確的邊界,深刻影響系統(tǒng)功能組織、代碼開發(fā)、部署和運維等各方面,應(yīng)用架構(gòu)定義系統(tǒng)有哪些應(yīng)用、以及應(yīng)用之間如何分工和合作。
分有兩種方式,一種是水平分,按照功能處理順序劃分應(yīng)用,比如把系統(tǒng)分為web前端/中間服務(wù)/后臺任務(wù),這是面向業(yè)務(wù)深度的劃分。另一種是垂直分,按照不同的業(yè)務(wù)類型劃分應(yīng)用,比如進(jìn)銷存系統(tǒng)可以劃分為三個獨立的應(yīng)用,這是面向業(yè)務(wù)廣度的劃分。
應(yīng)用的合反映應(yīng)用之間如何協(xié)作,共同完成復(fù)雜的業(yè)務(wù)case,主要體現(xiàn)在應(yīng)用之間的通訊機(jī)制和數(shù)據(jù)格式,通訊機(jī)制可以是同步調(diào)用/異步消息/共享DB訪問等,數(shù)據(jù)格式可以是文本/XML/JSON/二進(jìn)制等。
應(yīng)用的分偏向于業(yè)務(wù),反映業(yè)務(wù)架構(gòu),應(yīng)用的合偏向于技術(shù),影響技術(shù)架構(gòu)。分降低了業(yè)務(wù)復(fù)雜度,系統(tǒng)更有序,合增加了技術(shù)復(fù)雜度,系統(tǒng)更無序。
應(yīng)用架構(gòu)的本質(zhì)是通過系統(tǒng)拆分,平衡業(yè)務(wù)和技術(shù)復(fù)雜性,保證系統(tǒng)形散神不散。
系統(tǒng)采用什么樣的應(yīng)用架構(gòu),受業(yè)務(wù)復(fù)雜性影響,包括企業(yè)發(fā)展階段和業(yè)務(wù)特點;同時受技術(shù)復(fù)雜性影響,包括IT技術(shù)發(fā)展階段和內(nèi)部技術(shù)人員水平。業(yè)務(wù)復(fù)雜性(包括業(yè)務(wù)量大)必然帶來技術(shù)復(fù)雜性,應(yīng)用架構(gòu)目標(biāo)是解決業(yè)務(wù)復(fù)雜性的同時,避免技術(shù)太復(fù)雜,確保業(yè)務(wù)架構(gòu)落地。
常見的應(yīng)用架構(gòu)有多種,下面根據(jù)系統(tǒng)拆分方式,以及如何平衡業(yè)務(wù)與技術(shù)的角度進(jìn)行分析,討論各自的適用性,給企業(yè)應(yīng)用架構(gòu)選型提供參考。
單體式應(yīng)用
1、架構(gòu)模型
系統(tǒng)只有一個應(yīng)用,相應(yīng)地,代碼放在一個工程里管理;打包成一個應(yīng)用;部署在一臺機(jī)器;在一個DB里存儲數(shù)據(jù)。單體式應(yīng)用的架構(gòu)如下圖所示:
單體式應(yīng)用采用分層架構(gòu),按照調(diào)用順序,從上到下一般為表示層、業(yè)務(wù)層、數(shù)據(jù)訪問層、DB層,表示層負(fù)責(zé)用戶體驗,業(yè)務(wù)層負(fù)責(zé)業(yè)務(wù)邏輯,數(shù)據(jù)訪問層負(fù)責(zé)DB層的數(shù)據(jù)存取。
單體應(yīng)用在水平方向上,上下層之間職責(zé)劃分清晰;但垂直方向上缺乏清晰的邊界,上下層模塊之間是多對多的依賴關(guān)系,比如業(yè)務(wù)模塊1 (圖中BO1)可能調(diào)用數(shù)據(jù)層所有模塊DAO 1~3, DAO1也可能被業(yè)務(wù)層所有模塊BO1~3調(diào)用。
單體應(yīng)用通過水平分層,降低了業(yè)務(wù)復(fù)雜性;同時模塊之間是進(jìn)程內(nèi)部調(diào)用,技術(shù)實現(xiàn)簡單。
但單體應(yīng)用對系統(tǒng)的切分不徹底,只有水平切分,并且是邏輯上,因此適合業(yè)務(wù)比較單一,但深度上比較復(fù)雜的系統(tǒng),比如TCP/IP網(wǎng)絡(luò)通訊,從應(yīng)用層/傳輸層/網(wǎng)絡(luò)層/鏈路層,層層推進(jìn),類似這樣的系統(tǒng)可以方便地增加水平層次去適配。
對于廣度上復(fù)雜的業(yè)務(wù),由于缺乏垂直切分,強(qiáng)行把不同業(yè)務(wù)綁定在一起,整個系統(tǒng)神散形不散,帶來一系列問題。比如OTA網(wǎng)站包含機(jī)票/酒店/旅游等多個垂直業(yè)務(wù)板塊,每塊都比較獨立,就不適合放在一起開發(fā)維護(hù)。
2、優(yōu)缺點
單體式應(yīng)用的優(yōu)點和缺點都很鮮明,如下圖所示。
單體式應(yīng)用的優(yōu)點明顯:
- 現(xiàn)有IDE都是集成開發(fā)環(huán)境,非常適合單體式應(yīng)用,開發(fā)、編譯、調(diào)試一站式搞定。
- 一個應(yīng)用包含所有功能,容易測試和部署。
- 運行在一個物理節(jié)點,環(huán)境單一,運行穩(wěn)定,故障恢復(fù)簡單。
單體式應(yīng)用的缺點也明顯:
- 業(yè)務(wù)邊界模糊,模塊職責(zé)不清晰,當(dāng)系統(tǒng)逐漸變大,代碼依賴復(fù)雜,難以維護(hù)。
- 所有人同時在一個工程上開發(fā),容易發(fā)生代碼修改沖突,依賴復(fù)雜導(dǎo)致項目協(xié)調(diào)困難,并且局部修改影響不可知,需要全覆蓋測試,需要重新部署,難以支持大團(tuán)隊并行開發(fā)。
- 當(dāng)系統(tǒng)很大時,編譯和部署耗時。
- 應(yīng)用水平擴(kuò)展難,一方面狀態(tài)在應(yīng)用內(nèi)部管理,無法透明路由;另
- 一方面,不同模塊對資源需求差異大,當(dāng)業(yè)務(wù)量增大時,一視同仁地為所有模塊增加機(jī)器導(dǎo)致硬件浪費。
作者之前曾在一家大型電商公司工作,當(dāng)時整個網(wǎng)站是一個單體應(yīng)用,有數(shù)百萬行代碼,有專門的團(tuán)隊負(fù)責(zé)代碼合并,有專門的團(tuán)隊負(fù)責(zé)編譯腳本開發(fā),有一套復(fù)雜的火車模型協(xié)調(diào)不同團(tuán)隊,整套流程體系很精密很復(fù)雜,但這何嘗不是單體應(yīng)用的無奈和代價。
分布式架構(gòu)應(yīng)用
1、架構(gòu)模型
在分布式應(yīng)用架構(gòu)中,應(yīng)用相互獨立,每個應(yīng)用代碼獨立開發(fā),獨立部署,應(yīng)用通過有限的API接口互相關(guān)聯(lián)。API接口屬于應(yīng)用一部分,一般和表示層處于同一層次,兩者共享業(yè)務(wù)邏輯層,API和表示層采用同樣的web端技術(shù),通訊協(xié)議一般使用HTTP,數(shù)據(jù)格式是JSON,應(yīng)用集成方式比較簡化。
分布式架構(gòu)首先對系統(tǒng)按照業(yè)務(wù)進(jìn)行垂直切分,對廣度上復(fù)雜的業(yè)務(wù)實現(xiàn)物理解耦,應(yīng)用內(nèi)部還是水平切分,對深度上復(fù)雜的業(yè)務(wù)實現(xiàn)邏輯解耦。分布式架構(gòu)也可以解決業(yè)務(wù)量大的問題,對于某些高并發(fā)/大流量系統(tǒng),把系統(tǒng)切分為不同應(yīng)用,針對資源需求特點(比如CPU/IO/存儲密集型),通過加強(qiáng)硬件配置滿足不同應(yīng)用的需求,避免一刀切方式帶來的資源浪費。
技術(shù)上,API采用標(biāo)準(zhǔn)的HTTP/JSON進(jìn)行通訊,調(diào)用雙方實現(xiàn)難度都不大,但是API一般是“裸奔”的,在系統(tǒng)層面,調(diào)用依賴關(guān)系不透明,調(diào)用可靠性缺乏保障,因此只適用應(yīng)用之間依賴鏈路少,調(diào)用量不大的系統(tǒng),即應(yīng)用之間耦合確實夠松的系統(tǒng)。
2、優(yōu)缺點
分布式架構(gòu)每個應(yīng)用內(nèi)部高內(nèi)聚,獨立開發(fā)、測試和部署,支持開發(fā)敏捷;同時應(yīng)用之間松耦合,業(yè)務(wù)邊界清晰,業(yè)務(wù)依賴明確,支持大項目并行開發(fā),實現(xiàn)業(yè)務(wù)敏捷。
在分布式架構(gòu)中,應(yīng)用的表示層和API沒有物理分離,需要同時滿足自身業(yè)務(wù)需求和關(guān)聯(lián)業(yè)務(wù)需求,相互影響,比如API接口會隨著外部應(yīng)用的需求經(jīng)常變化,這會導(dǎo)致整個應(yīng)用重新部署。
運行時,API以HTTP/REST方式通過網(wǎng)絡(luò)對外提供接口,其通信可靠性和數(shù)據(jù)的封裝性相對于進(jìn)程內(nèi)調(diào)用比較差,如果沒有一些可靠的技術(shù)機(jī)制,如路由保障/失敗重試/監(jiān)控等, 裸奔的API方式將嚴(yán)重影響系統(tǒng)整體可用性。
SOA架構(gòu)
1、架構(gòu)模型
廣義上,SOA也是分布式應(yīng)用架構(gòu)一種,但內(nèi)涵不同。
這里有兩種類型的“應(yīng)用”,應(yīng)用1~N是前端應(yīng)用,面向用戶,服務(wù)1~N是service,只提供業(yè)務(wù)邏輯和數(shù)據(jù)。這些應(yīng)用都是獨立部署,前端應(yīng)用不再通過API直接關(guān)聯(lián),而是通過后端服務(wù)共享業(yè)務(wù)邏輯。
此外相對于“裸奔”的API,SOA架構(gòu)提供配套的服務(wù)治理,包括服務(wù)注冊、服務(wù)路由、服務(wù)授權(quán)、服務(wù)降級、服務(wù)監(jiān)控等等。這些功能通過專門的中間件支持,有中心化和去中心化兩種方式,具體技術(shù)實現(xiàn)機(jī)制和適用場景,網(wǎng)上有很多專門介紹,這里就不展開了。
SOA架構(gòu)在分布式架構(gòu)垂直切分的基礎(chǔ)上,進(jìn)一步把原來單體應(yīng)用的業(yè)務(wù)邏輯層獨立成service,做到物理上的徹底分離。
每個service專注于特定職責(zé),實現(xiàn)系統(tǒng)核心業(yè)務(wù)邏輯,service之間通過互相調(diào)用,可以完成復(fù)雜業(yè)務(wù)邏輯,解決業(yè)務(wù)深度上的問題;同時service面向眾多的應(yīng)用,以共享的方式支持邏輯復(fù)用。所以,SOA架構(gòu)既體現(xiàn)業(yè)務(wù)的分,又體現(xiàn)業(yè)務(wù)的合,更多地從業(yè)務(wù)整體上考慮系統(tǒng)拆分。
相比分布式應(yīng)用架構(gòu),基于SOA的系統(tǒng)有大量的service應(yīng)用,整個系統(tǒng)基于服務(wù)調(diào)用,所以對服務(wù)依賴的透明性和服務(wù)調(diào)用的可靠性提出很高要求,需要專門的SOA框架支持,還需要配套的監(jiān)控體系和自動化的運維系統(tǒng)支持,技術(shù)復(fù)雜性高,SOA架構(gòu)可以集中體現(xiàn)一個企業(yè)的IT技術(shù)能力。
2、優(yōu)缺點
SOA架構(gòu)優(yōu)缺點如下圖所示:
相比較普通API方式,SOA架構(gòu)更進(jìn)一步:
- 每個service都是濃縮的精華,聚焦某方面核心業(yè)務(wù),同時以復(fù)用的方式供整個系統(tǒng)共享。
- 服務(wù)作為獨立的應(yīng)用,獨立部署,接口清晰,很容易做自動化測試和部署。
- 服務(wù)是無狀態(tài)的,很容易做水平擴(kuò)展;通過容器虛擬化技術(shù),實現(xiàn)故障隔離和資源高效利用,業(yè)務(wù)量大的時候,加機(jī)器即可。
- 基于SOA的系統(tǒng)可以根據(jù)服務(wù)運行情況,靈活調(diào)控服務(wù)資源,包括服務(wù)上下架、服務(wù)升降級等,使系統(tǒng)真正具備可運營的能力。
當(dāng)然天下沒有免費的午餐,SOA也帶來了額外復(fù)雜性和弊端:
- 系統(tǒng)依賴復(fù)雜,給開發(fā)/測試/部署帶來一系列挑戰(zhàn)。
- 端到端的調(diào)用鏈路長,可靠性降低,依賴網(wǎng)絡(luò)狀況、服務(wù)框架及具體service的質(zhì)量。
- 分布式數(shù)據(jù)一致性和分布式事務(wù)支持困難,一般通過最終一致性簡化解決。
- 端到端的測試和排障復(fù)雜,SOA對運維提出更高要求。
SOA落地方式
在實踐中,SOA架構(gòu)不斷深入發(fā)展,具體落地形式也多種多樣。
1、面向外部SOA
SOA的前身是web service,web service初衷是企業(yè)之間通過Internet進(jìn)行互聯(lián),如下圖所示:
每個公司把自己的優(yōu)勢資源通過web service發(fā)布,如圖中天氣服務(wù)/機(jī)票服務(wù)/酒店預(yù)訂服務(wù)來自不同公司,其他企業(yè)可以直接調(diào)用服務(wù)或整合多個服務(wù),實現(xiàn)企業(yè)間資源共享。
2、面向應(yīng)用SOA
面向應(yīng)用SOA把原單體應(yīng)用里的業(yè)務(wù)邏輯層剝離出來,作為單獨的服務(wù)對外提供。
舉一個電商的例子,這里有兩個應(yīng)用,顧客使用的商品詳情頁,展示商品的信息、商品庫存,商品價格;內(nèi)部客服人員使用的客服系統(tǒng),根據(jù)顧客來電要求,修改訂單,同時也需要獲取商品的基本信息、價格信息等。
經(jīng)過SOA改造后,應(yīng)用架構(gòu)如下圖所示:
這里的service實現(xiàn)底層數(shù)據(jù)對于前端頁面的透明化,表示層和業(yè)務(wù)邏輯各自獨立維護(hù),同時全部業(yè)務(wù)邏輯對其他應(yīng)用開放,新應(yīng)用可以自由整合來自多個服務(wù)的接口,快速支持業(yè)務(wù)創(chuàng)新。
但每個service是原系統(tǒng)業(yè)務(wù)邏輯的封裝,接口設(shè)計面向原應(yīng)用的業(yè)務(wù)case,如果其它應(yīng)用的需求有差異,則自己創(chuàng)建service訪問底層數(shù)據(jù)。如此導(dǎo)致service職責(zé)不夠聚焦,類似的接口分散化,同時底層數(shù)據(jù)表被多方訪問,數(shù)據(jù)模型修改困難,數(shù)據(jù)一致性難以保障。
最終系統(tǒng)整體依賴復(fù)雜,容易形成網(wǎng)狀結(jié)構(gòu),修改時,往往牽一發(fā)動全身。
3、微內(nèi)核SOA
每個企業(yè)都有自己的核心數(shù)據(jù),比如對于電商系統(tǒng)來說,用戶/商品/訂單/庫存/價格都是核心數(shù)據(jù),稱之為主數(shù)據(jù)。微內(nèi)核SOA聚焦各類主數(shù)據(jù),封裝相關(guān)表的所有訪問,架構(gòu)示意如下:
每個服務(wù)獨占式地封裝對應(yīng)主數(shù)據(jù)表的訪問,這些服務(wù)構(gòu)成系統(tǒng)的基礎(chǔ)服務(wù),一起組成系統(tǒng)的微內(nèi)核,供所有上層應(yīng)用共享。
微內(nèi)核服務(wù)是原子服務(wù),接口粒度比較細(xì),可以在其上構(gòu)造聚合服務(wù),為上層應(yīng)用提供粗粒度服務(wù)??梢允切畔⒕酆?,比如圖中商品聚合服務(wù)整合商品的基本信息/庫存/價格;也可以是流程聚合,比如下單接口,調(diào)用來自多個服務(wù)的接口,共同完成復(fù)雜的下單操作。
這里服務(wù)是分層次的,聚合服務(wù)是上層,基礎(chǔ)服務(wù)是底層,依賴規(guī)則如下:
- 上層服務(wù)可以調(diào)用同層服務(wù)和基礎(chǔ)服務(wù)
- 基礎(chǔ)服務(wù)是原子服務(wù),不可相互調(diào)用
- 前端應(yīng)用可調(diào)用聚合服務(wù)和跨層調(diào)用基礎(chǔ)服務(wù)
微內(nèi)核的微表示服務(wù)數(shù)量有限,接口粒度細(xì);內(nèi)核表示這些基礎(chǔ)服務(wù)處于調(diào)用底層,負(fù)責(zé)核心數(shù)據(jù)和業(yè)務(wù),這和操作系統(tǒng)的內(nèi)核概念上類似,主數(shù)據(jù)相當(dāng)于核心的硬件,如cpu/內(nèi)存/外存等,微內(nèi)核的各個基礎(chǔ)服務(wù)分別負(fù)責(zé)這些核心資源的管理,屏蔽底層的復(fù)雜性,對上層應(yīng)用提供統(tǒng)一入口和透明化訪問。
最近微服務(wù)很火,其特征是職責(zé)單一、接口粒度細(xì)、輕量級通訊協(xié)議等,微內(nèi)核SOA架構(gòu)有微服務(wù)的形,同時有業(yè)務(wù)內(nèi)核的神,是架構(gòu)形散神不散思想的很好體現(xiàn),這個在淘寶、京東、一號店等大型電商系統(tǒng)都已有豐富實踐。
4、方式比較
面向企業(yè)外部SOA,業(yè)務(wù)場景有特殊性,不深入分析,這里主要比較面向應(yīng)用SOA和微內(nèi)核SOA的區(qū)別,一個大型B2C電商系統(tǒng),應(yīng)用和主數(shù)據(jù)是多對多依賴關(guān)系,如下圖所示:
面向應(yīng)用的服務(wù)從特定應(yīng)用出發(fā),整合應(yīng)用對相關(guān)數(shù)據(jù)的訪問需求;從特定主數(shù)據(jù)出發(fā),收斂各個業(yè)務(wù)對數(shù)據(jù)的訪問需求。
在面向應(yīng)用的服務(wù)設(shè)計下,數(shù)據(jù)表的訪問入口是發(fā)散的,來自多個應(yīng)用,這帶來一系列弊端:
1)數(shù)據(jù)模型碎片化
每個應(yīng)用都會基于自己的需求,往表里加字段,很多電商的商品表/訂單表有多達(dá)200個字段,都是野蠻增長,缺少控制的結(jié)果。
2)數(shù)據(jù)模型修改困難
類似的訪問需求散布在多個服務(wù),缺乏整合,同時表schema修改會影響很多服務(wù)和應(yīng)用。
3)連接資源利用率低
多個服務(wù)直連數(shù)據(jù)庫,并且每個服務(wù)會盡可能多地配置連接數(shù),在應(yīng)用數(shù)量多,業(yè)務(wù)并發(fā)量大的情況下,往往導(dǎo)致數(shù)據(jù)庫連接數(shù)不夠。
微內(nèi)核SOA通過收斂對主數(shù)據(jù)的訪問,保證數(shù)據(jù)模型一致性、優(yōu)化接口和有效利用數(shù)據(jù)庫連接資源。同時通過服務(wù)分層,簡化系統(tǒng)依賴關(guān)系。更為重要的是,微內(nèi)核服務(wù)保證了業(yè)務(wù)模型的一致性,比如電商系統(tǒng)的商品體系,包含單品/系列商品/組合商品/搭售商品/虛擬商品等一系列復(fù)雜概念,這些復(fù)雜邏輯在基礎(chǔ)商品服務(wù)里處理,對上層業(yè)務(wù)透明一致。
如果業(yè)務(wù)模式簡單,應(yīng)用數(shù)量少,特定主數(shù)據(jù)的訪問絕大多數(shù)(比如說80%)來自某個應(yīng)用,則服務(wù)設(shè)計以應(yīng)用為中心是可以的,不利影響比較小。
對于大型互聯(lián)網(wǎng)系統(tǒng),業(yè)務(wù)廣度和深度都復(fù)雜,但無論多復(fù)雜的系統(tǒng),主數(shù)據(jù)類型都是有限的,可以通過聚焦有限的基礎(chǔ)業(yè)務(wù),以此支持無限的應(yīng)用業(yè)務(wù),結(jié)果是底層業(yè)務(wù)模型穩(wěn)定,上層業(yè)務(wù)可以靈活擴(kuò)展。
面向應(yīng)用的服務(wù)設(shè)計是SOA初級階段,從具體業(yè)務(wù)著手,自底向上,難度?。晃?nèi)核服務(wù)設(shè)計是SOA高級階段,從全局著手,對業(yè)務(wù)和數(shù)據(jù)模型高度抽象,自頂向下,難度大。
值得注意的是,在提供基礎(chǔ)服務(wù)同時,每個應(yīng)用也可以創(chuàng)建自己需要的服務(wù)(但主數(shù)據(jù)的訪問必須通過基礎(chǔ)服務(wù)),所以微內(nèi)核的服務(wù)和面向應(yīng)用的服務(wù)可以有機(jī)結(jié)合在一起,當(dāng)業(yè)務(wù)應(yīng)用變得很多,并且不斷增長,可以考慮逐步往基礎(chǔ)服務(wù)過渡,整合特定主數(shù)據(jù)有關(guān)的業(yè)務(wù)邏輯。
順便提一下,應(yīng)用架構(gòu)會影響組織架構(gòu),如果采用面向應(yīng)用的服務(wù)設(shè)計,具體service一般由相關(guān)應(yīng)用的團(tuán)隊負(fù)責(zé);如果是微內(nèi)核的服務(wù)設(shè)計,一般由單獨的共享服務(wù)部門負(fù)責(zé)所有基礎(chǔ)服務(wù)開發(fā),和各個業(yè)務(wù)研發(fā)部門并列,保證設(shè)計的中立性和需求響應(yīng)的及時性。
應(yīng)用架構(gòu)的進(jìn)化
軟件是人類活動的虛擬,業(yè)務(wù)架構(gòu)是生產(chǎn)活動的體現(xiàn),應(yīng)用架構(gòu)是具體分工合作關(guān)系的體現(xiàn)。
單體應(yīng)用類似原始氏族時代,氏族內(nèi)部有簡單分工,氏族之間沒有聯(lián)系;分布式架構(gòu)類似封建社會,每個家庭自給自足,家庭之間有少量交換關(guān)系;SOA架構(gòu)類似工業(yè)時代,企業(yè)提供各種成品服務(wù),我為人人,人人為我,相互依賴。微內(nèi)核的SOA架構(gòu)類似后工業(yè)時代,有些企業(yè)聚焦提供水電煤等基礎(chǔ)設(shè)施服務(wù),其他企業(yè)在之上提供生活服務(wù),依賴有層次。
業(yè)務(wù)架構(gòu)是生產(chǎn)力,應(yīng)用架構(gòu)是生產(chǎn)關(guān)系,技術(shù)架構(gòu)是生產(chǎn)工具。業(yè)務(wù)架構(gòu)決定應(yīng)用架構(gòu),應(yīng)用架構(gòu)需要適配業(yè)務(wù)架構(gòu),并隨著業(yè)務(wù)架構(gòu)不斷進(jìn)化,同時應(yīng)用架構(gòu)依托技術(shù)架構(gòu)最終落地。
企業(yè)一開始業(yè)務(wù)比較簡單,比如進(jìn)銷存,此時面向內(nèi)部用戶,提供簡單的信息管理系統(tǒng)(MIS),支持?jǐn)?shù)據(jù)增刪改查即可,單體應(yīng)用可以滿足要求。
隨著業(yè)務(wù)深入,進(jìn)銷存每塊業(yè)務(wù)都變復(fù)雜,同時新增客戶關(guān)系管理,以更好支持營銷,業(yè)務(wù)的深度和廣度都增加,這時需要對系統(tǒng)按照業(yè)務(wù)拆分,變成一個分布式系統(tǒng)。
更進(jìn)一步,企業(yè)轉(zhuǎn)向互聯(lián)網(wǎng)+戰(zhàn)略,拓展在線交易,線上系統(tǒng)和內(nèi)部系統(tǒng)業(yè)務(wù)類似,沒必要重做一套,此時把內(nèi)部系統(tǒng)的邏輯做服務(wù)化改造,同時供線上線下系統(tǒng)使用,變成一個簡單的SOA架構(gòu)。
緊接著業(yè)務(wù)模式越來越復(fù)雜,訂單、商品、庫存、價格每塊玩法都很深入,比如價格區(qū)分會員等級,訪問渠道(無線還是PC),銷售方式(團(tuán)購還是普通)等,還有大量的價格促銷,這些規(guī)則很復(fù)雜,容易相互沖突,需要把分散到各個業(yè)務(wù)的價格邏輯進(jìn)行統(tǒng)一管理,以基礎(chǔ)價格服務(wù)的方式透明地提供給上層應(yīng)用,變成一個微內(nèi)核的SOA架構(gòu)。
同時不管是企業(yè)內(nèi)部用戶,還是外部顧客所需要的功能,都由很多細(xì)分的應(yīng)用提供支持,需要提供portal,集成相關(guān)應(yīng)用,為不同用戶提供統(tǒng)一視圖,頂層變成一個AOA的架構(gòu)(application orientated architecture)。
隨著業(yè)務(wù)和系統(tǒng)不斷進(jìn)化,最后一個比較完善的大型互聯(lián)網(wǎng)應(yīng)用架構(gòu)如下圖所示:
最終整個系統(tǒng)化整為零,形神兼?zhèn)?,支持積木式拼裝,支持開發(fā)敏捷和業(yè)務(wù)敏捷。
應(yīng)用架構(gòu),需要站在業(yè)務(wù)和技術(shù)中間,在正確的時間點做正確的架構(gòu)選擇,保證系統(tǒng)有序進(jìn)化。