軟體架構之我見

標籤：

　　在傳統公司專屬應用程式開發中，項目往往採用"煙囪式"開發模式，資料處理，商務邏輯以及介面操作糅雜在一起，快速推出一個可用版本，這本無可厚非。

　　但是隨著公司專屬應用程式的發展以及移動互連網的推進，你會發現你的系統無法輕易對接其他廠家系統，也無法快速開發其他平台應用。面對這樣的問題，我們不得不考慮架構的變更。而這一切其實都是可預見的或者說是可以提早規劃的。

傳統架構的問題

傳統企業開發架構面對變化總是有諸多的不足：

1.許多模組都要重複造輪子

2.模組間的耦合過深

3.出現問題難以追溯

4.可測試性較差

5.系統間資料和服務無法共用

這樣隨著項目負責程度的增加必然會導致項目越來越冗餘，越來越難以維護。

架構劃分

　　而在我看來，企業軟體的開發應該分成服務和終端這兩塊。

　　案頭應用，web程式，以及ios,android程式都可視為終端，作為終端我的工作就是展示資料，發起命令/請求，而並不關心其中有多少的商務邏輯和資料處理，我要的只是資料。

　　而作為服務，我不關心你介面怎麼布局，我需要的只是響應你的請求給你資料就行了。

　　這樣的一種架構我覺得能讓前台和後台分開協同工作(誰說傳統型程式就不能分前後台了)，並且由於統一的商務邏輯可適用於多個終端。

可擴充性

　　面向服務是一個解耦的過程，松耦合降低了服務之間的依賴。在大項目中為了保證大並發和高可用性，我們通常會將服務組組成一個叢集或者將服務拆分為多個部分分開部署。

採用叢集部署的模式，通過負載平衡的保持服務的可用性以及每一台伺服器的效能(圖示為簡單架構圖，也有採用主從機模式以及分散式資料庫模式)

　　採用服務拆分， 將服務拆分到多個伺服器從而達到“分布式”的效果。對於web應用圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的甚至多個圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力。

 

緩衝模式

　　使用資料緩衝在軟體工程中是一個非常有意義的策略，不僅僅可以減少資料庫負載，而且當資料緩衝在記憶體中，能大大提高了的讀取速度。

你可以在你的服務中加入記憶體緩衝也可以將你的資料放到3方的高效能緩衝中(memcached,radis等)。

而作為緩衝你必須關注的幾個方面：

1.這個資料緩衝的Key是什麼

2.這個資料緩衝生命週期有多長

3.如何在外部服務中訪問你的緩衝

4.快取資料的落地策略

5.分布式緩衝的主從備份

等等，具體的緩衝策略需要你結合項目考慮，個人比較推薦memcached，夠用就行。

 

wcf,wcf restful,webservice,webapi?

　　對於.NET系中這些技術何時使用的問題，上述技術都能做到解耦資源與服務，而採用哪種技術需要視乎你的應用情境。

　　個人理解而言，對於企業內網應用來說我傾向於使用wcf tcp模式，效率高並且支援雙工通訊。

　　而需要對接web和行動裝置 App的時候優先推薦webapi，標準化http協議。之前也用過wcf rest來做手機應用，體驗過web api之後感覺wcf還是太重了，webapi得心應手啊。

 

總結

　　煙囪式的開發架構我覺得在開發項目原型或者小型項目時可以採用，但凡有可能涉及到web應用和手機應用或者有大並發可能的時候，你得該思考下整體項目的開發架構了。

以上為個人對自己項目的一些經驗總結，理解不太深刻的地方歡迎大家指出。

 

軟體架構之我見