微服務框架下的思惟變化-OSS.Core基礎思路

　　現在框架兩字已經爛大街了，xx公司架構設計隨處可見，不過大多看個熱鬧，這些框架如何來的，細節又是如何思考的，相互之間的隔離依據又是什麼...相信不少朋友應該依然存在本身的疑惑，特別是愈來愈火熱的微服務以及衍生的微服務網關產品，正好最近打算寫一個小開源框架OSS.Core，過程當中有一點思考，經過這篇文章記錄一下，也但願能儘可能幫助你們去理解一下，大概圍繞如下幾個問題：

1. 微服務產生的由來

2. 微服務的設計思路

3. OSS.Core框架的設計和實現

　　在展開講述以前，我但願你們首先要明白傳統架構和微服務架構之間不是相互獨立/對立關係，微服務是在傳統框架下爲了應對併發維護等問題衍生出的邏輯概念，更多的是在項目不一樣階段的思考和解決問題方式的轉變。其次，把邏輯架構和物理架構(文件) 區分開來，多數時候邏輯架構和物理架構對應的，不過有時一個物理架構中是能夠包含多個邏輯架構的。

一. 微服務產生的由來

      微服務主要是將一些大型的，複雜的應用拆解爲多個服務組合，每一個服務自治，以達到更加靈活，維護方便的效果。 

　　爲了更好的理解，咱們先來看下常見三種解決併發的方式：

　　1. 添加數據庫主從分離，甚至多主寫入或者分區等機制，在應用程序中對應修改鏈接串或添加訪問中間件，來提升數據庫的處理能力。

　　2. 因爲數據庫資源相對緊張而且比較耗時，爲了提升訪問速度，這個時候通常也會經過分佈式緩存等來減小對底層的訪問。

　　3. 負載均衡分流處理，在大量請求抵達應用程序以前，將其分散到不一樣的機器上，來解決單機帶寬和性能瓶頸問題。

　　固然解決併發還有不少其餘的方式，如前端靜態文件壓縮，CDN加速，IP速率控制等，這裏先略過。

　　以上這三種方法不少朋友應該都見過，之因此這裏列一下，再結合這張圖能夠更加容易的對比出傳統整個服務到微服務之間的變化：

　　在傳統的總體服務框架中，模塊之間存在着很大的耦合，項目內部存在互相調用，以及各類複雜聚合操做，因此在多數狀況下只能總體部署，在左側圖中咱們能夠看到負載均衡時咱們須要總體部署在多臺機器上，相對數據庫也是如此，而一個項目中每一個模塊的需求是不同的。

　　例如：產品和下單模塊的訪問頻率和流程的複雜度上有着很大的不一樣，下單頻率相對較小，複雜度高，咱們更但願運行在預算能力高的相對少機器上，也方便更快的排查問題和維護。右圖中能夠看到把服務細化以後，咱們能夠用更小的部署單元來根據狀況進行組合。

　　同時，在互聯網產品快速迭代的今天，一個產品須要具備快速爲不一樣終端上線不一樣應用功能的能力，同時業務的調整可以快速的上線，傳統的總體服務模式已經力不從心。微服務由於已經化整爲零，反而由於各模塊的獨立能很快相互組合，而且每一個模塊能夠根據不一樣的需求點採用不一樣特性的編程語言。

　　

 

二. 微服務的設計思路

　　由於每一個產品都有本身的標準和重點，因此設計服務單元時也各有不一樣，可是有最基本一點： 服務自治

　　當你設計一個微服務模塊時，須要保證當前服務的獨立，特別是數據模塊的獨立，其餘服務無權直接操做當前服務下的數據庫模塊，對外交互只能經過服務接口來完成。由於模塊的獨立，因此你能夠選擇適合的編程語言，以及對應的部署規模。達到局部的靈活優化。微服務相互獨立帶來以上便利的同時，它也帶來了一些咱們須要面對的問題：

　　首先：如何如何界定當前服務的邊界，如何肯定當前服務治理範圍。

　　既然是要最小化服務單元，那就要肯定服務的職責邊界問題，這個問題建議結合：服務生命週期流程，領域，以及預估規模 這幾點綜合考慮，例如用戶服務，在訪問量小人員少時能夠把用戶基礎信息，餘額帳戶放在一個服務模塊下，以減小工做量減小精力分散。規模大時再分基礎服務和資產服務。

　　其次：跨服務數據查詢問題

　　例如在客戶端中搜索商品，還能夠搜索用戶或者統計數據查詢等如何處理。對於這種我給兩個處理方式：

　　1. API Gateway

　　這種狀況適合在服務單元過多，客戶端須要查詢使用不一樣的服務單元中的數據，這個時候咱們能夠針對性的搭建一個API服務網關（請注意和APP Gateway區分開），經過這個網關聚合多個服務，客戶端只須要和當前網關交互，網關聚合轉發給不一樣的微服務。以下圖：

　　2. 數據冗餘或者後臺數據同步

　　好比在訂單信息中我須要用戶的名稱等少許用戶字段，這個時候徹底能夠把這幾個字段冗餘到訂單微服務數據模塊下。又好比在統計模塊下，其數據製造者和查詢者徹底屬於不一樣的對象，無很高實時性，那我建議建立一個統計服務以及對應的統計數據庫，其餘服務經過事件消息交互，更新對應的統計數據，查詢時經過統計服務本身的數據便可完成。

　　再次：如何解決服務間的通訊問題

　　由於咱們已經將服務之間相互獨立，斷絕直接操做不一樣服務數據庫的可能。那麼數據的一致性如何處理，在傳統的服務模型中由於都糅合在一塊，咱們能夠經過事務或者存儲過程來保證數據的一致性。常見的有如下兩個方式：

　　1. 異步事件消息驅動

　　這類解決方案適合對數據實時性要求相對不高的場景，好比上邊的統計服務更新，在下單等服務的事件觸發後給消息隊列推送響應的消息通知，訂閱此隊列的服務接收更新數據。如圖：

　　2. 直接接口請求（HTTP,RPC）

　　通常狀況下不建議，以防止產生級聯依賴。這類主要針對數據實時性要求較高的請求，好比在秒殺下單過程當中須要當即知道庫存服務扣除是否成功等。（注：.net 下對task的支持已經特別好了，http請求建議使用異步，同時前端返回Task<ActionResult>,減小因IO操做形成的工做線程消耗）

　　最後：客戶端如何訪問

　　當咱們封裝完服務以後，這個服務如何和最後的客戶端如何訪問，這個須要根據實際的安全規則和要求各自決定了，通常狀況下，若是服務相對較少，功能不算複雜的狀況下能夠直接暴露服務接口給客戶端進行訪問，如圖：

　　或者經過上邊說的 API Gateway 的形式提供給客戶端，固然也有不少已經成熟的微服務網關好比Azure雲上的Service Fabric或者API Management，都是能夠的。

 

三. OSS.Core框架的思路和實現

　　OSS.Core這個項目是我最近在寫的一個小開源產品，瞭解的朋友應該知道我在前面寫了一些組件像: OSS.Social，OSS.PayCenter，OSS.Common，OSS.Http 這個項目但願能把這幾個組件給串聯起來，上邊已經介紹了微服務的大概思考方式，我將會在這個產品的邏輯架構中儘量的體現這一點，先把項目的物理架構圖展現一下：

　　這個項目中AdminSite，WebSite 放置在FrontEnds文件夾下，兩個問站點分別是用戶前端，和後臺管理前端

　　WebApi，Service，DomainMos（圖中的Models和Interface）類庫在 Layers 文件夾下，構成API基礎

　　Infrastructure（業務相關通用實體枚舉輔助類） 和 Common（業務無關相關實體輔助類） 做爲基礎設施類庫，能夠在各級類庫中調用

　　 Repositories（暫時是項目中的OSS.Core.RepDapper的Mysql實現，之後可能增長其餘數據庫支持），主要是Rep.. Interface的具體實現。

　　Plugs是實現了Common插件下的日誌，緩存，和配置接口具體實現，能夠經過Common在各級直接調用。

      回到微服務的話題上，在這個產品中我不會爲每一個服務建立一套Layers下的類庫實現，我將在這個項目經過文件夾隔離的形式來分開各個服務，你能夠把WebApi當作一個API Gateway，內部的調用順序我但願是這樣的：

　　如今代碼結構圖：

 

 

=============================

若是你還有其餘問題，歡迎關注公衆號（OSSCoder）