一、前言
說到網際網路系統架構，在網際網路行業日漸成熟的今天，一談到這背後的技術體系，很多人腦海中可能就會浮現從網上看到的，一個個龐大的知識圖譜，能說地清楚其中一二的同學，自然是志得意滿，而對于新入行的同學來說，則可能直接就勸退了。
那麼，我們是否需要對所有的這些相關技術，都全部學習掌握呢？筆者以為，大可不必過度焦慮，需要明白的是，一個龐大而複雜的網際網路架構體系，必然是由一個強大的團隊來共同支撐維護的，團隊成員各司其職、各盡所長，而這也就是團隊的力量。
當然，對于網際網路系統架構的演進過程，相信很多人都有自己的了解，從單體應用到分布式應用、從開發架構到中間件技術、從容器化到雲原生等等，不一而足。不過，在這龐雜的技術體系中，從宏觀上理清其演變過程中的關鍵節點與可能面臨的關鍵問題，對于我們了解一個大型網際網路系統的架構，是很有裨益的。
二、大型網際網路系統架構常見演變過程
系統架構應當是基于具體業務場景的，脫離了具體業務談技術架構，難免有空中樓閣、鏡花水月之嫌。系統架構常見的演變過程，網上的相關文章不勝枚舉，不過，為了保持本文整體的完整性與連貫性，筆者以為，仍需從基本的系統架構演進過程說起，綱舉則目張，先對常見大型網際網路系統架構的演進過程有一個整體上的大緻梳理，再說演進過程中常見的問題，也就水到渠成了。
“一個優秀的大型網際網路系統架構，不是設計出來的，而是不斷演進而來的” ，類似的觀點，相信大家都有所了解，也有所思考，但是，為什麼是這樣的呢？是技術同學技術能力不夠，設計不出優秀的系統架構嗎，還是說技術同學寫的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之類的開發架構已越來越成熟穩定，幾乎是行業标配，而得益于這些架構的完善，我們已不需要(或隻需少量配置)就可處理/避免大多數常見的安全問題。
那麼，我們是否真的可以忽略安全問題呢？當然不是，因為類似使用者敏感資料保護問題、“羊毛黨”問題等等、時刻警醒着我們，安全問題，無處不在。
工作在雲服務廠商日漸成熟的今天，我們非常幸運，也非常不幸…...
作者丨老農小江
來源丨網址：https://blog.csdn.net/cndmss/article/details/123636370
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
更多精彩内容
11月19日下午14:00，dbaplus社群攜手中國銀行，圍繞“中國銀行運維轉型與靈活開發探索實踐”這一主題開展線上直播分享，針對運維監控、混沌工程、DevOps等内容進行深度探讨，為金融業的數字化轉型提供更多新思路。
直播位址：http://z-mz.cn/5t8OC
關于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關注公衆号【dbaplus社群】，擷取更多原創技術文章和精選工具下載下傳