軟體架構之我見

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

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

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

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

2.模組間的耦合過深

3.出現問題難以追溯

4.可測試性較差

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

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

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

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

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

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

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

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

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

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

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

而作為快取你必須關注的幾個方面：

1.這個資料快取的key是什麼

2.這個資料快取生命週期有多長

3.如何在外部服務中訪問你的快取

4.快取資料的落地策略

5.分布式快取的主從備份

等等，具體的快取策略需要你結合專案考慮，個人比較推薦memcached，夠用就行。

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

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

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

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