微服務架構思想

 

微服務介紹

1.微服務架構是一種架構思想，架構就是為了解耦，實際的開發方式是分布式系統開發 Spring Boot+Spring Cloud Spring Cloud是一個編程模型，微服務開發的一種標准，一系列的接口 Spring Cloud Netflix 網飛 Spring Cloud Alibaba阿里巴巴 2.滿足三大指標：高可用，高性能，高並發 高可用---服務一直可以用，N個9,6個9，使用率達到99.99999%,允許宕機的時間是31.536秒 高性能---響應速度保證在3秒鍾以內 高並發---系統的承載能力， （new User()放到堆，List<> Map<> JVM->內存 不足就會導致OOM->宕機->重啟->需要時間120秒） 3.解決四大問題： 這么多服務，客戶端如何訪問 這么多服務，服務與服務之間如何通信 這么多服務，服務如何治理 這么多服務，服務掛了怎么辦 一個淘寶首頁有2000 個微服務組成，千人千面 一個蘇寧易購首頁有600個微服務組成

• • 如何應對高並發？

垂直擴展  升級配置 1CPU 2核心 2G 4路32核 4CPU 128G 性能瓶頸 水平擴展  多買服務器-->負載均衡 Nginx 策略問題（輪詢，Hash 一直，權重） 1CUP 4核心 32G 192.168.0.1 1CUP 4核心 32G 192.168.0.2 1CUP 4核心 32G 192.168.0.3 1CUP 4核心 32G 192.168.0.4 1CUP 4核心 32G 192.168.0.5 系統 計算密集型 cpu 2cpu 8核 16GB 內存密集型 內存 Redis 1cpu 2核 128GB 用戶分地區  跨地區訪問會延遲 100ms 所以用戶->根據IP（分辨）->CDN內容分發網絡 廣州 1cpu 4核心 32GB 172.0.0.1 北京 1cpu 4核心 32GB 172.1.0.1 上海 1cpu 4核心 32GB 172.2.0.1 南京 1cpu 4核心 32GB 172.3.0.1

• • 單點故障、分布式數據庫中間服務

分布式數據庫中間件 數據庫的水平拆分 單庫-->單點故障-->中心化 數據庫 User_0 192.168.0.1 數據表 User_0 ID 20200428056000 bId 業務Id User_1 ID 20200428056001 User_2 ID 20200428056002 User_3 ID 20200428056003 ... User_9 ID 20200428056009 數據庫 User_1 192.168.0.2 數據表 User_0 ID 20200428056000 bId 業務Id User_1 ID 20200428056001 User_2 ID 20200428056002 User_3 ID 20200428056003 ... User_9 ID 20200428056009 數據庫 User_2 192.168.0.3 數據表 User_0 ID 20200428056000 bId 業務Id User_1 ID 20200428056001 User_2 ID 20200428056002 User_3 ID 20200428056003 ... User_9 ID 20200428056009 查詢->配置多數據源 物理查詢 select * from 'user_0'.'user_0'; select * from 'user_0'.'user_1'; select * from 'user_0'.'user_9'; select * from 'user_1'.'user_9'; 邏輯查詢 select * from user -->發送給專門處理物理查詢服務呢？分布式數據庫中間件（MyQat-->重啟了Alibabat淘汰的分庫分表,Apache Sharding-Sphere） Apache Sharding-Sphere Shariding -JDBC->源碼里依賴，有一定的侵入性 Shariding-Proxy->分部署數據庫中間件，單獨部署 Shariding-Sidecar->Kubernetes里，高可用 分布式數據庫中間服務->高內聚低耦合 用來解析SQL，配置多數據源，分庫分表規則（分片） Spring Boot->yaml配置多數據源

• • CAP 

C  
  一致性->強一致性，原子性 強一致性 弱一致性 順序一致性 最終一致性 A 可用性->高可用+高性能，即服務一直可用，而且是正常響應時間 P 分區容錯性 要么CP ->強一致性系統->金融系統 要么AP ->強可用性系統->互聯網系統 

 

• • BASE 理論

電商 雙十一 天貓購物街B（香奈兒）2B（天貓）2C（用戶） 保證基本可以用->重要業務，瀏覽大促商品，促進成交（訂單，支付） 雙十二 淘寶狂歡節 C（賣家）2C（買家） 數據最終要落盤，持久化 弱一致性 順序一致性 a b c d 1 2 3 4 最終一致性（5分鍾寫進來） a b c d

• • 微服務的四大問題

Spring Cloud Alibaba + Dubbo

Zookeeper 分布式協調技術 分布式鎖 ztree -> znode -> 有序節點

Redisson 分布式鎖 RedLock 腦裂問題

Dobbo ->Nacos

Dobbo 只是一個通信框架

1.這么多服務，客戶端如何訪問？

API網關 反向代理 Zuul(網飛，同步並阻塞的)、 Spring CLoud Gateway（異步）、 Consul、 OpenRestry（物聯網） Kong 域名的請求方式 

例如：四個服務，一共12個服務IP 登錄服務 10.0.0.1、10.0.0.2、10.0.0.3 商品服務 10.0.1.1、10.0.1.2、10.0.1.3 注冊服務 10.0.2.1、10.0.2.2、10.0.2.3 訂單服務 10.0.3.1、10.0.3.2、10.0.3.3 

2.這么多服務，服務與服務之間是如何通信的？

同步通信 ：HTTP、RPC (對外RESI，對內【同一個局域網】RPC Dubbo Thrift) 異步通信：消息隊列MQ (RocketMQ、RabbitMQ) 

3.這么多服務，服務如何治理？

注冊中心 Eureka Nacos 鏈路追蹤 ZipKin SkyWalking 日志收集 ELK 

4.這么多服務，掛了怎么辦？

熔斷機制 Sentinel 負載均衡 微服務自帶負載均衡 

• • 微服務架構的構建原則

伸縮能力 可用性 健壯性 彈性 獨立的匿名服務 去中心化的治理 故障隔離 自動供給 通過 DevOps 實現持續交付