1、首先最外層有一層閘道器層 mz-gatway ，在閘道器層 使用霸下等，將異常流量剝離出來
異常流量:1、爬蟲，根據ip，如果是**的話，根據協議頭 request header 也可以判斷出來
2、使用者應用層，承接入口流量
包含了登入層設計
使用使用者名稱和密碼 登入然後服務端返回sessionid
這裡有個問題，那我能否模擬sessionid，其實是可以的，這個沒辦法控制模擬sessionid，可以使用頻次控制，比如某個人最多登入幾次，ip，一天最多幾次等；
3、業務邏輯層
處理使用者的業務邏輯資訊，核心層
4、資料持久層
處理與使用者底層的互動設計
db的互動
這裡可以分為兩個模組，分為兩種情況：
1、訪問自己的資料庫，不存在超時的問題
2、訪問遠端的資料庫，會存在超時的問題，需要統一處理；是否需要丟擲異常，還是自己吃掉異常，不向上層使用者透出
5、微服務向其他應用提供服務的client 介面層
因為是向其他應用提供，因此需要考慮盡量把引用的包做小，別人引用的時候更輕量，使用者不關心他不需要的應用，
實現放在業務邏輯層；
6、預熱層
富客戶端的資料，專門處理富客戶端的資料，放在快取；
1、雙快取設計
在入口層：gu**a --redis 快取（gu**a 如果key一致，則使用分布式事務鎖，只允許乙個key穿透到redis層）
redis 與資料庫db之前 使用sentinel限流；保護介面；
更新快取 與資料庫放在乙個try事務裡面；盡量把try做小；
gu**a的更新，可以考慮傳送mq訊息的形式；這樣會全量更新；
2、常用的穩定資料，比如使用者資訊，場館資訊等，考慮富客戶端設計；
核心鏈路，非同步日誌列印，
日誌統一，考慮只用手機號，或者使用者id 就可以查詢日誌；
考慮c端應用，只列印異常日誌；
如果異常使用日誌上報的形式；專門設計日誌監控系統；
架構設計思路
1 針對請求獲取url 判斷資料請求方式，如果為ajax請求則通過ajax返回json資料，否則顯示html頁面 2 根據url判斷模組 模型 控制器 方法以及關鍵key等 3 資料報data包括data list data info data tree data custom field defi...
架構設計思路
我們一般在做架構設計的時候，會經歷過三個階段 需求分析 概要設計和詳細設計。需求分析階段 主要梳理所有用例 use case 和場景，並抽象出面向系統的使用者與角色，梳理出需求提供哪些功能與非功能的需求給這些使用者。概要設計階段 根據需求分析的產物 核心需求，對整個系統進行模組劃分，並定義好模組之間...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...