說到互聯(lián)網(wǎng)系統(tǒng)架構(gòu)，隨便網(wǎng)上一搜都有大量的相關(guān)文章/書籍，而這些，得益于過去幾年互聯(lián)網(wǎng)行業(yè)的快速發(fā)展與繁榮，在今天看來，這些技術(shù)/解決方案似乎早已不是什么新鮮的東西了，但是，本文筆者仍想簡單聊聊這個話題，權(quán)當(dāng)閑聊了。一家之言，姑且看看，不妥之處，還請淡然笑之。
說到互聯(lián)網(wǎng)系統(tǒng)架構(gòu)，在互聯(lián)網(wǎng)行業(yè)日漸成熟的今天，一談到這背后的技術(shù)體系，很多人腦海中可能就會浮現(xiàn)從網(wǎng)上看到的，一個個龐大的知識圖譜，能說地清楚其中一二的同學(xué)，自然是志得意滿，而對于新入行的同學(xué)來說，則可能直接就勸退了。
那么，我們是否需要對所有的這些相關(guān)技術(shù)，都全部學(xué)習(xí)掌握呢？
筆者以為，大可不必過渡焦慮，需要明白的是，一個龐大而復(fù)雜的互聯(lián)網(wǎng)架構(gòu)體系，必然是由一個強(qiáng)大的團(tuán)隊(duì)來共同支撐維護(hù)的，團(tuán)隊(duì)成員各司其職、各盡所長，而這也就是團(tuán)隊(duì)的力量。
當(dāng)然，對于互聯(lián)網(wǎng)系統(tǒng)架構(gòu)的演進(jìn)過程，相信很多人都有自己的理解，從單體應(yīng)用到分布式應(yīng)用、從開發(fā)框架到中間件技術(shù)、從容器化到云原生等等，不一而足。不過，在這龐雜的技術(shù)體系中，從宏觀上理清其演變過程中的關(guān)鍵節(jié)點(diǎn)與可能面臨的關(guān)鍵問題，對于我們理解一個大型互聯(lián)網(wǎng)系統(tǒng)的架構(gòu)，是很有裨益的。
Tips:
系統(tǒng)架構(gòu)應(yīng)當(dāng)是基于具體業(yè)務(wù)場景的，脫離了具體業(yè)務(wù)談技術(shù)架構(gòu)，難免有空中樓閣、鏡花水月之嫌。系統(tǒng)架構(gòu)常見的演變過程，網(wǎng)上的相關(guān)文章不勝枚舉，不過，為了保持本文整體的完整性與連慣性，筆者以為，仍需從基本的系統(tǒng)架構(gòu)演進(jìn)過程說起，綱舉則目張，先對常見大型互聯(lián)網(wǎng)系統(tǒng)架構(gòu)的演進(jìn)過程有一個整體上的大致梳理，再說演進(jìn)過程中常見的問題，也就水到渠成了。
“一個優(yōu)秀的大型互聯(lián)網(wǎng)系統(tǒng)架構(gòu)，不是設(shè)計(jì)出來的，而是不斷演進(jìn)而來的” ，類似的觀點(diǎn)，相信大家都有所了解，也有所思考，但是，為什么是這樣的呢？是技術(shù)同學(xué)技術(shù)能力不夠，設(shè)計(jì)不出優(yōu)秀的系統(tǒng)架構(gòu)嗎，還是說技術(shù)同學(xué)寫的BUG太多，需要不斷修復(fù)？
筆者以為，都不是，架構(gòu)的演變，其本質(zhì)在于技術(shù)是服務(wù)于業(yè)務(wù)需求的，而業(yè)務(wù)需求是不斷變化發(fā)展的，而這，天生就注定了技術(shù)架構(gòu)的不斷演變，是一種必然的選擇。也正是因?yàn)殡S著業(yè)務(wù)的不斷發(fā)展，用戶體量不斷增長，業(yè)務(wù)場景越來越復(fù)雜，為了不斷滿足這些需求，對系統(tǒng)的要求也就自然越來越高，所以，這才是系統(tǒng)架構(gòu)不斷演變的根本原因。
通常情況下，互聯(lián)網(wǎng)系統(tǒng)技術(shù)架構(gòu)的演變大致會經(jīng)歷以下幾個階段：
在云服務(wù)越來越成熟的今天，以下，筆者對各階段的技術(shù)架構(gòu)進(jìn)行簡單說明：
1、單節(jié)點(diǎn)架構(gòu)
在互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的初期，通常是一些嘗試性的產(chǎn)品探索/試驗(yàn)，而這些需求往往就是需求提出者的一個瞬間想法/點(diǎn)子，衍生完善而來。其需要的是快速實(shí)現(xiàn)其創(chuàng)意，并快速投放到市場驗(yàn)證，然后不斷收集市場反饋，完善整體的產(chǎn)品邏輯，因此，其典型特點(diǎn)就是時(shí)效要求高、產(chǎn)品邏輯不夠完善、不確定性大。
在這一階段，對技術(shù)架構(gòu)通常沒有太高的要求，只需要實(shí)現(xiàn)基本的業(yè)務(wù)功能就行，從而技術(shù)投入自然也就不大，因此，單節(jié)點(diǎn)架構(gòu)是比較適合的。即通常所說的，所有代碼寫在一個工程中，應(yīng)用、存儲等服務(wù)部署在一臺機(jī)器上。技術(shù)人員在這一階段最關(guān)鍵的在于保持良好的編程習(xí)慣、盡量預(yù)留演進(jìn)余地。
當(dāng)然，在云服務(wù)日漸成熟的今天，單節(jié)點(diǎn)架構(gòu)通常如下圖所示：
即，技術(shù)人員只需要將自己的業(yè)務(wù)代碼部署在云服務(wù)器上，數(shù)據(jù)直接存儲在云數(shù)據(jù)庫中，高效且可靠性較高。（當(dāng)然，也可以直接在云服務(wù)器上自己搭建數(shù)據(jù)庫來存儲，但現(xiàn)在一般不會/不需要這么做了）
2、集群架構(gòu)
隨著業(yè)務(wù)的發(fā)展，對系統(tǒng)的處理能力、高可用性也就提出了越來越高的要求，在單節(jié)點(diǎn)的基礎(chǔ)上，集群架構(gòu)應(yīng)運(yùn)而生，集群架構(gòu)通常如下圖所示：
在集群架構(gòu)階段，引入的技術(shù)/組件會慢慢變多，團(tuán)隊(duì)成員也會逐漸壯大，到了這一階段，說明核心產(chǎn)品形態(tài)已初步成型，并已有相對穩(wěn)定的、一定規(guī)模的流量，此時(shí)，技術(shù)團(tuán)隊(duì)開始迎來挑戰(zhàn)。在這一階段，技術(shù)團(tuán)隊(duì)最大的關(guān)鍵問題在于規(guī)范制定/團(tuán)隊(duì)建設(shè)/人才儲備。
Tips:
在云服務(wù)廠商的支持下，集群架構(gòu)已經(jīng)能夠支撐較大的用戶流量了。云服務(wù)器、云數(shù)據(jù)庫等云端基礎(chǔ)服務(wù)的支撐能力，也比前些年要好了很多，升級擴(kuò)容也方便了許多，已經(jīng)足夠滿足一般規(guī)模下的系統(tǒng)性能需求了。所以，不要覺得業(yè)務(wù)量一上來，就立馬要改系統(tǒng)架構(gòu)，因?yàn)檫@反而可能帶來不必要的麻煩。有時(shí)，直接通過升級云服務(wù)器/云數(shù)據(jù)庫等的配置，就可以解決問題了。（通常來說，常規(guī)業(yè)務(wù)場景下，通過一些優(yōu)化改造，頂住1萬以內(nèi)的QPS是沒有太大問題的）。
3、分布式集群架構(gòu)
隨著業(yè)務(wù)的進(jìn)一步發(fā)展，系統(tǒng)流量越來越大，業(yè)務(wù)復(fù)雜度越來越高，需求迭代越來越頻繁，技術(shù)團(tuán)隊(duì)成員也快速發(fā)展（50人以上），此時(shí)，團(tuán)隊(duì)協(xié)作、業(yè)務(wù)響應(yīng)效率、系統(tǒng)“三高”訴求等問題日益凸顯，集群架構(gòu)的不足之處日漸明顯，此時(shí)，分布式集群架構(gòu)的改造工作，也就需要開始提上日程了。
分布式集群架構(gòu)簡易示意如下圖所示：
從集群架構(gòu)演變到分布式集群架構(gòu)，業(yè)務(wù)場景復(fù)雜度、技術(shù)復(fù)雜度都變地極高，繁雜的業(yè)務(wù)/技術(shù)需求，要求一個更專業(yè)的團(tuán)隊(duì)去整體協(xié)作支撐。在這一階段，技術(shù)團(tuán)隊(duì)的關(guān)鍵問題在于技術(shù)選型/團(tuán)隊(duì)協(xié)作/工具化自動化/業(yè)務(wù)重構(gòu) 。（實(shí)際系統(tǒng)架構(gòu)情況要遠(yuǎn)遠(yuǎn)復(fù)雜得多，此處只是簡單示意）
Tips:
分布式集群架構(gòu)改造過程中，需要對業(yè)務(wù)進(jìn)行合理的梳理與服務(wù)劃分，否則，技術(shù)架構(gòu)的改造不但不能解決實(shí)際問題，反而可能帶來一系列的麻煩，那就真的成了“毒藥”了。
4、未來架構(gòu)
未來系統(tǒng)架構(gòu)到底會往哪個方向發(fā)展，是往ServiceMesh方向發(fā)展，還是往Serverless方向發(fā)展，異或是別的方向？筆者也說不好，雖然這些技術(shù)架構(gòu)方案都在某些方面體現(xiàn)了一些優(yōu)越性，看起來設(shè)計(jì)理念確實(shí)很好，但是目前為止，筆者還沒有看到太多成功落地實(shí)施的、較大規(guī)模系統(tǒng)的相關(guān)案例。所以，此處筆者也就不多妄言了。
但是，筆者以為，有一點(diǎn)趨勢還是比較明顯的，那就是，云服務(wù)在未來技術(shù)架構(gòu)中，將扮演越來越重要的角色。未來，對絕大多數(shù)中小企業(yè)來說，技術(shù)架構(gòu)的'云化'將是必然的選擇；與此同時(shí)，隨著云服務(wù)的日益完善，低代碼化也將成為一個重要的、解決實(shí)際業(yè)務(wù)問題的一種選擇。
Tips:
微服務(wù)架構(gòu)、容器化部署架構(gòu)、SOA架構(gòu)、混合云架構(gòu)等等，筆者以為，其實(shí)都可以看做是集群架構(gòu)/分布式集群架構(gòu)的延伸與變種，雖然具體概念上有些不同，但大體上來說，基本上在相應(yīng)的設(shè)計(jì)理念邊界上，并沒有顛覆性的區(qū)別。
以上，就是對互聯(lián)網(wǎng)系統(tǒng)架構(gòu)演進(jìn)過程的簡單描述，作為一名技術(shù)人員，通常來說，大概率是不會完整經(jīng)歷以上過程的，能親身經(jīng)歷一個大型互聯(lián)網(wǎng)系統(tǒng)架構(gòu)從0到1的演變過程，實(shí)屬幸運(yùn)。
以上所述，在不少書籍/教程中基本都有相關(guān)的詳細(xì)描述，筆者就不再過多贅述了，此處筆者再說幾點(diǎn)其它地方可能提的比較少的，關(guān)于系統(tǒng)架構(gòu)演變相關(guān)的一些問題。
1、選擇分布式集群架構(gòu)的原因
采用分布式集群架構(gòu)（微服務(wù)），最關(guān)鍵的原因，不僅僅是為了解決系統(tǒng)性能問題，很大一部分原因，是為了解決業(yè)務(wù)迭代、團(tuán)隊(duì)協(xié)作、開發(fā)調(diào)試、編譯部署等問題。這是因?yàn)?，隨著系統(tǒng)業(yè)務(wù)復(fù)雜度的提升、團(tuán)隊(duì)成員的增加，對單節(jié)點(diǎn)架構(gòu)/集群架構(gòu)來說，除了性能問題外，業(yè)務(wù)耦合度高且邏輯不清晰、業(yè)務(wù)版本迭代不便且協(xié)作開發(fā)易沖突、代碼調(diào)試繁瑣且部署風(fēng)險(xiǎn)大，等相關(guān)問題會逐漸變成主要矛盾，而通過分布式架構(gòu)改造，就能較好地解決這些問題。
2、分布式集群架構(gòu)改造的關(guān)鍵點(diǎn)
在技術(shù)架構(gòu)演變的過程中，決不是簡單粗暴地?cái)U(kuò)機(jī)器、拆代碼、分服務(wù)，在不斷演進(jìn)過程中，難點(diǎn)其實(shí)在于對業(yè)務(wù)模型的完善設(shè)計(jì)，對業(yè)務(wù)流程的重新梳理，也就是業(yè)務(wù)架構(gòu)。
如果說，從單節(jié)點(diǎn)架構(gòu)/集群架構(gòu)過渡到分布式集群架構(gòu)的過程中，只是選一個分布式服務(wù)框架，然后將原有代碼結(jié)構(gòu)進(jìn)行簡單拆分成各個服務(wù)包，再通過框架來進(jìn)行調(diào)用，那么，這決不算完成了分布式架構(gòu)的演進(jìn)?，F(xiàn)如今，社區(qū)已有較為成熟的整套分布式集群架構(gòu)解決方案，在系統(tǒng)改造過程中，分布式框架的選型與技術(shù)方案的制定，已不再是最困難的問題。相對而言，在改造過程中，如何對現(xiàn)有業(yè)務(wù)邏輯進(jìn)行整體梳理與服務(wù)劃分改造，才是重點(diǎn)與難點(diǎn)，因?yàn)樵谶@一階段，通常會面臨改造服務(wù)與線上服務(wù)同時(shí)運(yùn)行的兼容問題，以及其它可能存在的較為沉重的歷史包袱。（這也是DDD最近幾年日趨火熱的原因之一吧）
3、架構(gòu)演變需要考慮的因素
技術(shù)是服務(wù)于業(yè)務(wù)的，不能完全脫離于業(yè)務(wù)談技術(shù)架構(gòu)，所以，在進(jìn)行技術(shù)架構(gòu)設(shè)計(jì)/選型時(shí)，要充分結(jié)合實(shí)際業(yè)務(wù)場景進(jìn)行取舍與平衡，切忌盲目隨大流，人云亦云。更進(jìn)一步，業(yè)務(wù)通常都是基于一定的商業(yè)目的的（政府/公益組織等不在其中），所以，在做技術(shù)架構(gòu)時(shí)，商業(yè)因素有時(shí)也是需要考慮的。有時(shí)，甚至政策/法律/語言文化等因素，可能也需要有所考量。
4、架構(gòu)演進(jìn)的終點(diǎn)
技術(shù)架構(gòu)是一個非常復(fù)雜的系統(tǒng)工程，從宏觀上的整體把握到基本的代碼實(shí)現(xiàn)，從服務(wù)端架構(gòu)到客戶端架構(gòu)，從基礎(chǔ)中間件到異構(gòu)系統(tǒng)，凡此種種，浩如煙海，學(xué)無止境，我們只是站在前人的肩膀上，才不至于太過狼狽，要時(shí)刻心懷敬畏之心。分布式集群架構(gòu)的代碼改造完成只是萬里長征的第一步，后續(xù)，服務(wù)治理才是分布式集群架構(gòu)中的重點(diǎn)與難點(diǎn)。可以說，只要業(yè)務(wù)場景有需要，技術(shù)架構(gòu)演進(jìn)，永無止境。
5、架構(gòu)演進(jìn)技術(shù)選型的原則
現(xiàn)如今，大多數(shù)技術(shù)痛點(diǎn)，社區(qū)都有許多成套的相關(guān)解決方案，在這個時(shí)候，切忌盲目套用，一籃子全都使用了，造成整個技術(shù)體系異常龐雜，開發(fā)/維護(hù)都較為繁瑣。需要注意的是，技術(shù)架構(gòu)不是做的越多越好，相反，應(yīng)當(dāng)盡量少做，大道至簡。我們應(yīng)該結(jié)合自己的實(shí)際情況，如業(yè)務(wù)場景、團(tuán)隊(duì)整體技術(shù)棧、成員技術(shù)水平等綜合考量，盡量選擇通用的、成熟的相關(guān)解決方案就可以了，不需要追求所謂“前沿”但還不夠成熟的相關(guān)技術(shù)，簡潔而清晰的，往往是最適合的。
6、架構(gòu)演進(jìn)落地的關(guān)鍵點(diǎn)
系統(tǒng)架構(gòu)的演進(jìn)過程，其實(shí)就是一個不斷取舍/平衡的過程，“三高”系統(tǒng)架構(gòu)有常用的三板斧（擴(kuò)容、緩存、流控），技術(shù)架構(gòu)演變到最后，要實(shí)際落地的話，也會有三個關(guān)鍵問題需要處理，那就是業(yè)務(wù)、技術(shù)、團(tuán)隊(duì)協(xié)作之間這三者的平衡。
業(yè)務(wù)，指的是實(shí)際業(yè)務(wù)場景與業(yè)務(wù)迭代訴求；技術(shù)，指的是技術(shù)選型與制定的技術(shù)方案；團(tuán)隊(duì)協(xié)作，指的是技術(shù)團(tuán)隊(duì)內(nèi)部之間（基礎(chǔ)架構(gòu)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)、業(yè)務(wù)開發(fā)團(tuán)隊(duì)等）、跨部門團(tuán)隊(duì)之間的溝通與協(xié)作。如果這三者之間的關(guān)系沒有處理/協(xié)調(diào)好的話，就會出現(xiàn)一個嚴(yán)重的問題，那就是技術(shù)方案都制定/預(yù)研完成了，結(jié)果實(shí)際推廣落地時(shí)，卻很難推進(jìn)，甚至因長時(shí)間推不動而最終不了了之。（實(shí)際工作中，技術(shù)架構(gòu)的落地，除了技術(shù)本身的問題，人的問題往往更難搞）
7、架構(gòu)演進(jìn)中的安全問題
在互聯(lián)網(wǎng)技術(shù)架構(gòu)的演進(jìn)過程中，系統(tǒng)安全問題通常沒有被重點(diǎn)考慮，這點(diǎn)需要引起我們的重視。造成這種情況，應(yīng)該說有多方面的原因吧，筆者以為，主要原因有以下幾個：
一是云服務(wù)廠商的日趨完善。云服務(wù)使得開發(fā)/部署一個基本的、可靠性較高的應(yīng)用較為簡單，更進(jìn)一步的是，云服務(wù)廠商本身，從整體上做了大量的安全方面的基礎(chǔ)工作，如防火墻(硬件、軟件)、風(fēng)控識別、數(shù)據(jù)保護(hù)等等。因此，相對于早期的自建機(jī)房/服務(wù)器托管方式，系統(tǒng)層面的常規(guī)安全風(fēng)險(xiǎn)大大降低，即便出現(xiàn)相關(guān)風(fēng)險(xiǎn)的時(shí)候，云服務(wù)廠商也會及時(shí)解決/協(xié)助解決。而這，也在很大程度上讓我們往往對安全問題不夠敏感/重視。
二是第三方基礎(chǔ)服務(wù)商的完善。一個系統(tǒng)所涉及的關(guān)鍵業(yè)務(wù)流程中的支付(支付寶、微信等)、消息推送(短信、郵件等)、風(fēng)險(xiǎn)識別(涉黃、敏感信息等)等等，都有成熟的服務(wù)商提供相關(guān)服務(wù)，通常只需要接入相應(yīng)SDK即可快速實(shí)現(xiàn)相關(guān)能力，簡便高效。（第三方基礎(chǔ)服務(wù)供應(yīng)商，一般都有一套相對成熟的安全/風(fēng)控機(jī)制）
三是社區(qū)開發(fā)框架的成熟完善。在今天的互聯(lián)網(wǎng)技術(shù)生態(tài)中，類似Spring/Mybatis之類的開發(fā)框架已越來越成熟穩(wěn)定，幾乎是行業(yè)標(biāo)配，而得益于這些框架的完善，我們已不需要(或只需少量配置)就可處理/避免大多數(shù)常見的安全問題。
那么，我們是否真的可以忽略安全問題呢？當(dāng)然不是，因?yàn)轭愃朴脩裘舾袛?shù)據(jù)保護(hù)問題、“羊毛黨”問題等等、時(shí)刻警醒者我們，安全問題，無處不在。
最后
工作在云服務(wù)廠商日漸成熟的今天，我們非常幸運(yùn)，也非常不幸…
聯(lián)系客服
