這個檢查表包含的內容是在設計階段必須考慮的，並且在開始實現之前必須驗證
以下檢查項是所有微服務都必須滿足的一般架構檢查
｜ 檢查項
描述無狀態服務
所有永續性資料都儲存在容器外部
部署順序
服務啟動不應該有順序
資料擁有權
只有資料維護服務才能直接訪問資料，避免多個服務管理同乙份資料
如果安全性較低，客戶和公司資料將被盜或偽造(資料洩露)
檢查項描述
身份驗證
服務受驗證服務的保護
授權訪問被限制到適當的級別。考慮誰應該訪問每個公開的api以及允許他們做什麼
傳輸安全
服務在internet網路上使用tsl傳輸
可持續性影響團隊/組織的長期生產力和系統可用性。如果可持續性很低，系統就會經常出故障，維修人員就會頻繁更換。這將導致低可用性。
檢查項描述
沒有短期轉讓
團隊成員不會被迫在短期內轉移到另乙個團隊
考慮團隊oncall
團隊遵循oncall的實踐
遵循sla
團隊知道服務依賴關係的sla
slo定義了服務的slo和slo所有者
選擇服務級別的主要因素是預期的slo，也就是說需要定義服務slo來選擇你的服務水平
服務等級
對應的slo
a>99.9%
b99% ~ 99.9%
c95% ~ 99%
level a : 是**關鍵的**微服務,故障級別在p3的服務，直接對公司層面的目標做出重大貢獻(例如gmv)，或者可能在宕機期間對公司造成重大損害(例如社會影響力)，通常應該是a級level b : 是指**標準**微服務，這適用於提供必要功能的服務，但不會在宕機期間導致顯著的可用性降級，或者可以在不嚴重影響公司級別目標的情況下進行補救。例子:如簡訊服務,通知服務等level c : 用於**實驗性的**微服務,提供實驗性新特性的服務，或者只影響一小部分使用者的服務分布式高併發商品秒殺系統設計
本專案為另乙個專案seckill的分布式改進版本，dis seckill意為 distributed seckill，即分布式秒殺系統。商品秒殺與其他業務最大的區別在於 除了具有以上特點，秒殺商品還需要完成正常的電子商務邏輯，即 1 查詢商品 2 建立訂單 3 扣減庫存 4 更新訂單 5 付款 6 ...
高併發分布式佇列設計
訊息佇列提供了分布式集群系統架構中各個服務模組之間的訊息通訊，主 要解決應用解耦，非同步訊息，流量削鋒等問題，實現高效能，高可用，可伸縮 和最終一致性架構，其模型如下 應用解耦 模組之間僅依賴 通知 而沒有直接的介面呼叫，所以不存在依賴 可擴充套件性 佇列支援高可用部署，水平擴充套件容量和吞吐量 生...
高併發與分布式
一提到高併發很多人就會想到分布式，那麼二者到底有什麼區別呢？併發和分布是完全不同的概念。分布是將任務分發到不同的點上去，一般分布式最多的就是分布式計算。通過某種分布式程式設計方式，在不同的系統上利用各自的cpu，記憶體等進行計算，將結果匯集至控制中心，進行處理。比如最有名的就是分布式計算天氣的氣候阿...