《架構基礎 從需求到架構》讀書
《架構基礎 從需求到架構》這本書我去年讀過前兩章，當時我的感受是醍醐灌頂，最近我用了一週的時間把整本書讀了一遍，依然收穫頗多。強烈推薦小夥伴們都看看，相信會對你有幫助。這裡我再梳理一些技術點，加深印象。
-
每一個架構師都是一個笨鳥先飛的程式設計師
-
架構師的重要之處在於將抽象的東西具體化，讓複雜的事情簡單化，讓眾多部門人員清楚自己的職責，有序的實現各自部分的系統功能
-
架構師是需求與開發之間的橋樑，它並不是一個純技術崗位
-
一名資深架構師需要保持終身學習的心態
-
程式設計師如何提高自己的架構能力：反覆認真的看系統原型，反覆認真的看需求文件，反覆認真的看設計文件，擴大自己的視角，養成刨根問底的習慣，練習文件寫作能力，抓住每一個驗證自己能力的機會，鍛鍊總結能力
-
架構師的12項必備技能：深入掌握一門物件導向的程式語言，熟練掌握各種設計模式，熟練掌握一種關係型資料庫，能夠熟練繪製各種UML圖，至少掌握一種快取性資料庫，至少掌握一種文件性資料庫，至少掌握一種訊息中介軟體，對於執行緒池連線池物件池有深入的理解和掌握，對於各種資料結構和演算法具有較為全面的掌握，對於併發程式設計具有深入的理解，掌握一種容器化技術，熟悉Linux伺服器的使用
-
解決問題的思想才更加重要，儘早規則自己的職業生涯
-
高可用模式的核心思想是 冗餘，容錯，故障轉移和系統監控
-
Ngnix + Keepalive雙機主備方案裡，提到虛擬IP技術 VIP
-
Ngnix 不夠用後，可使用LVS或HAProxy + Ngnix做二級負載， 再不夠用可以再加一層硬負載F5
-
DNS服務 可以針對不同的地區、運營商繫結不同的IP地址，這樣全國各地的使用者進行訪問時可以儘量將使用者的請求解析到距離最近的伺服器
-
MongoDB高可用架構 的 副本集模式裡 提到 選舉演算法， 叢集各節點透過心跳機制， 衝裁節點只負責投票不存業務資料。 分片模式裡分片演算法：Hash,Range
-
Redis不能完全替代關係型資料庫，首先Redis基於記憶體儲存和查詢，雖然速度快，但是記憶體資源有限，無法像磁碟一樣儲存海量資料，其次Redis使用Key=Value形式儲存，無法表達複雜的資料關係。
-
Redis持久化 RDB模式裡，主程序Fork一個子程序專門用於持久化,RDB模式缺點是造成資料丟失(定時引起)
-
RDB持久化AOF模式裡，日誌回訪模式恢復資料，AOF檔案寫入三種策略：always no everysec.
-
Redis 主從模式裡 如何將資料從主節點高效準確的複雜到從節點，主要分為 全量同步（fork rdb），增量同步(aof)，部分同步(偏移量 aof)
-
Redis 哨兵模式，推薦至少採用3哨兵+3節點的結構部署。故障轉移流程：
1）. 哨兵A探測到主節點不通，標記為主觀下線。但是A不一定準確， A 告訴 B C，然他們看看是不是真的
2）.如果超過半數 都連不上主節點，就認為主節點已不可用，標記為客觀下線
3） A B C成立仲裁委員會 投票負責人， 負責人帶領大家再選出一個主節點。
-
Redis叢集模式 使用雜湊槽hashslot方式實現資料分片儲存
-
Kafka高可用 要藉助於Zookeeper， 透過分割槽副本保證分割槽的高可用。 假如分為三個主題，每個主題裡有3個區，每個主題裡都有一份完整的資料，每個主題裡又只有1/3的Leader部分， 這樣保證即便一個區故障了，可以從其他主題複製資料。
-
關係型資料庫的讀寫分離架構，主庫一般只用於寫， 從庫用於讀。 對實時性要求較高的業務也可以強制從主庫讀。 主從從架構 ，一主多從架構。
-
關係型資料庫資料同步策略：非同步複製（不等從庫），全同步複製（等所有從庫），半同步複製（等至少一個從庫）。
-
高併發訪問限流的目的是 保證系統的可用性，需要限流的場景有：系統資源有限，承載能力有限，大量併發訪問導致系統效能下降甚至當機，避免引起雪崩問題，系統某些介面遭受攻擊導致整個系統無法訪問。 客戶端限流主要4種手段：純前端驗證碼，禁用按鈕，呼叫限制，假排隊
-
漏桶演算法 和 令牌桶演算法的區別：漏桶無法處理突發請求，只能固定速度處理。 令牌桶 只有通中有足夠的令牌 就可以，不是固定速度流程，適用性略好。
-
高伸縮性主要是指服務的水平擴充套件能力。水平擴充需要藉助負載均衡技術，最好提供無狀態服務。 無狀態與有狀態是相互對應的，主要看使用者的多次請求是否存在上下文關係和依賴關係。
-
有狀態服務改為無狀態服務主要有兩種方案：資料同步和資料共享。
-
GFS（Google File System）設計目標主要是針對大檔案儲存，讀多寫少的場景，支援彈性伸縮。FastDFS 更適合儲存佔用空間小但數量巨大的碎檔案。
-
高併發的主要策略有多級快取策略，非同步化策略和讀寫分離策略。
-
靜態資源可以直接使用Ngnix的快取功能，加快訪問速度。
-
使用中介軟體快取需要注意3種問題：快取穿透（非法攻擊 不存在的ID），快取擊穿（單一熱點快取到期），快取雪崩（大量快取同時到期）
-
同步非同步阻塞非阻塞 場景區分，假如我們用洗衣機洗衣服，將所有的衣服 水 洗衣液都準備好
1）同步阻塞， 啟動開關後，洗衣機開始洗衣服，我們就站在洗衣機旁邊守著，不斷的去看洗完了嗎
2）同步非阻塞：啟動開關後，我們就去做別的事情了，但是隔一段時間來看一下是否洗完了
3）非同步阻塞：啟動開關後，我們就站在旁邊守著，但是不再去看是否洗完了，而是洗衣機洗完後會自動播放音樂，通知我們洗完了
4）非同步非阻塞：啟動開關後，我們就去做別的事了，等洗衣機洗完後會自動播放音樂，通知我們洗完了
-
資料脫敏必須從後端服務脫敏，不能採用前端JS脫敏
-
SOA ESB最大的問題是讓原本去中心化的系統變為了中性化的系統，ESB故障會導致整個系統不可用
-
微服務架構的缺點：拆分粒度難以界定，增加了運維難度，交易流程複雜，網路延遲增加
-
微服務架構的優點：分散式去中心化，服務伸縮性好，服務自治能力，服務內聚更高耦合更低，敏捷開發，異構開發，對硬體要求降低
-
註冊中心的原理：
1）註冊中心是一個獨立部署的微服務，專門負責服務註冊與發現。將新啟動的服務節點後設資料儲存到登錄檔中，將停止和異常的服務從登錄檔中剔除
2）當訂單服務 庫存服務啟動時，將自己的後設資料資訊發給註冊中心，註冊中心將資料儲存到服務登錄檔中
3）當訂單服務請求服務時，先從註冊中心獲取登錄檔資訊，查詢到庫存服務的ip地址埠， 然後訂單服務會直接使用此ip去訪問庫存服務
思考 每次請求都去註冊中心問，效能不會降低嗎？ 每個微服務都會在本地儲存一份登錄檔副本，同時與註冊中心保持同步關係。
-
微服務熔斷機制，當觸發熔斷後 可以直接返回一個預製好的應答內容，從而保證整個交易鏈路可用。 微服務斷路器 半開啟狀態後，會再有少量的請求嘗試，如果服務正常，斷路器變為關閉狀態。
-
配置中心的3點好處：集中管理， 配置安全，動態調整
-
微服務改造的六大原則： 不要為了使用微服務而使用，不要妄想完美架構要用進化的眼光看架構，微服務拆分沒有絕對的標準，不要忽略非功能性設計，環境網路隔離許可權隔離，重視容器化持續整合和部署
-
多型別賬號密碼登入設計中，客戶端匹配設計，由客戶端根據正規表示式匹配 賬號，郵箱， 手機
-
手機驗證碼登入設計中注意 驗證碼 手機號 TOKEN三個都要匹配。
-
手機號一鍵登入設計中設計 運營商認證SDK， 運營商認證伺服器，涉及 掩碼請求，TOKEN請求， 手機號請求
-
微信掃描登入 OAuth2.0協議
-
自己設計使用者掃碼登入設計，二維碼供應商，App,App後端服務， 網站系統服務。
-
在一些系統升級之前會將使用者主動踢出，並且不允許登入，保證系統釋出過程中不被訪問
-
App主動踢出設計：個推服務 ； 被動踢出：等App訪問後端時判斷。
-
密碼安全檢查設計：檢查庫， 歷史密碼庫
-
密碼加密演算法： MD5（MD5(原始密碼) + salt） ,salt變 但有規則。
-
郵箱找回密碼設計時，郵箱傳送的url裡包含token和加密郵箱， 用這倆繫結業務。
-
RBAC模型演進：使用者組模型，使用用經常要將多個角色授權給一類使用者的情況
-
微服務裡Token的延時與重新整理（換值）
-
利用登入日誌 分析 安全建模，單獨組建 安全中心
-
選單操作日誌 的必要性：對追查問題意義很大，能夠準確的還原當時的使用者操作狀態。 同時經常操作的選單 是效能最佳化 提升體驗的重點。 非同步批次上報。
-
簡訊 防攻擊設計，先探出驗證碼視窗，立即禁用按鈕，倒數計時。 驗證碼後端返回圖片，不能前端生成。
-
防禦重放攻擊的方式：請求限流，黑名單（IP），利用交易流水號，驗證時間戳，請求序號。
-
引數掃描攻擊： 假如主鍵是 有順序的數字，對外暴露後很可能被人利用，需要形成新編碼，比如用MD5（ID+時間戳）
-
防篡改攻擊： 互動加密AOP， 簽名驗證
-
站內信列表拉取設計： 短輪詢（定時）， 長輪詢（更適合聊天室）
-
站內信資料表設計 一個點： 一般是設計 訊息表，使用者訊息關聯表，這裡注意 不一定 傳送訊息時就往使用者訊息關聯表裡插入資料。 假如訊息是 發給全站使用者，使用者登入後可以只查訊息表。 等真正讀訊息後寫入關聯表，減少資料儲存。
-
App訊息推送設計裡： IOS獨立生態， Andorid各大手機商自己獨立的服務。 App訊息還分為 通知訊息 和 透傳訊息（觸發app的監聽）
-
被動掃描監控設計： 定時任務監控， 集中配置定義規則和SQL指令碼
-
海量資料處理的核心思想是 分片處理， 單執行緒變多執行緒， 另外一個思想是實時計算（時間跨度大）
-
引數項配置設計中 懶載入方式，只有使用時才載入。 假如更新配置時，可以利用訊息佇列 清除記憶體快取
-
第十三章裡 有多個設計實戰，可以參考模式寫論文，圖文並茂，瞭解套路。