如今框架兩字已經爛大街了，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，內部的呼叫順序我希望是這樣的：
# 現在程式碼結構圖：
#
以上是OSS.Core基礎思路的詳細內容。更多資訊請關注PHP中文網其他相關文章！
