一文看懂微服務和經常使用的微服務落地技術

微服務的概念

　　首先咱們嘗試用一段話解釋一下微服務的概念，微服務區別於講全部的服務，數據庫訪問等業務及中間層代碼打在一個jar或者war包內的all in one的體系結構，以業務服務及領域模型的組合爲單元拆分出可獨立部署，獨立運行，獨立風險控制的系統組件應用的結合體。微服務擁有業務服務(能夠理解爲spring mvc中的service)及領域模型(能夠理解爲spring mvc中的model)爲閉環，其自己的微服務系統所提供的服務業務邊界清晰，生命週期獨立且可自運行，可隔離，可追蹤。

　　舉個實際一點的例子，在沒有采用微服務結構前，咱們的電商java代碼結構相似以下

　　全部的服務融合在一個業務程序內，採用all in one的打包方式組成一個jar或者一個war包，而且訪問同一個mysql數據庫，簡單粗糙，服務之間調用關係因爲是在一個代碼包內，能夠隨意互相應用，業務關係不清晰，並且部署在一塊兒，一旦一個服務或者對應的數據庫產生問題，則全盤故障。因而咱們把系統作了微服務化的拆分，以服務爲單位將其變成一個分佈式的系統

　　網關接入系統負責接收對應的web請求，轉發給對應後面的業務服務系統處理對應的業務並接收返回轉發給前端。後面的業務服務系統各司其職，每一個系統只負責本身業務範圍內的職責，好比商品系統僅服務商品相關的服務，建立，更新，查詢，上下架等整個的生命週期並被購物車系統依賴，服務系統之間的邏輯關係清晰，且不一樣系統間只能經過對方提供的接口作訪問，管理方便，每一個系統擁有本身獨立部署服務器，擁有本身的存儲數據庫，故障可隔離，配合日誌，消息，監控，配置中心等分部署微服務下的配合組件作到一個可監控，可隔離，又可通訊的服務體系。

　　微服務的落地技術

　　微服務的落地技術有不少，但整體來說仍是能夠用幾個簡單的點去作分類，微服務的框架目前開源的用的最多的是spring cloud，另外有人確定會說爲何不是dubbo，那其實dubbo僅僅是解決了微服務技術中的一部分問題，例如服務通訊，負載均衡，服務註冊發現等，可是他沒有解決降級限流，熔斷控制，服務路由等問題，還須要本身實現或者結合一些第三方組件，所以spring cloud是真正意義上閉環完整的實現了全部微服務的落地功能技術。可是在這裏我仍是強烈推薦你們學習一下dubbo技術，畢竟在國內阿里體系公司技術流派的氛圍下，阿里的開源組件是有不少愛好者和公司使用的，並且dubbo的面向服務插件的編程方式能夠很容易的融合第三方庫彌補其微服務的不完善性，最終作到一個閉環的服務生態，那咱們一塊兒來看一下使用dubbo作微服務技術的具體落地，微服務須要解決如下幾個問題：

　　服務通訊

　　隔離開系統以後，原本進程內的調用就要改爲進程之間的調用了，進程之間的調用最經常使用的方式就是網絡通訊，而遠程的網絡通訊調用函數的方式就是RPC(Remote Process Call)遠程過程調用，其並不是是一個簡單的網絡通訊過程，在java中依靠接口代理的通訊機制使用服務消費方在進程內能夠像調用本地函數同樣去調用服務提供方的代碼，其中間層由dubbo的服務代理機制負責搞定。

　　服務提供方代碼：

　　服務消費方引用服務

　　對，RPC通訊框架使得服務調用就這麼簡單

　　服務註冊及發現

　　服務註冊及發現，解決了服務通訊的網絡問題，你們不要忽略了，個人服務消費方怎麼知道提供方的ip地址和端口，而後鏈接上去作服務通訊的，dubbo結合zookeeper的註冊和發現的通訊能力作到了這一點

　　服務提供方啓動後將本身的ip,端口及能夠提供的demoService的接口簽名註冊到zookper的註冊中心上

　　服務消費方啓動後經過本身的reference服務依賴引用列表從註冊中心找到了提供demoService接口簽名的接口服務提供方，也就是咱們的服務提供方的ip和端口

　　當consumer要調用對應的demoService服務時經過本地存儲的提供方ip和端口鏈接到provider並進行服務調用後得到返回

　　當provider產生問題，例如異常退出後，因爲和zookeeper註冊中心之間的心跳丟失，註冊中心斷定provider死亡會主動通知關注demoService的服務消費方consumer，consumer因而就將對應的provider ip和端口及鏈接提出

　　發送方和接收方定義將服務調用量發送給monitor監控器作服務健康監控負載均衡

　　在上圖服務註冊和發現中其實咱們的provider和consumer在分佈式環境下是多臺的，所以咱們的consumer能夠經過註冊中心拿到一批provider的ip和端口，當發生服務調用時能夠在本地存儲的provider列表上作負載均衡策略，好比能夠輪訓或隨機的取下一次調用的provider的鏈接，因爲上述第4步的存在，若某臺provider故障則consumer會立馬經過註冊中心感知到並將provider踢出對應的列表，當provider恢復後又會到註冊中心註冊，consumer又能夠獲得經過將provider加回。

　　配置中心

　　dubbo依賴zookeeper提供註冊中心的能力，一樣咱們能夠將分佈式環境下統一使用對應zookeeper作配置中心，將一些集羣的配置信息存放在zookeeper上而後全部的關注這個配置的系統均可以實時的得到配置信息並在配置信息發生變動的時候得到第一時間的響應

　　異步化服務通訊

　　咱們以前所說的RPC屬於同步服務通訊，若咱們須要使用異步化的服務通訊，好比商品被下單後的銷量+1操做，則能夠藉助rocketmq或者kafka之類的消息中間件解決異步化通訊的問題

　　服務限流

　　通常咱們衡量服務承載的能力爲TPS(transaction per second)也就是咱們每秒能夠處理的服務筆數，這個數值咱們能夠經過壓測得到，那接下來咱們要作的是在服務入口層面加上一個限流器，若是每秒鐘服務的調用量超過對應的筆數則要採起拒絕服務的處理措施保護咱們的系統，google的guava rateLimit就能夠提供給咱們很好的方法

　　熔斷降級

　　若你依賴的服務長時間響應失敗或者超時錯誤次數頻增，你是否就要考慮估計你的下游服務生病了，或者處理算力不夠了，咱們就要像參考電路板熔斷器同樣，我就不去調用你了，這種機制咱們把它叫作「熔斷」，基於熔斷保護下游，給下游一個喘息的機會，一旦熔斷以後咱們還要間歇性的去觀察下游是否恢復了，由於熔斷很是態，正常服務纔是咱們的訴求，咱們還須要提供說我間歇性的訪問下你，好比每一個2秒鐘訪問你一次，若是連續三次都沒有異常，則判斷你已經恢復了，我關閉熔斷處理策略。在熔斷的過程當中咱們須要定義一種異常，這種異常好比咱們能夠用一個特殊的錯誤碼，一種特殊的異常，或者就是一個null的返回，咱們對應的服務消費要基於這個錯誤碼作到可降級，好比咱們的商品銷量獲取，若是服務不可用咱們就能夠展現一個默認的銷量，或者隱藏掉銷量的展現，不要把系統錯誤拋給前端。hystrix框架提供給咱們和好的服務隔離和熔斷機制，結合dubbo的插件式編程方式作很好的融合

　　監控

　　咱們須要一套監控體系配合咱們的微服務健康度檢查，在出現問題的時候能夠快速定位問題，甚至於作到提早發現問題，防患於未然，dubbo自身的monitor並不能提供給咱們太好的支持，在這裏我建議你們看一下點評開源的cat監控組件，結合dubbo的插件式編程方式，將每個服務調用以打點的方式打到cat上，並提供給咱們一種可視化的監控展示。

　　總結

　　微服務自己是一個很好的工具，可是配套的所產生的系統之間的通訊問題，服務的穩定性問題等對開發人員都是不小的挑戰，咱們建議開發人員結合本身的業務實際狀況作好本身的微服務技術落地。