架構簡明指南

架構簡明指南

設計原則部分供你們隨手參考。

架構原則

• 避免過分設計：最簡單的方案最容易實現和維護，也能夠避免浪費資源。但方案中須要包括擴展。
• 冗餘設計：對服務、數據庫的作結點冗餘，保證服務的高可用。經過數據庫主從模式、應用集羣來實現。
• 多活數據中心：爲了容災，從根本上保障應用的高可用性。須要構建多活的數據中心，以防止一個數據中心因爲不可控因素出現故障後，引發整個系統的不可用。
• 無狀態設計：API、接口等的設計不能有先後依賴關係，一個資源不受其餘資源改動的影響。無狀態的系統才能更好地進行擴展。若是非得有狀態，則要麼客戶端管理狀態，要麼服務端用分佈式緩存管理狀態。
• 可回滾：對於任何業務尤爲是關鍵業務，都具備恢復機制。能夠使用基於日誌的WAL、基於事件的Event sourcing等來實現可回滾。
• 可禁用/自我保護：具備限流機制，當上遊的流量超過自身的負載能力時，可以拒絕溢出的請求。能夠經過手動開關或者自動開關（監測異常流量行爲），在應用前端擋住流量。
• 問題可追蹤：當系統出現問題時，可以定位請求的軌跡、每一步的請求信息等。分佈式鏈路追蹤系統即解決的此方面的問題。
• 可監控：可監控是保障系統可以穩定運行的關鍵。包括對業務邏輯的監控、應用進程的監控以及應用依賴的CPU、硬盤等系統資源的監控。每個系統都須要作好這幾個層面的監控。
• 故障隔離：將系統依賴的資源(線程、CPU)和服務隔離開來可以使得某個服務的故障不會影響其餘服務的調用。經過線程池或者分散部署結點能夠對故障進行隔離。
• 成熟可控的技術選型：使用市面上主流、成熟、文檔、支持資源多的技術，選擇合適的而非最火的技術實現系統。
• 梯級存儲：內存->SSD硬盤->傳統硬盤->磁帶，能夠根據數據的重要性和生命週期對數據進行分級存儲。
• 緩存設計：隔離請求與後端邏輯、存儲，是就近原則的一種機制。包括客戶端緩存（預先下發資源）、Nginx緩存、本地緩存以及分佈式緩存。
• 異步設計：對於調用方不關注結果或者容許結果延時返回的接口，採用隊列進行異步響應可以很大程度提升系統性能；調用其餘服務的時候不去等待服務方返回結果直接返回，一樣可以提高系統響應性能。異步隊列也是解決分佈式事務的經常使用手段。
• 前瞻性設計：根據行業經驗和預判，提早把可擴展性、後向兼容性設計好。
• 水平擴展：相比起垂直擴展，可以經過堆機器解決問題是最優先考慮的問題，系統的負載能力也才能接近無限擴展。此外，基於雲計算技術根據系統的負載自動調整容量可以在節省成本的同時保證服務的可用性。
• 小步構建和發佈：快速迭代項目，快速試錯。不能有跨度時間過長的項目規劃。
• 自動化：打包、測試的自動化稱爲持續集成，部署的自動化稱爲持續部署。自動化機制是快速迭代和試錯的基礎保證。

架構六步思考法

筆者對美團總架構師夏華夏一次分享提出的架構六步思考法的理解。

數據設計原則

• 注意存儲效率
  • 減小事務
  • 減小聯表查詢
  • 適當使用索引
  • 考慮使用緩存
• 避免依賴於數據庫的運算功能(函數、存儲器、觸發器等)，將負載放在更容易擴展的業務應用端
• 數據統計場景中，實時性要求較高的數據統計能夠用Redis；非實時數據則能夠使用單獨表，經過隊列異步運算或者定時計算更新數據。此外，對於一致性要求較高的統計數據，須要依靠事務或者定時校對機制保證準確性。

系統響應性能提高五板斧

• 異步：隊列緩衝、異步請求。
• 併發：利用多CPU多線程執行業務邏輯。
• 就近原則：緩存、梯度存儲。
• 減小IO：合併細粒度接口爲粗粒度接口、頻繁的覆蓋操做能夠只作最後一次操做。這裏一個須要特別注意的地方: 代碼中儘可能避免在循環中調用外部服務，更好的作法是使用粗粒度批量接口在循環外面只進行一次請求。
• 分區：頻繁訪問的數據集規模保持在合理的範圍。