微服務
什么是微服務
- 為了降低代碼的耦合性,將專案進行了拆分.按照功能模塊拆分為若干個專案.該專案稱之為服務.(分布式思想).
- 如果采用微服務的結構,要求服務器如果出現了故障應該實作自動化的故障的遷移(高可用HA)
單體架構的不足
在文章網站后臺主流架構一文中，我較為詳細闡述了分布式架構的設計模式，
而這之中我們不難發現，后臺業務處理為單體架構，單體架構在規模比較小的情況下作業情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多：
1.復雜性逐漸變高
比如有的專案有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多復雜性越高，越難解決遇到的問題，
2.技術債務逐漸上升
公司的人員流動是再正常不過的事情，有的員工在離職之前，疏于代碼質量的自我管束，導致留下來很多坑，由于單體專案代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多，
3.部署速度逐漸變慢
這個就很好理解了，單體架構模塊非常多，代碼量非常龐大，導致部署專案所花費的時間越來越多，曾經有的專案啟動就要一二十分鐘，這是多么恐怖的事情啊，啟動幾次專案一天的時間就過去了，留給開發者開發的時間就非常少了，
4.阻礙技術創新
比如以前的某個專案使用struts2寫的，由于各個模塊之間有著千絲萬縷的聯系，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個專案將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新，
5.無法按需伸縮
比如說電影模塊是CPU密集型的模塊，而訂單模塊是IO密集型的模塊，假如我們要提升訂單模塊的性能，比如加大記憶體、增加硬碟，但是由于所有的模塊都在一個架構下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因為我們不能因為擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮，
6.基于單體架構拆分的服務在故障遷移方面不能實作高可用（負載均衡、反向代理時也需要手動修改組態檔）
微服務與單體架構區別
單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難，微服務每個模塊就相當于一個單獨的專案，代碼量明顯減少，遇到問題也相對來說比較好解決，
單體架構所有的模塊都共用一個資料庫，存盤方式比較單一，微服務每個模塊都可以使用不同的存盤方式（比如有的用redis，有的用mysql等），資料庫也是單個模塊對應自己的資料庫，
單體架構所有的模塊開發所使用的技術一樣，微服務每個模塊都可以使用不同的開發技術，開發模式更靈活，
微服務架構的使用
而微服務架構便是在此分布式架構的基礎上，利用SOA思想，將業務服務器集群按功能模塊進行拆分，從而增加業務修改的便捷性，
SOA思想
面向服務的架構（SOA）是一個組件模型，它將應用程式的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的介面和協議聯系起來，介面是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平臺、作業系統和編程語言，這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動，
微服務架構機制
步驟：
1.服務提供者啟動時,.將自己的資訊注冊到注冊中心中.
2. 注冊中心接受到了用戶的請求之后,更新服務串列資訊.
3. 當消費者啟動時,首先會鏈接注冊中心,獲取服務串列資料.
4. 注冊中心將自己的服務串列資訊同步給客戶端(消費者)
5. 消費者接收到服務串列資料之后,將資訊保存到自己的本地.方便下次呼叫
6. 當消費者接收到用戶的請求時,根據自己服務串列的資訊進行負載均衡的操作,選擇其中一個服務的提供者,根據IP:PORT 進行RPC呼叫.
7. 當服務提供者宕機時,注冊中心會有心跳檢測機制,如果檢查宕機,則更新本地的服務串列資料,并且全網廣播通知所有的消費者更新服務串列.
通過以上架構，我們不難發現微服務架構的核心之一便是注冊中心的搭建，如Zookeeper等，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/234867.html
標籤：其他
上一篇：我眼中的ZYNQ - 嵌入式工具