如今框架兩字已經爛大街了，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）
