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，內部的調用順序我希望是這樣的：

　　現在代碼結構圖：