物理架构规划图

2020-03-05 10:49:22   21  举报





这张物理架构规划图展示了一个复杂的网络系统，其中包括多个服务器、存储设备和网络设备。整个系统的中心是一台高性能的中央服务器，它通过高速以太网连接到各个子系统。在服务器群中，有一台专门用于数据存储的存储服务器，它通过光纤通道与磁盘阵列相连。此外，还有一台备份服务器，用于定期备份数据。在网络设备方面，图中显示了多台交换机和路由器，它们负责连接各个子系统并实现数据传输。整个系统的布局合理，各个组件之间的连接清晰可见，为未来的发展提供了良好的扩展性。总之，这是一个功能强大、结构紧凑的物理架构规划图。

系统架构

物理拓扑图

拓扑图

作者其他创作

大纲/内容

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区