golang實現web中介軟體的一些思考

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

    最近陸續看了golang的Martini架構，也試用了，這個山寨自node.js的Express架構和最新的koa架構的golang架構，

同樣具有低耦合的特點，不過還是擔憂其效能，因為核心採用了reflect反射技術。

    golang的http包用Hander、handerfuc這些來解決中介軟體的問題，比如說驗證，日誌等，採取的是一層層封裝的方式，

好比洋蔥。這樣寫出來的代碼的缺點是耦合度高。如果中介軟體的順序或者名字變換，則有很多代碼需要改動。

     為了降低依賴，則需讓代碼不要直接引用前一層的名稱，加入第三方的一個間接層。reflect可行，但是reflect反射是基於對對象毫不瞭解，採取笨辦法逐步找出物件類型（結構體）的各個函數的名稱然後調用。

     如果採取以下方法似乎可以更好解決這個問題：

     每個待添加的組件都遵守一個簡單的介面約定，比如將需要匯出為外界調用的函數都保持在一個類似函數指標數組的資料結構中，這樣，架構對於要啟用的組件會知道如何去利用，有利於兩者的協同。然後，若啟用該組件，則可將這個數組和別的組件的數組放在一起，web應用依次調用。這種比較底層的方式，效率或者可以更高。

    為進一步考慮提高效率，若組件已耗用時間比較長，可採用gorutine + channel 的方式，來達到各個中介軟體filter 模式並存執行的效果？ golang的net/http底層已經採用了gorutine處理並發串連，不知會不會衝突？

    koa架構核心的co是基於ES6新規範中的yield關鍵字來實現協程的效果，這點和gorutine + channel比較類似。