软件系统结构图的宽度是指整体控制跨度(最大模块数的层)的表示。
系统结构图架构的几个要点:
系统安全这是首要考虑的,网络可以划分为3个区:
DMZ区可以直接公网访问,也可以与AppCore区互通,但不能直接与DBCore区互通(通常这里放置反向代理Web服务器);
AppCore区能与DMZ区、DBCore区互通,但是无法直接从公网访问(通常这里放置应用服务器、中间件服务器之类);
DBCore区仅与AppCore区互通(通常这里放置核心数据库)。除了“硬件负载均衡”节点外,其它节点都可以部署成集群(DB有点特殊,传统RDBMS要实现分布式/集群还是比较困难的,要看具体采用的数据库产品,并非所有数据库都能方便的做Sharding。
Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBMMQ本身就支持集群、FTPServer配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说。
尽量采用开源成熟产品,jboss、redis、nginx、apache、mysql、rabbitMQ都是很好的选择。硬件负载均衡通常成本不低,但是效果明显,如果实在没钱,域名解析采用DNS轮询策略,也能达到类似效果,只不过可靠性略差。
常规企业应用中,传统关系型数据仍然是主流,但是no-sql经过这几年发展,技术也日渐成熟了,一些非关键数据可以适当采用no-sql数据库,比如:系统日志、报文历史记录这类相对比较独立,而且增长迅速的数据,可以考虑存储到no-sqldb甚至HDFS、TFS等分布式开源文件系统中。
如果系统数据量级达到单机RDBMS的上限,尽早考虑Sharding方案,目前mysql在这方面比较成熟,其它数据库就不好说了。
webserver、appserver这些一般都可以通过集群实现横向扩张,满足性能日常增长的需求。最大的障碍还是DB,如果规模真达到了DB的上限,还是考虑换分布式DB或者迁移到“云”上吧。
扩展资料:
软件结构图是为了反映软件系统中组件之间相互关系和约束的体系结构设计图,称为软件体系结构图更为合适,一般通过分层次或分时间段等方式说明体系结构的各个组成部分的组合关系。
在结构化设计方法中,软件结构图主要分为变换型软件结构图和事务型软件结构图两种。
软件结构包括构成系统的设计元素的描述、设计元素之间的交互、设计元素的组合模式以及在这些模式中的约束。一个系统由一组构件以及它们之间的交互关系组成,这种系统本身又可以成为一个更大的系统的组成元素。
参考资料:百度百科-软件结构图