微服務架構實戰讀書筆記(一)—微服務概述

什麼是微服務

​ 現在微服務概念十分火熱，到底什麼是微服務？與之前的架構有啥區別？

​ 微服務是一種軟體架構模式，可以把它理解為三層架構mvc一樣，同樣只是一種人們為了應對業務規模的迅速擴大，從而總結出來的一種架構模式

​ 它將以往的單機MVC架構中的業務，抽離出公共的服務單獨部署，實現程式碼的可複用性，服務和服務之間的耦合度降低。並且資料庫也抽出，一個服務都有自己單獨的資料庫，耦合降到最低。在可擴充套件性上提高了很多，有了優點也不可避免帶來了其他缺點

優點

• 開發簡單，獨立性高
• 每個服務可以選擇不同語言，技術選用靈活
• 服務無依賴
• 服務可以按需擴充套件叢集
• 一個服務掛了不會影響其他，可用性高
• 選擇輕量api通訊
• 服務小而精

缺點

• 運維困難，如何有效管理龐大的服務是個困難
• 部署依賴
• 通訊成本，網路延遲啥的，介面不可用怎麼辦
• 資料一致性，分散式自帶的問題
• 測試成本
• 監控問題
• 溝通成本
• 可能重複工作

微服務的主要難點在於，系統的設計，服務管理，運維。隨著系統的複雜，有可能抽象化程度不高，導致服務重複化，而且龐大的服務如何有效的管理是個巨大問題，監控服務到效能。

架構的演變

單機架構

​ 最開始的單機架構MVC，大家最熟悉

​ controller->service->dao->db

​ 這裡有個很明顯問題是如果專案中一個業務模組出了問題會導致整個專案崩潰，無法對外提供服務

第一步切分

​ 每個業務模組單獨部署

​ 網頁訪問不同的業務模組，一個業務掛了不會導致整個系統掛了

​ 現在存在的問題是前端呼叫介面數量具有管理

服務化

​ 在業務和網頁中間加一個api閘道器，可以理解為Nginx，用這個來管理介面

​ 然後服務之間通過RPC遠端呼叫進行訪問

​ 但是需要呼叫RPC需要個註冊中心，得讓消費者知道服務提供者在什麼地方，這個時候需要zookeeper充當註冊中心

微服務的可擴充套件性

​ 效能可擴充套件:因為服務可以按需擴充套件叢集

​ 可用性擴充套件:cap理論，一般採用ap，選擇可用性和分期容錯性，犧牲強一致性，保證最終一致性

​ 維護可擴充套件:使用自動化平臺工具，實現自動化部署更新

​ 成本可擴充套件:先有元件可以重用，使用行業標準容易招人

微服務和SOA區別

​ 網上很多資料對這塊都是很模糊，我也不見得能把握精髓吧，我個人理解劃分服務的粒度不同

​ 微服務本身也是SOA一個提升

​ SOA對服務的劃分還是比較粗，而微服務更加細了

常見的微服務元件

• 服務註冊
• 服務發現
• 負載均衡
• 服務閘道器
• 配置中心
• API管理
• 框架整合
• 分散式事務
• 呼叫鏈
• 支撐平臺

常用的微服務框架

​ dubbo

​ Spring cloud

​