java web系统架构设计需要解决的几个问题-优快云博客

本文探讨了JavaWeb系统架构设计中的关键问题，包括应用层架构、数据层架构、负载均衡和高可用设计等方面。强调了子系统划分的重要性，并讨论了不同架构方案的选择依据。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

下面列出了java web系统整体设计时需要解决的几个问题，肯定不够全面和深入，欢迎大家补充和交流，呵呵。

系统架构的工作是需要长期一线编码经验的，管理方向的项目经理之类的应该较少参与，长期非一线人员主导了架构及细节工作，很可能设计出来的系统缺乏根据，个人认为此类系统具备较好的成长性的可能性较小。

1. 应用层架构

1.1 子系统的划分

子系统的划分只存在于分布式系统中，通常情况下，子系统的划分需要从业务和技术两个维度来考虑，以业务分析作为划分依据，以实现的复杂度、合理性、性能等作为要求来综合考虑和设计子系统的划分。

1.2 子系统间的通讯方式

子系统之间的通讯方式是否合理和高效，在很大程度了约束和决定了系统的整体性能、扩展性、可维护性等表现。通常的选择包括基于tcp协议、http协议，传输的数据包括二进制流，json格式数据，xml格式数据等。

1.3 事务的选择和定义

1.3.1 选择本地事务还是分布式事务，根据是什么，数据层的架构方式对事务模式的选择有较大的影响，需要重点分析。一般不建议采用分布式事务，主要因为该方式实现机制较为复杂，因而响应不够迅速。

1.3.2 分布式系统要考虑子系统之间接口的事务方式，采用什么方式可以较好的保证系统数据完整性和性能。

曾经在一个企业应用项目，架构师采用自定义回滚接口的方式来保证子系统见消息传递的事务处理，实践证明也是一种可行的方式。参与的一个互联网项目，采用了调用失败后定时再次调用的方式从某种程度降低子系统间接口传递消息失败的几率的方式，虽然从逻辑上讲不是比较理想，但比较实用，慢慢进化吧。

1.2 逻辑架构设计

主要和业务相关度较大，在对业务的深入分析和理解的基础上，归纳总结出合理的逻辑模型是最终的目标。

逻辑模型基于业务，并进行抽象，根据业务和实际需求，需要确定大的方向，包括是设计为集中式系统还是分布式系统，如果是分布式系统，那系统如何拆分是进一步要解决的问题。

1.3 部署架构设计

部署架构一般包括网络拓扑架构、系统部署架构。网络拓扑架构主要任务是完成系统的网络设备的选择，如何组合和设计，例如根据网络安全的需要，合理地划分网络安全区域；根据需要选择防火墙、路由器、网关等网络设备，以及设计为既能保证安全，又能保证尽量简单的结构，减少不必要的“跳”，就减少了系统的复杂度，减少了运维和监控的工作难度。

1.4 web服务器的选择，是选择tomcat级别的还是应用服务器。

web服务器轻量级，免费开源是很好的优势，对于中小型项目已经够用。较大型或对web服务器的稳定性、扩展性、技术咨询较高的项目，采用应用中间件也是较好的选择，毕竟商业的软件，技术支持方面有优势。

1.5 .怎样访问数据库，是选择jdbc的方式还是使用持久层框架。

对于大数据量的系统，建议采用jdbc方式。原因是采用hibernate等持久层框架会提高开发效率，但性能方面没有保证。毕竟我们选择框架时是需要根据的，这个关键点上要重点考虑系统负载加大后，如何较好地进行系统的性能优化，而不能只考虑是否有利于提高开发效率。

2.数据层架构设计

2.1 cache软件选择

目前在用户量数据量较大的系统中，通常在数据库软件之上会添加一层cache来提供数据访问的支撑能力。

互联网软件中用户访问压力较大，数据量也很大，仅仅通过DB无法满足系统吞吐量的要求，惯常的做法是将数据首先存储到cache软件中，然后异步存储到DB中。cache提供高效地实时数据访问能力，DB提供数据的持久化能力。目前常用的cache软件包括redis和memched等，都比较成熟可用。

2.2 选择数据存储软件

选择数据库存储还是nosql，需要进行分析和判断。目前，常用的方式是两种合理的组合。

较核心和关键的数据一般对数据的一致性和完整性要求较高，通常选择关系型数据库来存储。

日志等非关系型数据一般选择nosql软件，mangodb等是通常的选择。