上幾篇中描述了框架演進中的基本框架，也討論了一下基本框架的優缺點。

    在我的實際工作當中，基本框架只用了一次就被廢棄；基本框架搭起來的專案在一年後進行了重構，因此基本框架最終只存在不到一年時間。但對於架構師新手們，從設計一個基本框架開始，逐漸摸索、積累出對公司更有價值的框架，是一條可以切實落地的路。更重要的是，對一個沒有軟體基礎的公司而言，不管是框架、方案乃至方向，其實都是從一個專案一個專案中積累起來；專案積累多了之後，從公司戰略層面、研究院研究方向層面以及軟體部自身發展層面，都是需要抽象、升級、更新軟體體系（從需求到設計到實現）的。因此，以實現專案為目標，花較少的力氣迅速搭建一個基本框架，再在演進當中升級框架，不失為一個好的策略。

    基本框架之後，我的第二個過渡框架是以客戶端和伺服器的通訊協議為核心的。具體而下如下。

    伺服器端：

     這是伺服器端的頂層抽象。

     這是伺服器端的分層架構。

     從上面兩個圖可以看出，該架構主要考慮了幾個因素：

     1）對資訊入口和資訊出口的抽象和管理。

     2）模組化，並基於模組提供服務。

     3）資訊、解釋、服務、回覆的鏈條。

     對資訊入口進行抽象、集中和管理非常重要。這些資訊入口通常是伺服器運行當中，一個新的事務的起點；捋清了起點，就更容易搭建一個易讀、易改、易擴充套件的體系，隨之而來還有易開發、易除錯、易講解等好處；是我個人比較喜歡的一種方式。

     對於視音訊行業的軟體來說，最重要的入口資訊有兩大類：一是客戶端來的互動資訊；一是裝置來的互動資訊。因此，資訊入口最終落到了Win伺服器的一個網路介面函式，以及Codec伺服器、裝置代理伺服器的裝置回覆網路介面函式當中。

     對資訊出口做出抽象和管理也同樣重要。最重要的，這是和裝置互動的基礎；另一方面，這也是和客戶端互動的基礎；最後，可以基於此實現可靠的雙機熱備。和裝置互動的出口封裝在了Codec伺服器、裝置代理伺服器的資訊傳送函式中，和客戶端互動的功能封裝到了Win伺服器的資訊傳送及廣播函式中。

     在分層架構裡面，可以比較明顯看到，從下到上依次有工具層、服務層、解析層和入口層。其中服務層是內容最多，也最複雜的；其他層在架構定下來後，編碼量和編碼難度並不大。

     對服務層採用了強模組化設計，只向上層提供服務並嚴格限制了模組間的同層呼叫，對於框架的分工、優化、擴充套件，尤其是複用，是非常必要的。事實上，在上述框架的落地過程當中，Win伺服器層、主備模組都較難不利用同層間的模組呼叫，在後期進行了調整。

    事實上，如果你的框架只用一次，而且專案小好分工（尤其是一個人寫的），強模組化會增加不少工作量，意義也並不大。但如果核心程式碼超過了五個人合作，或者以後的專案也得複用程式碼，那強模組化是難以避免的。

    最後，從分層框架裡能看出資訊接入、解釋資訊、對外部命令進行服務、給與回覆的一個事務鏈條。對於客戶端伺服器架構，這個鏈條存在的意義是顯而易見的。因此對這個鏈條予以規範、抽象，對於實現功能、排查問題都很有幫助。

    下一篇會介紹該版本客戶端的框架。