此次想寫一個偏技術的話題,企業應用程序架構設計,鄙人對系統結構設計有一些特殊愛好,合理的體系結構,是軟件開發中一切美好的事物即將發生的前提,反之,欠考慮的體系結構,會是噩夢。這裏,我有一個小建議,做爲讀者的你,發現公司待遇不錯,公司前景也美好,公司的活也不重,可是有一些A級人才總留不住,給承諾留不住,加工資也留不住,反正就是要走,這個時候,能夠想一想應該是某個方面錯了,並且是沒法挽回的錯誤,由於這些A級人才卓越的洞察力,發現了負責的系統在目前的時間,空間條件內,徹底沒有了可行性。其中,由於軟件體系結構有問題而無法走下去的,確定是一個重要緣由之一。接着講講個人特殊愛好,其實也是我我的學習和實踐總結的一些前輩們都常常傳授的經驗,觀點。
世界上最美好的結構是層次結構。這是區區的第一個觀點,若是系統沒有分層,再多的理念在我看來也是一團糟糕。層次結構設計,是自然的,容易理解,設計經驗也方便分享;讓大型工程能夠從容的分解,只須要對外發布提供服務的接口,同時使用低層次提供的服務便可,規範有序的使用原則,從而避免了複雜的調用關係。若是一個層次結構出現了多向循環調用,那他就不是層次結構,而是網狀結構,有人說,網狀結構不是更靈活,更有效率嗎?的確如此,層次結構的好處是把複雜度控制在普通工程師都能控制的範圍之內,天才可以掌握控制的結構,工程上極有可能不可行。如同tcp,ip協議族,這就是層次結構設計的表明做。
應用體系設計應該是鬆散耦合,體系中每一個系統都應該具備獨立運行能力,應該是能夠輕鬆實現升級綁定與降級解耦。如同一隻壁虎,平時拖着一隻大尾巴,幫助本身儲存能量,保持平衡,一旦遇到危險能夠脫掉尾巴,還可以輕鬆逃跑,一點也不影響它的生活,至少是不會影響它的生存。如同操做系統,文件系統崩潰,操做系統還能夠用,網絡崩潰,也能夠用……
應用系統架構應該是可監控,可調試的,而不是不知道它到底怎麼樣,可能會怎麼樣,它的行爲是能夠預測的,它的當前運行時是能夠監控,應用系統做爲一個體系運行,絕對不能經過猜想。所以,設計系統時,可監控,可調式,這些看起來多餘的功能,多餘的設計,是不可以偷懶,省略的,不然之後將會是一個很大的隱患。
接下來說講咱們正在作的,咱們設計的是一個在線的saas架構的企業服務系統。把一直以來的一些思考和外面學習的一些知識結合起來作一個易於實現 ,符合現階段要求, 同時又有潛力發展的架構。
首先定義目標:
-
-
- 可以知足在線的註冊便可使用。
- 數據安全與穩定服務
- 服務器集羣的狀態可監控
- 共享,獨立的二級域名訪問支持
- 每一個組織都是獨立的應用實例,互不影響。
- 每一個應用實例可以快速關閉與備份
- 每一個實例的使用,訪問都是快速的,單個實例支持最高1000人的同時在線使用
- 實例個數擴展時,能夠經過自動添加新的服務器知足擴展需求
- 實例降級時能夠快速降級,縮減服務器與應用實例
- 應用實例自動升級
- 應用系統內部任意一個系統崩潰都不該該影響總體的系統可用性
- 系統之間沒有強依賴,子系統能夠隨時剔除不影響應用服務的可用性
目標比較多,不過考慮的時候,我認爲,有必要詳細一點,作設計時,根據實際的狀況能夠分步實現。
總體的結構效果圖如圖:
邏輯結構分爲:
前臺系統
帳號系統:用來管理用戶的帳號,登陸,註冊業務,幫助系統,活動推薦等。
應用實例集羣:用戶開啓一個組織實例,獲取完整的oa系統應用功能
後臺系統
負載均衡中間件:各個應用實例調用批做業服務,緩存服務,監控服務的中間件,主要用來作負載均衡與路由轉發
批做業實例集羣:處理各類定時的或耗費系統資源較多的做業,好比郵件,短信,等
緩存集羣:提供緩存服務,提升系統性能
備份做業系統:提供主動的備份機制,被動熱備份機制,備份數據並保存到異地
監控系統:提供應用實例的日誌,反饋處理服務,應用系統運行狀況監控服務,服務器情況監控服務
自動部署系統:應用實例自動快速部署,自動升級服務,重裝,回收服務,二級域名分配與回收服務
這裏的系統每一個單獨設計都將會是一個挑戰,有可能之後分開篇幅寫出來分享。今天暫時寫這麼多,下一篇的主題我會想一想是些技術相關的仍是產品相關的,或者是市場相關的,有興趣的朋友能夠跟我溝通一下。
這段時間正在設計基於html5流程設計器,更新少點,見諒!
獨步天下的創業歷險記
個人文章首先會在微信公衆號(acao1984)中推送,次日將發佈到個人幾個博客頻道,請關注個人同窗,請關注個人微信公衆號
曹志輝 「全棧工程師」 有觀點的憋足程序猿, 夜光雲科技創始人 正在作一個惟美的在線協同辦公產品,個人公衆號裏將不定時分享 我我的的真實創業大冒險經歷,關於產品,關於編程,關於職場,關於趨勢,也可能包含其餘話題,與各路朋友共勉。