什麼是分佈式架構？
分佈式架構是分佈式計算技術的應用和工具，其中J2EE技術應用較爲普遍，它簡化和規範多層分佈式企業應用系統的開發和部署，它能夠給分佈式應用軟件提供在各類技術間共享資源的平臺數據庫
分佈式架構發展
衆所周知，傳統架構單一無分層，模塊之間耦合性太高致使穩定性和擴展性較差，沒法知足互聯網高速迭代變化的腳步，技術架構也會發生很大變化。傳統架構逐漸分化爲分佈式架構。提供更穩定、容錯、高可用的特質。演變過程以下圖所示緩存
階段1
服務器
階段2微信
階段3
網絡
階段4
架構
階段5併發
分佈式架構設計理念和目標
設計理念：分佈式架構的核心理念按照必定維度（功能、業務、領域）等，對系統進行拆分，經過合理的拆分結構，實現各業務模塊解耦，同時經過系統級容錯設計，在廉價硬件基礎設施上構建起高可用、可擴展的開放技術體系。app
目標：設計目標能夠明確方向，經過設計驅動和方向的把控，朝着既定方向前行並最終實現目標。設計目標分爲如下方面：負載均衡
•系統拆分框架
a.以業務爲導向，充分了解系統業務模型，按不一樣層面的業務模型上能夠劃分爲主模型、次模型。業務模型在必定的比例上可以凸顯出系統的業務領域及邊界
b.業務依賴範圍，因爲業務存在重複依賴，從業務邊界中按照業務功能去細分
c.把拆分結構圖梳理出來，按照系統周邊影響從小到大逐漸切換
d.拆分過程當中儘可能不要引入新的技術或者方案，如需討論評估後再實施
•業務模塊解耦
拆分以前可能模塊和模塊之間、系統和系統之間有很是強的依賴，因此咱們在拆分過程當中須要思考，哪些模塊須要減小依賴，依賴越少，獨立性越強
•系統容錯
a.架構設計層面(重試、服務降級、熔斷和限流)
b.業務功能層面(冪等、異步處理、事務補償機制)
•高可用
a.單點系統面臨嚴重高可用問題，因此在設計過程當中要儘可能避免系統的單點出現，保證系統處於多機狀態，俗稱冗餘。冗餘指重複配置系統某些部件，當系統發生故障不可用時，冗餘配置的部件介入並承擔故障部件的工做，減小系統的故障時間
b.經過設計和監控能夠提升系統正常提供服務的可靠性，那麼，如何才能保障系統的高可用
系統初期
系統中期
系統後期
高可用監控以下：
調用關係圖
波狀圖
分佈式架構應用場景
•適用於對數據密集/實時要求比較高的項目或系統•適用於對服務器高可用運用指數較高的系統•適用於大型業務複雜/統計類系統
單體消息
集羣消息
服務器結構圖以下：
分佈式架構難點
•網絡因素
網絡延遲：延遲是指在傳輸介質中傳輸所用的時間，如部署在同個機房，網絡IO傳輸相對較快，可是不少公司爲了增長系統的可用性，有多套機房（線上、線下）等，此時會面臨跨機房、跨網絡傳輸。尤爲跨IDC，網絡IO會存在不肯定性，出現延遲、超時等狀況，你們都知道寬帶有瓶頸能夠換網卡，但從根本上不能解決物理延遲。因爲這些現象會給整個設計帶來總體性的難點，咱們在作分佈式架構設計的同時須要考慮這些要素，而且提供相關高效解決方案，從而規避此問題
網絡故障：若出現網絡故障問題，能夠先了解數據是以什麼協議方式在網絡中傳輸致使丟包、錯亂。而後採用比較穩定的TCP網絡協議進行傳輸
•服務可用性
a.因爲探針監控是定時去請求訪問服務器，經過請求迴應來收集服務器狀態。定時需設置在合理範圍值內，過短會給服務器帶來壓力，太長會致使不能及時收集報錯信息，而錯過最佳時機。基於以上狀況，能夠採用服務器集羣化的方式，根據系統場景，設置合理探針請求頻率，當發現異常及時剔除替換
b. 爲了保證服務器正常運行，可對服務器進行監控，如探針、心跳檢測等，而這些僅僅是針對服務器的運行數據和日誌分析。爲了提升服務器服務的可用性，可進一步實施服務器負載均衡、主從切換、故障轉移等
•數據一致性
a. 能夠從系統構建層面減小這種現象發生，採用分佈式事務進行處理，存在犧牲一部分性能去彌補數據一致性
b. 因爲數據架構須要提供多節點部署，不一樣節點之間通訊存在數據差別，在不少場景下會每每產生髒數據、異常數據，讓業務不能正常運轉。數據一致性指，關聯數據之間的邏輯關係是否正確和完整，那麼分佈式狀況下如何讓不一樣模塊之間的數據保證完整性、一致性
分佈式架構解決痛點
•系統宕機
系統業務量逐漸增多，致使系統壓力增大，經過監控和各方面指標發現系統頻繁報警，經過優化讓系統變的穩定，下降負載。最直接的方式是增長系統容量，調整系統參數，可是經過硬件擴展並不是解決問題的最優方式，會存在如下弊端
硬件設備費用高額後續會帶來更大的維護代價
進一步優化過程須要垂直或者水平拆分業務系統，按照必定維度拆分紅多個模塊，下降耦合性，經過合理的設計方案，從端到端、點到點優化，讓系統變得健壯，爲後續複雜業務提供模塊化管理和運營。
分佈式的架構體系具備良好的橫向擴展性，經過橫向擴展機器可以快速高效提升系統的併發量和吞吐量，爲複雜的業務系統提供良好支撐。而分佈式架構體系調用過程較長，從外界流量入口分發、代理服務、網絡傳輸、容器、應用服務、數據存儲，存在很高的優化空間，經過合理的設計方案能讓系統承載更多更高的指標，從而穩定運行.
•系統癱瘓
不少外部因素也會致使系統癱瘓，如機房停電、線路關閉、網絡堵塞等，所以須要一套完整的分佈式架構方案（高可用、監控、故障轉移等）來支撐。
系統在構建時期須要考慮這些外在因素，而後構思設計相應的處理方案，經過設計方案而後落地，在測試環境中演練外在因素致使系統癱瘓場景，不斷探索、改進、完善，這樣，當外部因素真的出現時，系統能夠從容面對，從側面凸顯出系統的健壯。
分佈式架構體系中針對以上場景有衆多解決方案，會從設計之初就會考慮這些因素，確保系統是可用的、可靠的。而多機房部署就能從根源上解決由機房停電引發的事故.
•系統故障
當系統發生故障，因系統構建龐大，維修排查故障時間太久，影響用戶羣體使用。
分佈式架構中講究系統拆分模塊化，使用更輕量級的模塊、可用的部署策略，從必定程度上規避掉故障風險，如出現故障，經過有效的故障轉移方式能讓系統在短期以內正常服務
•系統臃腫
分佈式架構中可拆分模塊化，模塊細化後可讀性、維護性會變得簡單明瞭，針對細化後的模塊可更專一開發和優化，系統龐大內核彙集多，致使臃腫。迭代維護運營成本高額，風險過大
技術大廠使用情況
•阿里巴巴
初級階段阿里巴巴已擁有規模龐大的用戶，業務體系複雜，業務之間相互依賴較高，不能給客戶提供好的服務和體驗。
阿里巴巴規劃使用分佈式架構，經過多條業務線的拆分，讓業務模塊之間相互解耦，減低依賴，提升系統間的容錯和穩定性。
阿里巴巴在此期間研發了多項分佈式技術和框架，如：Dubbo（微服務）、Rocketmq（消息隊列）、OSS（資源存儲）、Tair（緩存）、Xdb(數據庫)等等。其中面對國內每一年的’雙11‘，淘寶/天貓等商城系統每一年都會面對較大的壓力，壓力多方面來自於用戶數的增長（多用戶的請求頻率和次數），之因此可以提供給用戶良好的體驗和使用量，阿里的技術體系尤其重要，每一年的’雙11‘都是阿里的自家技術的實戰和分析。技術創新、技術沉澱讓阿里在國內數一數二
•百度
百度是一家作搜索引擎及其人工智能的企業，搜索業務場景複雜多變，搜索涉及信息較廣。最初搜索體驗很差，搜索結果不太準確。
百度擁有’獨立搜索引擎核心技術‘，天天面對來自百餘個國家和地區的數十億次搜索請求，爲了知足用戶需求和提升體驗，不斷堅持技術創新、優化分佈式搜索引擎、分佈式存儲（Tera）
總結：
分佈式發展過程經歷了傳統單體結構、集羣化結構等。它的發展都離不開業務場景，業務場景是驅動技術架構變革的載體。本章重點講述了大型系統在分佈式環境中面臨的問題，分佈式環境中存在諸多不肯定性因素，系統從構建到發展成型，會經歷不少階段，而不一樣階段須要關注點不一樣，因此設計之初需考慮全面。從而讓系統在面臨諸多不肯定因素時有多種容錯方式，總體提升系統的穩定性
點擊「閱讀原文」，進入留言區留言，具體規則見原文文章。
本文分享自微信公衆號 - 物流IT圈（exiter18）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。