晚上把公司應用的架構結合之前研究的東西梳理了下，整理了一張架構規划圖，貼在這里備份
下面是個人理解的做架構的幾個要點：
1、系統安全
這是首要考慮的，以這張圖為例，網絡划分為3個區：
a) DMZ區可以直接公網訪問，也可以 與App Core區互通，但不能直接與DB Core區互通 (通常這里放置 反向代理Web服務器)
b) App Core區能與DMZ區、DB Core區互通，但是無法直接從公網訪問 (通常這里放置 應用服務器、中間件服務器之類)
c) DB Core區僅與App Core區互通 (通常這里放置 核心數據庫)
2、盡量消除單點故障
上圖中，除了“硬件負載均衡”節點外，其它節點都可以部署成集群（DB有點特殊，傳統RDBMS要實現分布式/集群還是比較困難的，要看具體采用的數據庫產品，並非所有數據庫都能方便的做Sharding），Jboss本身可以通過Domain模式+mod_cluster實現集群、Redis通過Master/Slave以Sentinel方式可以實現HA、IBM MQ本身就支持集群、FTP Server配合底層儲存陣列也可以做到HA、Nginx靜態資源服務器自不必說
3、成本
盡量采用開源成熟產品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的選擇。硬件負載均衡通常成本不低，但是效果明顯，如果實在沒錢，域名解析采用DNS輪詢策略，也能達到類似效果，只不過可靠性略差。
4、Database問題
常規企業應用中，傳統關系型數據仍然是主流，但是no-sql經過這幾年發展，技術也日漸成熟了，一些非關鍵數據可以適當采用no-sql數據庫，比如：系統日志、報文歷史記錄這類相對比較獨立，而且增長迅速的數據，可以考慮存儲到no-sql db甚至HDFS、TFS等分布式開源文件系統中。
如果系統數據量級達到單機RDBMS的上限，盡早考慮Sharding方案，目前mysql在這方面比較成熟，其它數據庫就不好說了。
5、性能
web server、app server這些一般都可以通過集群實現橫向擴張，滿足性能日常增長的需求。最大的障礙還是DB，如果規模真達到了DB的上限，還是考慮換分布式DB或者遷移到“雲”上吧。