服務註冊
服務發現
負載均衡
服務閘道器：唯一入口，實現使用者鑑權，動態路由，灰度發布，a/b測試，負載限流等
配置中心
api管理
整合框架：整合各個微服務元件到統一介面下
分布式事務：tcc，高可用訊息服務，最大努力通知
呼叫鏈：展示出來方便排查問題
支撐平台：容器雲平台
一致可用、可靠、可伸縮
分割槽容忍
三者只能滿足其二，比如要做分布式，資料一致性就很難滿足，要看具體需求，找到平衡
最終一致性：一段時間後的一致性
基本可用：保證絕大部分使用者的一致性，放棄很小的部分（還是看業務需求，網際網路上有些業務是可以的）
軟狀態/柔性事務：有時可以先把資料快取在客戶端，不同步
最終一致性：一定要在容忍的時間內
api粒度
api之間不影響
不停機發布api
承載流量：限流，防刷，非同步等方法
安全：簽名，授權
單一應用
垂直應用
分布式服務
soa微服務
各有各適用場景
案例：很多情況下拆了，下層讀寫資料還是耦合了
根據業務、領域，系統功能，使用資源，資料邊界等拆分
避免先設計資料庫
服務**
服務聚合
服務串聯
服務分支
非同步訊息：通過mq
共享資料：快取和資料庫
艙壁隔離：分灰度環境，準生產環境，生產環境
執行緒隔離
降級：本地快取->分布式快取->庫
流量精細化控制
優雅降級：排隊，降級，靜默降級
限流熔斷
超時euraka：服務註冊發現
ribbon：負載均衡
feign：http客戶端
hystrix：斷路器
zuul：閘道器
字段冗餘：如訂單快照等系統需要
庫冗餘：主從，主備，集群
同步寫非同步寫
線下非同步寫：類主從的模式
主要是一致性hash
兩段提交：規定好超時時間
tcc：try，confirm，cancel
本地訊息表：需要定時輪詢訊息表，如轉賬場景
mq非事務訊息：依賴於mq可靠性
mq事務訊息：適用廣泛
cdn分布式快取
本地快取
分布式，主從，主備效能差於本地
redis幾乎可替代memcache所有適用場景
案例：資料量大：分片：hash環集群
峰值明顯，非同步備份，雙寫的方式
採用雙環的方式保證可靠性，備份環做持久化落盤
zk實現分布式鎖：但是集群不能太大
樂觀鎖思路+版本號
粒度小資料冷熱交換的各種策略：根據實際業務來設計
元件、存活、方法效能、業務、jvm、伺服器效能、報警
web展現
結合容器
微服務架構授權是在閘道器做還是在微服務做？
在springcloud架構中，實現授權功能有兩種實現方式 很抱歉，看完這篇文章你也不一定能得到你想要的答案，因為結論是並沒有最優方案，兩種方案各有千秋，只有根據自身業務選擇對應的方案。本文我們將兩種方案做乙個簡單對比，以便大夥在做方案決策有個選擇參考。首先我們看看兩種方案實現的原理 如果對具體實現...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
微服務架構
一 先了解一下什麼是單體應用 就是乙個應用程式包含了所有模組功能，各模組同時部署。當然這種應用模式比較容易部署 測試，但隨著專案的加大，單體模式就會變得越來越臃腫，維護的成本逐漸變高。當乙個模組出錯，整個應用都會出現問題，擴充套件能力也會受到限制。二 什麼是微服務 是將整個應用程式分解為多個模組，各...