物理架构规划图

Redis Cache 服务组

Nginx反向代理

Apache静态资源ServerFtp Server

平板

防火墙

Mobile

Tomcat Service 服务组

DB Core区

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或者迁移到“云”上吧。

台式电脑

MQ 队列服务组

硬件负载均衡或CDN轮询

App Core区

Tomcat App 服务组

笔记本

Mysql数据库集群

DMZ区