大型網際網路系統架構演進 BATJ其實無需神化

　　 一、前言

　　說到網際網路系統架構，在網際網路行業日漸成熟的今天，一談到這背後的技術體系，很多人腦海中可能就會浮現從網上看到的，一個個龐大的知識圖譜，能說地清楚其中一二的同學，自然是志得意滿，而對於新入行的同學來說，則可能直接就勸退了。

　　那麼，我們是否需要對所有的這些相關技術，都全部學習掌握呢？筆者以為，大可不必過度焦慮，需要明白的是，一個龐大而複雜的網際網路架構體系，必然是由一個強大的團隊來共同支撐維護的，團隊成員各司其職、各盡所長，而這也就是團隊的力量。

　　當然，對於網際網路系統架構的演進過程，相信很多人都有自己的理解，從單體應用到分散式應用、從開發框架到中介軟體技術、從容器化到雲原生等等，不一而足。不過，在這龐雜的技術體系中，從宏觀上理清其演變過程中的關鍵節點與可能面臨的關鍵問題，對於我們理解一個大型網際網路系統的架構，是很有裨益的。

　　 二、大型網際網路系統架構常見演變過程

　　系統架構應當是基於具體業務場景的，脫離了具體業務談技術架構，難免有空中樓閣、鏡花水月之嫌。系統架構常見的演變過程，網上的相關文章不勝列舉，不過，為了保持本文整體的完整性與連貫性，筆者以為，仍需從基本的系統架構演進過程說起，綱舉則目張，先對常見大型網際網路系統架構的演進過程有一個整體上的大致梳理，再說演進過程中常見的問題，也就水到渠成了。

　　“一個優秀的大型網際網路系統架構，不是設計出來的，而是不斷演進而來的” ，類似的觀點，相信大家都有所瞭解，也有所思考，但是，為什麼是這樣的呢？是技術同學技術能力不夠，設計不出優秀的系統架構嗎，還是說技術同學寫的BUG太多，需要不斷修復？

　　筆者以為，都不是，架構的演變，其本質在於技術是服務於業務需求的，而業務需求是不斷變化發展的，而這，天生就註定了技術架構的不斷演變，是一種必然的選擇。也正是因為隨著業務的不斷髮展，使用者體量不斷增長，業務場景越來越複雜，為了不斷滿足這些需求，對系統的要求也就自然越來越高，所以，這才是系統架構不斷演變的根本原因。

　　通常情況下，網際網路系統技術架構的演變大致會經歷以下幾個階段：　　

　　在雲服務越來越成熟的今天，以下，筆者對各階段的技術架構進行簡單說明。

　　1、單節點架構

　　在網際網路業務發展的初期，通常是一些嘗試性的產品探索/試驗，而這些需求往往就是需求提出者的一個瞬間想法/點子，衍生完善而來。其需要的是快速實現其創意，並快速投放到市場驗證，然後不斷收集市場反饋，完善整體的產品邏輯，因此，其典型特點就是時效要求高、產品邏輯不夠完善、不確定性大。

　　在這一階段，對技術架構通常沒有太高的要求，只需要實現基本的業務功能就行，從而技術投入自然也就不大，因此，單節點架構是比較適合的。即通常所說的，所有程式碼寫在一個工程中，應用、儲存等服務部署在一臺機器上。技術人員在這一階段最關鍵的在於保持良好的程式設計習慣、儘量預留演進餘地。

　　當然，在雲服務日漸成熟的今天，單節點架構通常如下圖所示：　　

　　即，技術人員只需要將自己的業務程式碼部署在雲伺服器上，資料直接儲存在雲資料庫中，高效且可靠性較高。（當然，也可以直接在雲伺服器上自己搭建資料庫來儲存，但現在一般不會/不需要這麼做了）

　　2、叢集架構

　　隨著業務的發展，對系統的處理能力、高可用性也就提出了越來越高的要求，在單節點的基礎上，叢集架構應運而生，叢集架構通常如下圖所示：　　

　　在叢集架構階段，引入的技術/元件會慢慢變多，團隊成員也會逐漸壯大，到了這一階段，說明核心產品形態已初步成型，並已有相對穩定的、一定規模的流量，此時，技術團隊開始迎來挑戰。在這一階段，技術團隊最大的關鍵問題在於規範制定/團隊建設/人才儲備。

　　在雲服務廠商的支援下，叢集架構已經能夠支撐較大的使用者流量了。雲伺服器、雲資料庫等雲端基礎服務的支撐能力，也比前些年要好了很多，升級擴容也方便了許多，已經足夠滿足一般規模下的系統效能需求了。所以，不要覺得業務量一上來，就立馬要改系統架構，因為這反而可能帶來不必要的麻煩。有時，直接透過升級雲伺服器/雲資料庫等的配置，就可以解決問題了。（通常來說，常規業務場景下，透過一些最佳化改造，頂住1萬以內的QPS是沒有太大問題的）。

　　3、分散式叢集架構

　　隨著業務的進一步發展，系統流量越來越大，業務複雜度越來越高，需求迭代越來越頻繁，技術團隊成員也快速發展（50人以上），此時，團隊協作、業務響應效率、系統“三高”訴求等問題日益凸顯，叢集架構的不足之處日漸明顯，此時，分散式叢集架構的改造工作，也就需要開始提上日程了。

　　分散式叢集架構簡易示意如下圖所示：　　

　　從叢集架構演變到分散式叢集架構，業務場景複雜度、技術複雜度都變得極高，繁雜的業務/技術需求，要求一個更專業的團隊去整體協作支撐。在這一階段，技術團隊的關鍵問題在於技術選型/團隊協作/工具化自動化/業務重構 。（實際系統架構情況要遠遠複雜得多，此處只是簡單示意）

　　分散式叢集架構改造過程中，需要對業務進行合理的梳理與服務劃分，否則，技術架構的改造不但不能解決實際問題，反而可能帶來一系列的麻煩，那就真的成了“毒藥”了。

　　4、未來架構

　　未來系統架構到底會往哪個方向發展，是往ServiceMesh方向發展，還是往Serverless方向發展，或是別的方向？筆者也說不好，雖然這些技術架構方案都在某些方面體現了一些優越性，看起來設計理念確實很好，但是目前為止，筆者還沒有看到太多成功落地實施的、較大規模系統的相關案例。所以，此處筆者也就不多妄言了。

　　但是，筆者以為，有一點趨勢還是比較明顯的，那就是，雲服務在未來技術架構中，將扮演越來越重要的角色。未來，對絕大多數中小企業來說，技術架構的"雲化"將是必然的選擇；與此同時，隨著雲服務的日益完善，低程式碼化也將成為一個重要的、解決實際業務問題的一種選擇。

　　微服務架構、容器化部署架構、SOA架構、混合雲架構等等，筆者以為，其實都可以看做是叢集架構/分散式叢集架構的延伸與變種，雖然具體概念上有些不同，但大體上來說，基本上在相應的設計理念邊界上，並沒有顛覆性的區別。

　　以上，就是對網際網路系統架構演進過程的簡單描述，作為一名技術人員，通常來說，大機率是不會完整經歷以上過程的，能親身經歷一個大型網際網路系統架構從0到1的演變過程，實屬幸運。

　　 三、架構演變不常說的一些問題

　　以上所述，在不少書籍/教程中基本都有相關的詳細描述，筆者就不再過多贅述了，此處筆者再說幾點其它地方可能提的比較少的，關於系統架構演變相關的一些問題。

　　1、選擇分散式叢集架構的原因

　　採用分散式叢集架構（微服務），最關鍵的原因，不僅僅是為了解決系統效能問題，很大一部分原因，是為了解決業務迭代、團隊協作、開發除錯、編譯部署等問題。這是因為，隨著系統業務複雜度的提升、團隊成員的增加，對單節點架構/叢集架構來說，除了效能問題外，業務耦合度高且邏輯不清晰、業務版本迭代不便且協作開發易衝突、程式碼除錯繁瑣且部署風險大，等相關問題會逐漸變成主要矛盾，而透過分散式架構改造，就能較好地解決這些問題。

　　2、分散式叢集架構改造的關鍵點

　　在技術架構演變的過程中，絕不是簡單粗暴地擴機器、拆程式碼、分服務，在不斷演進過程中，難點其實在於對業務模型的完善設計，對業務流程的重新梳理，也就是業務架構。

　　如果說，從單節點架構/叢集架構過渡到分散式叢集架構的過程中，只是選一個分散式服務框架，然後將原有程式碼結構進行簡單拆分成各個服務包，再透過框架來進行呼叫，那麼，這絕不算完成了分散式架構的演進。現如今，社群已有較為成熟的整套分散式叢集架構解決方案，在系統改造過程中，分散式框架的選型與技術方案的制定，已不再是最困難的問題。相對而言，在改造過程中，如何對現有業務邏輯進行整體梳理與服務劃分改造，才是重點與難點，因為在這一階段，通常會面臨改造服務與線上服務同時執行的相容問題，以及其它可能存在的較為沉重的歷史包袱。（這也是DDD最近幾年日趨火熱的原因之一吧）

　　3、架構演變需要考慮的因素

　　技術是服務於業務的，不能完全脫離於業務談技術架構，所以，在進行技術架構設計/選型時，要充分結合實際業務場景進行取捨與平衡，切忌盲目隨大流，人云亦云。更進一步，業務通常都是基於一定的商業目的的（政府/公益組織等不在其中），所以，在做技術架構時，商業因素有時也是需要考慮的。有時，甚至政策/法律/語言文化等因素，可能也需要有所考量。

　　4、架構演進的終點

　　技術架構是一個非常複雜的系統工程，從宏觀上的整體把握到基本的程式碼實現，從服務端架構到客戶端架構，從基礎中介軟體到異構系統，凡此種種，浩如煙海，學無止境，我們只是站在前人的肩膀上，才不至於太過狼狽，要時刻心懷敬畏之心。分散式叢集架構的程式碼改造完成只是萬里長征的第一步，後續，服務治理才是分散式叢集架構中的重點與難點。可以說，只要業務場景有需要，技術架構演進，永無止境。

　　5、架構演進技術選型的原則

　　現如今，大多數技術痛點，社群都有許多成套的相關解決方案，在這個時候，切忌盲目套用，一籃子全都使用了，造成整個技術體系異常龐雜，開發/維護都較為繁瑣。需要注意的是，技術架構不是做得越多越好，相反，應當儘量少做，大道至簡。我們應該結合自己的實際情況，如業務場景、團隊整體技術棧、成員技術水平等綜合考量，儘量選擇通用的、成熟的相關解決方案就可以了，不需要追求所謂“前沿”但還不夠成熟的相關技術，簡潔而清晰的，往往是最適合的。　　

　　6、架構演進落地的關鍵點

　　系統架構的演進過程，其實就是一個不斷取捨/平衡的過程，“三高”系統架構有常用的三板斧（擴容、快取、流控），技術架構演變到最後，要實際落地的話，也會有三個關鍵問題需要處理，那就是業務、技術、團隊協作之間這三者的平衡。　　

　　業務，指的是實際業務場景與業務迭代訴求；技術，指的是技術選型與制定的技術方案；團隊協作，指的是技術團隊內部之間（基礎架構團隊、運維團隊、業務開發團隊等）、跨部門團隊之間的溝通與協作。如果這三者之間的關係沒有處理/協調好的話，就會出現一個嚴重的問題，那就是技術方案都制定/預研完成了，結果實際推廣落地時，卻很難推進，甚至因長時間推不動而最終不了了之。（實際工作中，技術架構的落地，除了技術本身的問題，人的問題往往更難搞）　　

　　7、架構演進中的安全問題

　　在網際網路技術架構的演進過程中，系統安全問題通常沒有被重點考慮，這點需要引起我們的重視。造成這種情況，應該說有多方面的原因吧，筆者以為，主要原因有以下幾個：

　　1）雲服務廠商的日趨完善

　　雲服務使得開發/部署一個基本的、可靠性較高的應用較為簡單，更進一步的是，雲服務廠商本身，從整體上做了大量的安全方面的基礎工作，如防火牆(硬體、軟體)、風控識別、資料保護等等。因此，相對於早期的自建機房/伺服器託管方式，系統層面的常規安全風險大大降低，即便出現相關風險的時候，雲服務廠商也會及時解決/協助解決。而這，也在很大程度上讓我們往往對安全問題不夠敏感/重視。

　　2）第三方基礎服務商的完善

　　一個系統所涉及的關鍵業務流程中的支付(支付寶、微信等)、訊息推送(簡訊、郵件等)、風險識別(涉黃、敏感資訊等)等等，都有成熟的服務商提供相關服務，通常只需要接入相應SDK即可快速實現相關能力，簡便高效。（第三方基礎服務供應商，一般都有一套相對成熟的安全/風控機制）

　　3）社群開發框架的成熟完善

　　在今天的網際網路技術生態中，類似Spring/Mybatis之類的開發框架已越來越成熟穩定，幾乎是行業標配，而得益於這些框架的完善，我們已不需要(或只需少量配置)就可處理/避免大多數常見的安全問題。

　　那麼，我們是否真的可以忽略安全問題呢？當然不是，因為類似使用者敏感資料保護問題、“羊毛黨”問題等等、時刻警醒著我們，安全問題，無處不在。

　　工作在雲服務廠商日漸成熟的今天，我們非常幸運，也非常不幸…...