這次想寫乙個偏技術的話題，企業應用程式架構設計，鄙人對系統結構設計有一些特殊愛好，合理的體系結構，是軟體開發中一切美好的事物即將發生的前提，反之，欠考慮的體系結構，會是噩夢。這裡，我有乙個小建議，作為讀者的你，發現公司待遇不錯，公司前景也美好，公司的活也不重，但是有一些a級人才總留不住，給承諾留不住，加工資也留不住，反正就是要走，這個時候，可以想想應該是某個方面錯了，而且是無法挽回的錯誤，因為這些a級人才卓越的洞察力，發現了負責的系統在目前的時間，空間條件內，完全沒有了可行性。其中，因為軟體體系結構有問題而沒法走下去的，肯定是乙個重要原因之一。接著講講我的特殊愛好，其實也是我個人學習和實踐總結的一些前輩們都經常傳授的經驗，觀點。
世界上最美好的結構是層次結構。這是區區的第乙個觀點，如果系統沒有分層，再多的理念在我看來也是一團糟糕。層次結構設計，是天然的，容易理解，設計經驗也方便分享；讓大型工程可以從容的分解，只需要對外發布提供服務的介面，同時使用低層次提供的服務即可，規範有序的使用原則，從而避免了複雜的呼叫關係。如果乙個層次結構出現了多向迴圈呼叫，那他就不是層次結構，而是網狀結構，有人說，網狀結構不是更靈活，更有效率嗎？的確如此，層次結構的好處是把複雜度控制在普通工程師都能控制的範圍以內，天才能夠掌握控制的結構，工程上極有可能不可行。如同tcp，ip協議族，這就是層次結構設計的代表作。
應用體系設計應該是鬆散耦合，體系中每個系統都應該具有獨立執行能力，應該是可以輕鬆實現公升級繫結與降級解耦。如同乙隻壁虎，平時拖著乙隻大尾巴，幫助自己儲存能量，保持平衡，一旦遇到危險可以脫掉尾巴，還能夠輕鬆逃跑，一點也不影響它的生活，至少是不會影響它的生存。如同作業系統，檔案系統崩潰，作業系統還可以用，網路崩潰，也可以用……
應用系統架構應該是可監控，可除錯的，而不是不知道它到底怎麼樣，可能會怎麼樣，它的行為是可以**的，它的當前執行時是可以監控，應用系統作為乙個體系執行，絕對不能通過猜測。因此，設計系統時，可監控，可調式，這些看起來多餘的功能，多餘的設計，是不能夠偷懶，省略的，否則以後將會是乙個很大的隱患。
首先定義目標：
資料安全與穩定服務
伺服器集群的狀態可監控
共享，獨立的二級網域名稱訪問支援
每個組織都是獨立的應用例項，互不影響。
每個應用例項能夠快速關閉與備份
例項個數擴充套件時，可以通過自動新增新的伺服器滿足擴充套件需求
例項降級時可以快速降級，縮減伺服器與應用例項
應用例項自動公升級
應用系統內部任意乙個系統崩潰都不應該影響整體的系統可用性
系統之間沒有強依賴，子系統可以隨時剔除不影響應用服務的可用性
目標比較多，不過考慮的時候，我認為，有必要詳細一點，做設計時，根據實際的情況可以分步實現。
整體的結構效果圖如圖：
邏輯結構分為：
前台系統
應用例項集群：使用者開啟乙個組織例項，獲取完整的oa系統應用功能
後台系統
負載均衡中介軟體:各個應用例項呼叫批作業服務，快取服務，監控服務的中介軟體，主要用來做負載均衡與路由**
批作業例項集群：處理各種定時的或耗費系統資源較多的作業，比如郵件，簡訊，等
快取集群：提供快取服務，提高系統效能
備份作業系統：提供主動的備份機制，被動熱備份機制，備份資料並儲存到異地
監控系統：提**用例項的日誌，反饋處理服務，應用系統運**況監控服務，伺服器狀況監控服務
自動部署系統：應用例項自動快速部署，自動公升級服務，重灌，**服務，二級網域名稱分配與**服務
這段時間正在設計基於html5流程設計器，更新少點，見諒！
獨步天下的創業歷險記
獨步天下的創業歷險記2 創業背景
鄙人非名校，年過30，白髮初生，小寶寶未滿百日，沒房沒車，也沒有錢，自稱只剩下帥 沒有大公司工作背景 注 解釋一下，富士康是巨型工廠，區區做過一年，如果可以重來，我願意呆過三年以上，現在看見年輕的朋友老換工作，心裡著急，就像看見當年的我，換工作這個話題，以後有機會我們單獨篇幅聊 就連最引以為豪的程式...
獨步天下的創業歷險記 論產品的靈性
作為乙個軟體工程師。也許你認為自己掌握了很多技術，理論上講，你是可以開發出很多產品的，說的直白點就是，這個世界上有的軟體應該都能做出來吧！事情往往沒那麼簡單。你雖然掌握了足夠的技術，但是，這並不意味著，你就可以作出有用的產品。產品的價值是市場決定，是使用者決定，而不是技術決定，更不是工程師決定的。這...
獨步天下的創業歷險記6 一葉知秋
先向大家匯報一下最近的工作進展吧。這應該是上次說的閉關日期的開始，我準備做流程設計器，現在終於做完了，當然，兩個月，不止做了這些，還有表單設計器，組織結構的設計等等一大堆讓我不願意太多回想的功能模組。畢竟，軟體設計不是談情說愛，那麼天真，那麼爛漫，更加不是附風庸雅，也沒辦法那麼優雅，那麼從容。他可能...