微服務的概念

　　首先我們嘗試用一段話解釋一下微服務的概念，微服務區別於講所有的服務，資料庫訪問等業務及中間層程式碼打在一個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上，並提供給我們一種視覺化的監控展現。

　　總結

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