物理架构规划图

2019-11-13 13:38:45   27  举报





这张物理架构规划图展示了一个高度优化和可扩展的系统设计。图中的核心组件包括高性能的服务器集群、高速网络交换机和冗余电源系统，确保了系统的高可用性和稳定性。此外，通过分布式存储和负载均衡技术，实现了数据的高效存储和处理。在安全性方面，采用了多层次的安全策略，包括防火墙、入侵检测系统和数据加密技术，有效保护了系统和数据的安全。整个架构遵循模块化和可插拔的原则，便于未来的扩展和维护。总之，这张物理架构规划图为构建一个高性能、高可用、安全可靠的系统提供了详细的指导。

物理架构

作者其他创作

大纲/内容

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区