web架構(gòu)之所以會(huì)持續(xù)演進(jìn)，個(gè)人認(rèn)為主要是兩方面的驅(qū)動(dòng)因素，一是解決“三高”問(wèn)題，二是新技術(shù)的快速發(fā)展。

而總體的演進(jìn)思路無(wú)非就是各種拆分（分層、分割、分布式、集群、異步、緩存），最終利用硬件平滑的彈性擴(kuò)展，構(gòu)建終極架構(gòu)形態(tài)。所以接下來(lái)就從拆分和分布式的思路描述企業(yè)級(jí)應(yīng)用架構(gòu)的演進(jìn)過(guò)程。對(duì)于搜索引擎技術(shù)、緩存技術(shù)、內(nèi)存數(shù)據(jù)庫(kù)技術(shù)、應(yīng)用容器化等技術(shù)的卓越貢獻(xiàn)，在本篇文章就不細(xì)致描述了。

1.應(yīng)用與數(shù)據(jù)庫(kù)物理資源的拆分

從web應(yīng)用與本地?cái)?shù)據(jù)庫(kù)部署在一臺(tái)服務(wù)器，演進(jìn)為二者分開(kāi)部署。在提高系統(tǒng)負(fù)載能力的同時(shí)，也提高了容災(zāi)能力，更可歌可泣的是，此方式也為今后的架構(gòu)演進(jìn)提供了基本思路：“增加硬件服務(wù)器是個(gè)行之有效的辦法”。

2.應(yīng)用服務(wù)器分布式集群

將應(yīng)用服務(wù)器從一臺(tái)變?yōu)槎嗯_(tái)，這樣用戶請(qǐng)求的負(fù)載壓力被均衡分配。此種方式的優(yōu)化效果很好理解，但要解決很多問(wèn)題才能真正實(shí)現(xiàn)負(fù)載均衡，①如何實(shí)現(xiàn)用戶請(qǐng)求平均分配。②如何實(shí)現(xiàn)用戶請(qǐng)求的調(diào)度轉(zhuǎn)發(fā)。③如何實(shí)現(xiàn)服務(wù)器故障切換。④如何實(shí)現(xiàn)session一致性。

3.數(shù)據(jù)庫(kù)讀寫分離

大多數(shù)應(yīng)用對(duì)于數(shù)據(jù)庫(kù)的壓力都集中在各種各樣、各個(gè)維度、各種查詢條件組合的查詢與統(tǒng)計(jì)操作，不過(guò)把數(shù)據(jù)庫(kù)一分為二，顯然不是最終形態(tài)，他同樣存在很多問(wèn)題，①如何實(shí)現(xiàn)主從庫(kù)的數(shù)據(jù)同步問(wèn)題。②數(shù)據(jù)操作對(duì)于數(shù)據(jù)源的選擇問(wèn)題。③僅僅一分為二很難徹底緩解數(shù)據(jù)“讀”庫(kù)的壓力。

4.數(shù)據(jù)庫(kù)水平拆分與垂直拆分

對(duì)數(shù)據(jù)庫(kù)讀寫分離一分為二顯然很容易達(dá)到瓶頸，而對(duì)讀庫(kù)的水平拆分，則充分的解決了數(shù)據(jù)查詢的負(fù)載問(wèn)題。而數(shù)據(jù)庫(kù)的垂直拆分，其實(shí)不能在當(dāng)前的演進(jìn)階段就草率執(zhí)行，這里要引進(jìn)企業(yè)中臺(tái)的感念，個(gè)人認(rèn)為，業(yè)務(wù)中臺(tái)是數(shù)據(jù)中臺(tái)的驅(qū)動(dòng)，數(shù)據(jù)中臺(tái)是業(yè)務(wù)中臺(tái)的基礎(chǔ)，也就是說(shuō)，要想對(duì)數(shù)據(jù)做垂直拆分，不僅要對(duì)業(yè)務(wù)做拆分，還要對(duì)業(yè)務(wù)本身的服務(wù)做邊界清晰的拆分，才能保證數(shù)據(jù)垂直拆分的可行性。數(shù)據(jù)庫(kù)拆分同樣帶來(lái)一些問(wèn)題，①依然是數(shù)據(jù)源路由問(wèn)題。②垂直拆分后主外鍵設(shè)置問(wèn)題。③垮庫(kù)數(shù)據(jù)操作的jion問(wèn)題。④夸業(yè)務(wù)庫(kù)的事務(wù)問(wèn)題。

5.數(shù)據(jù)庫(kù)分表分庫(kù)

就是大表變小表，阿里對(duì)于分表的建議是3年內(nèi)單表數(shù)據(jù)量超過(guò)5000萬(wàn)條，分表同樣帶來(lái)很多問(wèn)題，①同一張表拆分后的關(guān)聯(lián)查詢。②事務(wù)操作變的異常復(fù)雜。③數(shù)據(jù)維護(hù)成本極高。④橫向擴(kuò)容的hash取模問(wèn)題。⑤結(jié)果集的合并和排序問(wèn)題。

6.微應(yīng)用、微服務(wù)拆分

為什么要把微應(yīng)用、微服務(wù)放在一起說(shuō)，個(gè)人認(rèn)為微應(yīng)用適用范圍有限且是一個(gè)過(guò)渡階段，單純的應(yīng)用拆分雖然運(yùn)維升級(jí)較為簡(jiǎn)單，但存在太多的公共模塊或者說(shuō)公共代碼，如果功能模塊升級(jí)改造，會(huì)導(dǎo)致所有的引用模塊共同升級(jí)，這也是微服務(wù)逐步發(fā)展的最大契機(jī)?；跇I(yè)務(wù)邊界對(duì)服務(wù)進(jìn)行合理拆分，應(yīng)用于服務(wù)通過(guò)HTTP、PRC等方式調(diào)用，假設(shè)不考慮其它問(wèn)題，這樣的架構(gòu)模式，基本是企業(yè)web架構(gòu)的終極形態(tài)了，至少已拆無(wú)可拆，相關(guān)技術(shù)也趨于成熟，比如Dubbo、SpringCloud等框架都不同程度的實(shí)現(xiàn)了服務(wù)治理、限流、熔斷、降級(jí)、自動(dòng)化運(yùn)維的功能，然而不同的接口訪問(wèn)方式不同，包括接口形式、數(shù)據(jù)格式、編碼格式等等差異化問(wèn)題，導(dǎo)致企業(yè)內(nèi)部應(yīng)用服務(wù)集成都變得極為復(fù)雜，何況外部集成。因此引用了企業(yè)服務(wù)總線ESB，引用了消息中間件。然而ESB存在一些顯而易見(jiàn)的問(wèn)題，①增加設(shè)計(jì)開(kāi)發(fā)成本。②對(duì)于建設(shè)中或者運(yùn)行中的應(yīng)用或服務(wù)很不友好。③增加硬件資源與運(yùn)維成本。④容易出現(xiàn)“雪崩”效應(yīng)。去中心化雖能徹底解決問(wèn)題，可談何容易，最終還得扯到企業(yè)信息化管理成熟度上去，哈哈。