洞悉本質 | 論軟件設計中間加一層的威力

爲何寫這個主題？

軟件設計中間加一層的解決方案，隨處可見。寫本文的目的也是由於看到不少場景都是基於這個思想的應用，就想着梳理一下，讓你們看到一些本質的內容。

順便以現今主流的一些技術或概念做爲樣本，進行拆解，輔助你們理解。

搞清底層邏輯和設計思想，纔不會被各類技術名詞，技術概念整的一臉懵逼。

如今鋪天蓋地的三高講解、培訓，千萬悠着點學，別整的身體三高了，哈哈，開個玩笑。

可是軟件的設計思想層面的東西，編程的一些思考，咱們也需學習提高，思考沉澱。學技術不僅有三高。

並且思惟層面的東西不像學習個具體的技術框架，全身心投入個幾天甚至幾個小時就能上手使用了。而是須要一點一滴積累，一點一滴思考總結。

看別人的總結也不行，別人的永遠是別人的，參考能夠，必定要本身總結。

迴歸主題，今天分享的是「論軟件設計中間加一層的威力」 。

正文開始

你熟悉的jvm

先看個jvm得簡易執行圖。

上圖jvm部分是簡化後的並不嚴謹，重點在總體結構上，能夠看到，JVM處於class文件與操做系統之間。JVM針對不一樣操做系統作了實現。不一樣平臺的JVM將class解釋爲對應平臺的機器碼執行。

經過在class與操做系統之間加上JVM以後，之後出現新的操做系統，只須要針對對應平臺實現一套JVM（JVM的各平臺實現是不須要咱們關心的，有官方團隊處理），項目便可在平臺上運行，這即是Java宣稱的一次編寫，處處運行。處處運行的前提是，處處都須要有JVM的實現。

JVM在這裏就充當了一箇中間層，隔離了開發環境與操做系統。

隔離的好處是消除了雙方之間直接接觸帶來的相互影響和不適應，這些都在JVM這一層化於無形。

對項目開發人員來講就不用關心底層是什麼操做系統，我只對接JVM。操做系統的任何變化、升級都跟我無關，這都是JVM須要考慮的事。

對操做系統而言，也不須要由於要運行你的class而作出任何改變。這也是JVM須要考慮的事。

那些不知道在哪能用上的設計模式

代理模式
算是設計模式中比較簡單也比較容易理解的一種，看個圖。

加上中間的代理層後，對調用方來講並不知道實際類的真實狀況，這樣一方面能夠隱藏實際類的信息，另外一方面能夠在代理層對調用方和實際類進行控制，能夠作一些限制操做，又或者添加一些其餘的處理邏輯，好比常見的在調用先後輸出個日誌。而這個處理過程對調用者和實際類來講是無感知的。


外觀模式
一樣先看個圖

中間加了外觀角色這個中間層後，對調用方來講，就變得簡單了許多，原來哼哧哼哧調3個，如今簡簡單單調一個。
其餘還有很多，限於篇幅，就不列舉了。

消息中間件

這裏主要說下用消息中間件解耦的場景，兩個服務之間消除依賴，藉助消息中間件便可實現，不用消息中間件能夠實現嗎，徹底能夠，本身實現一箇中間的交換系統沒什麼不能夠，只不過須要投入時間精力，因此你們都用現成的。

此場景下僅僅解耦兩個服務之間的依賴實際上是沒什麼可炫耀的，它真正的威力在於加了中間層後將多服務之間多對多的調用結構轉換爲了多對一結構。

以下圖

右圖比左圖清楚的不是一點點，圖能看清楚，代碼實現就有了寫清楚的前提。

網關

仍是先看個圖

加上網關這個中間層後，一方面能夠隱藏真實服務的訪問地址，另外一方面對調用方來講統一了調用入口，同時能夠在網關層統一對全部後端服務添加全局的處理邏輯，如鑑權、限流、日誌記錄等等。

最後再舉個項目中的場景

以前項目中遇到的一個場景是，須要經過一個很複雜的統計SQL最終輸出一個客戶想要的結果，數據量較大時查詢很是慢，在數據實時性要求不高，又不想引入多餘技術組件的狀況下，怎麼處理這種問題 ？

解決辦法就是加個中間結果表，定時執行統計SQL將結果輸入到結果表，查詢功能直接查詢結果表，就很方便的解決了。處理過程以下圖

以上僅僅列舉了部份內容，沒提到的就只能留給讀者自行發覺領悟嘍。

總結

結合上面的實例拆解，總結下，中間加一層的設計來講大概能夠解決如下場景的問題。

這裏特別強調下加一層是個設計思想，不光能夠解決技術問題，工做中平常生活中也能夠用到，因此關鍵的關鍵是須要吸取這種設計思想。

 

再回到技術場景下來講不一樣場景的處理方式會不同，不必定是非要引入一個技術組件這樣，好比某些特定場景下，加個字段，加個類均可以實現。必定要活學活用。

解耦

解耦的目的是爲了後續可擴展，可維護，提高軟件的可修改性，保證各自的獨立進化。

聚合

爲了簡化上層調用和方便獲取結果，添加一個聚合中間層，這裏仍是帶一點解耦和隱藏細節的做用，雖然說不是聚合的重點，但確有此功效。

統一處理

典型場景如上面提到的網關的應用場景和做用，如鑑權中心，日誌記錄等均可以在網關層統一去作。

隱藏細節

系統有沒有本身的一些小祕密不想讓外界知道，有怎麼辦 ？加上一個對外的調用層，隱藏真實服務地址，改變方法名，改變參數你想作的統統能夠作到。

屏蔽差別

上面沒提到的對應的場景，其實拿設計模式中的適配器來講這個比較合適，一個典型的場景是一個兩插的插頭如何接入到一個三口的插座上。中間加個轉換頭就能夠作到。經過轉接頭間接屏蔽了接口間的差別。

對應到系統中也是如此，一個接口輸出的是xml，而另外一個接收方須要的是json，兩方都不能改動狀況下，怎麼作，那就是加個中間轉換層。屏蔽數據報文的差別。

最後

好的設計其實必定程度上能夠避免一些技術問題，簡化問題場景，而這須要咱們不斷摸索、不斷嘗試、不斷學習、不斷總結。

以爲還行，動動手指留個贊。

以上就是今天的內容，咱們下期見。