分佈式系統實戰

時間 2021-02-13

標籤前端 git github redis 數據庫編程後端緩存安全性能優化欄目系統架構简体版

原文原文鏈接

導語：記得在本身大學畢業的2006年到以後近五年的工做裏，源於工做經歷和有限的視野，幾乎對「分佈式系統」沒有任何概念。固然，彼時的互聯網/移動互聯網還未對咱們的生活呈覆蓋顛覆之勢，不少網絡應用採用傳統的集中式服務即可應對。可是隨着互聯網大潮的風起雲涌，出現了愈來愈多的細分大流量網站及應用，網民體量也如滾落雪球通常愈來愈大，這種狀況下分佈式的概念幾乎在技術圈「家喻戶曉」，也成了咱們追逐的另外一顆時代「銀彈」。我也不例外，可是隻是由於身處於某幾乎無互聯網氛圍的二線城市和保守封閉的技術氛圍中，因此對分佈式系統的理解、掌握只能是本身一步步學習、實踐而來，可是反過來也有了不少踏實的實踐體會。前端

剛纔提到分佈式系統產生的背景之一就是有了不少大型網站、應用。git

這些系統的特色是：高併發、大流量；高可用；海量數據；用戶分佈普遍，網絡狀況複雜，安全環境惡劣；需求快速變動，迭代式發展，發佈頻繁。github
這些系統的核心架構要素：性能、可用性、伸縮性、擴展性和安全性。redis

來看看分佈式系統的特色：數據庫

異構性：使得用戶能在大量異構計算機和網絡上訪問服務和運行應用程序，好比容許硬件、操做系統、編程語言、開發者等的多樣性和差異。編程
開放性（擴展性）：使系統能以不一樣的方式被擴展和實現，好比經過發佈系統的關鍵接口、基於一致的通訊機制和網絡協議擴展其餘應用。後端
可伸縮性：在不一樣的用戶規模下經過對資源的調節依然能有效且高效的運轉，好比經過縱向的伸縮來增強硬件、經過橫向的伸縮來增長服務器等。緩存
併發性：保持用戶對共享資源操做的正確性，好比CAP理論中的C（一致性）的要求。安全
高可用性：經過性能優化、安全性、故障處理提升可用性，好比採用高性能的編程模型，安全的隔離和過濾機制，自動化故障檢測、容錯、故障修復、冗餘等。性能優化

分佈式系統的優點：

下降不一樣模塊開發團隊間的協同成本，業務響應更迅捷。
大大下降系統間的耦合度以及總體複雜度，各個開發團隊可專一於各自的業務模塊。
避免了個別模塊的錯誤給總體帶來的影響。
業務可拆分、可擴展後解放了對單服務資源的依賴。
作到針對性的業務能力擴容，減小沒必要要的資源浪費。

可見分佈式系統爲大型網站應用在技術和組織層面都提供了良好的解決和支撐。

分佈式系統相關的理論：

CAP理論：一個分佈式系統最多隻能同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance 指分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務）其中的兩項。
BASE理論：是指基本可用（Basically Avalilable）、柔性狀態（Soft State）、最終一致性（Eventual Consistency）。BASE是對CAP理論的延伸，核心思想是即便沒法作到強一致性，但應用能夠採用適合的方式達到最終一致性。

另外，如今常常有人問起分佈式架構理念與以前咱們常常說的SOA（面向服務的架構）和如今頗爲流行的微服務架構孰優孰劣。我我的認爲問優劣是不合理的，首先分佈式構架理念在二者中都有體現和應用。而對於做爲對比的SOA和微服務，這兩者在彼此適配的場景下均可以異曲同工的解決問題，都是好的架構理念。可是確實是也有區別和聯繫：

SOA的主要特性：

面向服務的分佈式計算
服務間鬆散耦合
支持服務的組裝
服務註冊和自動發現
以服務契約方式定義服務交互方式

微服務架構的典型特徵：

分佈式服務組成的系統
按照業務而不是按照技術來劃分組織
作有生命的產品而不是項目
智能化服務端點與傻瓜式服務編排
自動化運維
系統容錯
服務快速演化

上面主要講了對分佈式系統的概念認識，不少是對書籍和學習的總結。可是作到真正的理解就必須有實戰，拿其中一個本身親自架構編碼的即時聊天/用戶、設備上線系統的後臺架構爲例，此架構思路目前已經實踐應用在多個百萬級別的服務上。其實對於此架構的分佈式應用，本身並非在熟知分佈式理論的前提下設計的，而是基於其餘理念模型和在具體的業務實踐、組織協做過程當中演化而來的。

好比分層的架構設計，以前因爲主要作網絡安全和網絡編程工做，TCP/IP協議棧的分層設計深深影響了本身

把網絡層、業務邏輯層、數據層分離，網絡層支持負載均衡，業務層支持動態擴展，數據層支持分佈式存儲，各層均支持分佈式部署；如下是架構細化圖

對不一樣功能的模塊進行進程級的分離，用TCP來進行通信。這是受「《UNIX編程藝術》第7章——多道程序設計：分離進程爲獨立的功能「的理念影響，是否是和微服務的理念很像，並且基於TCP通訊的方式利於進行分佈式部署。Unix最具特色的程序模塊化技法就是將大型程序分解成多個協做進程，並專一於考慮這些子進程間的接口和通信方式；
通用技術模塊和業務應用模塊分離，好比網關服務、上線服務實現網絡接入和協議轉發功能不承載業務邏輯，由具體的應用進程處理業務。網關服務就相似於Nginx，用戶的請求首先會經過前端接入層（Nginx）分發到後端的應用集羣上，另外經過在網關上實現的安全過濾（好比域名IP類、協議祕鑰、黑名單）實現接入層限流、安全的主要工做。
無狀態的設計，將狀態、消息、業務數據類信息分離出業務進程，利用分佈式緩存（如redis），數據庫（關係型數據庫MySQL、非關係型數據庫MongoDB）存儲進行調用。這樣業務進程利於分佈式部署，數據服務也支持分佈式存儲。
服務間利用標準統一的協議進行信息交互，好比採用序列化協議Json和RESTful API設計，我我的比較推崇文本化的協議，容易令人理解也更容易記錄、分析、調試。這是深受「《Unix編程藝術》第5章——文本化：好協議產生好實踐」理念的影響。相比二進制協議，文本化協議能夠帶來互用性、透明性、可擴展性。
經過配置文件或者配置服務加載策略，對於不少靜態和動態的策略不要寫死在程序中，而是經過配置文件或者配置服務加載，這樣能夠快速部署發佈新功能、對服務進行無間斷的熱啓動。這也是「《Unix編程藝術》中分離原則：策略同機制分離，接口同引擎分離」原則的實踐。