【 前一段時間寫了關於架構的總結，一共十篇，放在新浪博客上 :http://blog.sina.com.cn/zgwangbo001 ，今天放到csdn上】
也可以關注微信公衆號：simplemain
【第九階段 ： 邏輯關聯和層次劃分】
在第七階段的時候，我們提到了幾個問題，其中有一個就是業務關聯問題。當我們將業務拆分以後，多個業務之間沒有了耦合（或者是極弱的耦合），能夠獨立的運轉。這個看起來是多麼美妙的事情。但是實際情況真是如此嘛？
這樣的業務還真是存在的。比如我們有兩個業務blog和image。blog可以上傳和展示圖片。那image.XXX.com就提供兩個HTTP服務，一個是上傳的，一個是顯示的。這樣，blog業務就可以通過簡單的URL耦合來實現了圖片的這些功能。
但真是所有的情況都是如此的嘛？
我們再看一個例子。比如blog和用戶相關的業務。用戶可以在blog登錄、註銷等，blog需要實時判斷某一個用戶是否登錄等。登錄和註銷兩個操作似乎可以通過類似account.XXX.com提供的login和logout這樣的URL接口實現。但是每次頁面瀏覽要判斷用戶是否已經登錄了，出於安全性等多方面的考慮，就不好通過URL來提供這樣的服務。
那看起來，我們在第七階段提出的按業務切分的理想情況，在實施的時候，並不是那樣的完美。在實際的運行中，耦合是不可避免的。
有了耦合，我的第一反應基本上就是看看是否能夠藉助設計模式來解決這些的問題。其實呢，設計模式早已經給我們比較好的解決方案（但絕對不是完美的解決方案。俗話說的：沒有最好，只有更好！）。在這篇文章的最初已經提到過了，爲了增強網站代碼的可重用性，我們引入了一些框架，比如：struts、spring、hibernate等等。其實這些框架，基本上是圍繞着MVC的原則來設計的。struts、webwork等框架，將視圖和邏輯控制分離；spring負責組織業務邏輯的數據；hibernate很好的做了數據訪問層的工作，實現了ORM。
那現在我們採用多機分佈式的時候，是否可以借鑑這些思想呢？其實也是可以的。
我們來分析一下我們的業務。
其實我們的業務大多可以分爲兩類：
一、與實際的產品相關的業務，比如：blog、news等等。這些業務之間的耦合度不是很高，往往可以通過提供HTTP的接口即可實現業務需要的互通。因此，從這個層面上來看，是可以基本做到業務垂直拆分的。
二、基礎服務，比如：用戶帳號管理、消息通知等等。這些服務往往被多個業務所依賴。他們需要提供更通用的、更安全的、更穩定的接口和服務。但是，關於基礎業務的理解和劃分，是沒有一個特定的規則的。比如，image圖片服務，他有可能剛開始是一個業務服務，到一定階段以後，多個系統需要對他有強的依賴，自然也就成爲了一個基礎服務。
所以，從上面的描述，我們可以發現服務的類型，並不是固定的。要很好的解決服務耦合的問題，也並沒有一個十分完美的解決方案。我們能做的就是儘量降低耦合，通過某種方式，能夠很好的達到耦合和可維護性的平衡。
總的來看，MVC模式其實給我們提供了一個比較好的方案。
我們把系統從兩個維度上進行劃分：垂直（業務）和水平（邏輯）。
我們做了這樣的劃分以後，似乎看起來沒有實質性的改變。但是，我們可以明確了我們設計的原則，並強化了代碼的可複用性。另外，最關鍵的是，服務之間的依賴和耦合關係，有了明確的地方來做。同時，我們還可以將業務內部的結構進行拆分，更好的增強複用。
數據訪問和組織層、數據存儲層，這兩個位於下游的層次，應該是屬於系統內部的層次，原則上是最好不要對外開放接口的，否則，系統間的耦合就會非常的大。並且可維護性會非常的難。而邏輯控制和視圖層，實際上是提供對外（對用戶或者是外系統）最好的訪問的入口。當然，這個入口可以是HTTP協議的，也可以是非HTTP協議的。
比如，對於account服務，可以提供基於HTTPS對用戶開放的login和logout服務，也提供基於XXX Protocol數據交換的協議的給內部的get_session服務。從簡單的設計上來看，只是根據服務不同，提供不同的數據交換格式、以及不同的安全控制。這樣也是秉承了一個高內聚低耦合的原則。
這裏還有幾個及其重要的問題沒有詳細的提及：系統內外的數據傳輸協議、接口API、服務訪問定位。這幾個問題實際上還跟運維問題緊密相關，都會放到後面來詳細討論。
―――――――――――――春天的分割線 ―――――――――――――
