關於架構的一些自己的想法

談到架構這種東西,總感覺有一種很高大上的感覺,不過本人目前接觸的項目還沒有達到阿里或者騰訊那種億萬級別的訪問和流量,所以其實也沒啥深度的經驗。這裏只是就架構的核心的幾個原則,結合目前線上的項目隨便講講罷了。

講到架構設計其實從簡單來說就是在具體業務框架的實現、團隊開發和維護的效率、整體項目的安全之間達到的一個動態平衡的模型。

 

一、關於業務代碼框架的實現

關於開發由具體的業務和產品來驅動,是目前大部分互聯網公司很熟悉的模式。這裏面每個公司產品不一樣,具體實現的細節也是不可一概而論。但是本質其實也很簡單,就是保證用戶在使用公司產品的時候能夠用的爽,雖然用戶體驗是一個綜合的工程,但是作爲技術保證速度和流暢也是最基本的。然而,這最基本的條件,在流量達到一定的量級之後,做起來也並不是一件很容易的事情,圍繞這個也出現了很多細分的技術和各種框架。

比如:在負載均衡上LVS, NginX等都是比較成熟和常用的開源方案;提高用戶的訪問速度,CDN加速也幾乎成爲一種標配的服務;MemCached分佈式緩存也在近些年得到了相當規模的應用;在緩存技術上進一步深入發展出來的NoSql數據庫也是在訪問速度的提升上起到了很重要的作用(MongoDB,Redis等等)。這些都是近些年發展起來的,比較成熟的技術框架和解決方案,其實對於大部分項目這些技術如果能用的足夠精通,再加上消息隊列之類的技術,絕對用戶體驗槓槓的。

本人的項目因爲是一個比較小的項目,所以暫時並沒有相關的必要去使用緩存相關的技術。而且項目目前還在發展迭代的過程中,也許等用戶量增長起來之後,會用到一些相關的技術。本人所在的移動團隊目前有用到MongoDB, Redis, MemChed, NgniX等,當然還有一些開源的插件之類,這裏不做深入。

整體的項目其實在業務代碼的實現上並沒有採用MVC,而是有點類似於三層架構,視圖展示直接對應相應的H5頁面,一個單獨的類進行業務邏輯的處理,數據訪問層使用工廠模式,直接動態創建對象,然後直接調用接口的具體實現。

據說因爲項目前期業務發展速度的需要,並沒有去特別花時間做整體的規劃和項目重構,整體看上去比較糙。目前也存在一些問題:大量代碼重複,代碼複用率低;底層公共方法沒有持續迭代,各自寫業務基本重新實現一遍底層;安全問題,在不同的項目中,各自的加密解密方法混亂,密鑰直接寫死在業務代碼中。我會在接下來的日子裏,根據自己的思考,儘量去完善,等以後有效果再回頭細說。

 

二、團隊開發效率

團隊開發效率這個東西,其實不太好說。這個不光是人的問題,還有整體技術架構對開發效率的影響。大名鼎鼎的敏捷開發,各種分佈式版本管理工具,大公司的極其規範的開發文檔,各種造輪子,其實本質都是對團隊開發效率的提升。尤其是現在用的最多的MVC架構,MVVM架構之類,更是在架構層面直接固化下來。其實在整個過程中最精髓的就是讓程序員做更少的事情,更容易的做事情。

分佈式版本管理工具的出現(如svn, git等,當然這裏有各種比較,有機會也可以說說),讓開發的工作可以多線程運行;MVC架構對於視圖和邏輯層的分離,以及單獨的model層,大大的降低了項目的耦合度,相對來說在項目開始的時候工作稍微多一些,但是一旦項目團隊更替,業務拓展或者對原有的業務進行更新優勢立竿見影。還有很多公司底層會封裝一個framework,將底層的服務,安全方法,各種工具都放在裏面,這也是方便開發的一個常見的方式。

本人所在的移動團隊,整個項目在這個部分感覺做的並不是很充分。在第一部分已經說過,整個項目目前的狀態比較糙,也沒有看到公共框架和常用的底層方法有什麼迭代和更新,或許正在進行但是我這小羅羅還不知道罷了。不過底層公共的方法,至少發起htpp異步請求,數據庫查詢的公共方法得把安全相關需要注意的地方封裝一下下吧。

 

三、項目的安全

其實關於項目安全這點,我還是有點問題的,我在開發的過程中,出現了幾個問題,包括用戶敏感信息加密,防Xss攻擊過濾,簽名驗證之類的。我整體的項目都看了一下,歷史項目參差不齊,很多的並沒有做以上的工作,而且,相關的方法也要自己單獨寫方法,並沒有封裝的framework方法,導致每個項目的安全係數都不一樣。如果出現人員的變動,項目的安全因素,並不控制在項目小組組長的手上,也許就會有出現問題的潛在危險。

簽名驗證和防Xss攻擊過濾,應該整合放進底層封裝的框架,然後通過引用的形式使用具體方法,保證在使用的過程中,具體的代碼處理業務的程序員涉及不到,由另外的人或者小組單獨負責底層框架的方法和項目安全。加密的密鑰以及相關的參數以及解密的相關算法,最好可以封裝加密,然後引用調用,保證項目的加密和解密的安全由相關人員和小組單獨負責。不至於出現一個具體業務一套加密解密,而且還不能確定是不是安全。

當然很多的問題,是伴隨着http協議本身的特性而產生的。目前據說項目在準備升級https,升級之後,很多問題自然會迎刃而解。也許會有其他的問題出現,但是https至少在安全上比原來的裸奔要好太多了。

 

總結:

歸根到底,都是人的問題,如果都想谷歌那樣招的人都是大神級的人物,估計啥問題都沒有了。當然了,如果給我足夠多的錢,我也是有可能有動力在工作中發揮出超常水平的。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章