一、现有架构的问题对于大型应用系统项目而言, 在安全性保障方面, 提出了较高要求, 在灵活可扩展性方面, 提出了较高要求, 在服务组件可管理可重用这方面, 也提出了较高要求, 然而现有应用系统架构却还无法满足这些需求, 有待进行提升完善, 先去分析一下系统架构现状, 物理架构呈现出如下图所示的情况, 逻辑架构同样呈现出如下图所示的情况:由上图我们可看出这种架构主要有以下问题1、Web服务器安全性问题现有应用系统的后台服务程序, 被安装部署在了一台Web应用服务器上, 这台Web应用服务器处于DMZ区。MVC的//DAO三层, 都在一个War包中, 进而通过JDBC接口去访问内网里的数据库服务器。一旦这台Web应用服务器, 被黑客攻击并且获取了系统权限, 那么就很容易经由SQL/JBDC接口侵入内网数据库, 窃取关键数据资料, 或者篡改关键数据资料, 甚至销毁关键数据资料。因此, 出于安全性方面的关联考量, 要把接入层以及交互层, 还有应用服务包含DAO层, 从物理架构层面着手予以分隔, 借助分区部署的方式, 以此来确保数据库系统的安全性能得以存续。2、紧耦合性问题当下的架构形式虽说于开发范畴已然存在分层情况, 于当下也依照MVC的样式予以架构然而于应用服务组件化这一方面、于Web松耦合性这一方面缺失架构设计, 给团队分工开展开发工作、针对局部功能模块实施优化升级、进行分布式部署造成了些许有着制约性质的问题。3、应用服务扩展性问题需在现有的架构基础之上开展应用服务的扩展工作, 从界面一直至DAO层均需存在改动, 各层之间都有相互的牵制影响。所以, 要依据SOA松耦合架构的设计思想, 把应用服务包含DAO层分离出来达成服务组件化, 借助服务注册/发现机制以及服务总线ESB进行协调, 达成动态服务扩展、灵活组合调用。二、架构改进设计方案1、合理分层设计现有的架构设计之中已存在清晰的分层设计, 只是其在部署以及代码组织结构方面耦合得较为紧密, 我们乃在这两个方面予以封装而后进行解耦合, 在物理部署层面, 把接入/交互层以及应用服务含DAO层予以拆分, 如下列图示那样:为了使系统安全性得以增强, 以及接入服务性能能够提升 , 故而引入接入/交互服务器 , 在该服务器上需专门用于部署和UI相关的应用即War包 , 这些应用涵盖HTML/CSS/JS , 还有具备安全策略功能也就是防SQL注入、防篡改的。在对代码结构予以调整之后, 接入服务器以及交互服务器存在着多种调优方式, 举例来说, 可以增添页面静态化处理以此提升性能, 还能增加缓存机制, 进而提高用户体验。在配置方面相较于之前更加安全且更为轻量, 涉及数据库访问方面的配置均被放置在内网的应用服务器之上。现在的系统, 按照下面图示的方式, 重新开展组织构建工作, 就能够达成接入/交互层、应用服务层的物理分离, 以及分服务器进行部署服务请求的一方, 统一凭借HTTP/JSON接口, 去调用Web服务。建议采用Maven多模块主子架构形式来构建WAR, JAR, JAR(DAO)。远程调用实例参考如下其中和 分别布署在不同的服务器上。需要注意的是, 这样的一种方式, 适用于当下已存在的、基于框架构建起来的应用系统要是属于是异构系统的话, 那么在此建议使用SOAP协议实现方式来发布服务。2、安全机制设计Web服务欲实现认证、授权、身份管理等安全需求, 我们能够借助WSDL以及SOAP的Web安全规范予以指导。为保证服务的安全性设计考虑对客户端做身份认证l对敏感的数据做加密并且防止篡改l身份认证之后的授权。对客户端做身份认证有几种常见的做法1在请求中加签名参数对每个接入方分配一个密钥, 同时规定一种计算签名的方法, 要求接入方在请求里必须加上签名参数。在实际的相关项目当中, 一般而言, 是去设计那种动态加密的种子数量, 以此来生成动态的密钥。这样做的作用, 是能够让每一次的URL访问都具备安全签名。如此一来, 就能很好地防止出现这样一种情况, 即一个URL的信息, 在不同的浏览器当中是可以被使用的。2对敏感的数据做加密并且防止篡改做法如下把SSL基础设施也就是HTTPS进行部署, 敏感数据的传输全都依据SSL, 只是针对部分敏感数据实施加密, 像用户编号加上密码这种, 还添加某种随机数当作加密钥用来防止数据被篡改。经过身份认证之后的授权行为, 主导控制的主要是应用程序。一般而言应当实施确立某种基于角色以及用户组的授权运营机制, 能够启用采用Shiro框架达成实现授权, 也能够通过自行定义方式来达成实现相关功能。三、基于SOA架构的服务发布注册/查找机制以SOA架构设计理念为依据, 达成应用服务组件化, 进而实现服务组件的最大化重用目标, 为此, 就得构想并设计一套具备服务发布/注册功效、服务查找功效以及服务监控功效等的服务管理平台功能。下图描述了服务发布及注册、服务查找及服务调用的过程:在这个架构里头存在三种类型的角色哦, 它们分别是, 为服务提供的那一方, 用于服务注册的中心, 以及去消费服务的那一方句号。1、服务提供者身为服务提供方的服务提供者, 会把自身的服务信息登记到服务注册中心, 服务信息涵盖:l隶属于哪个系统l服务的IP端口l服务的请求URLl服务的权重等2、服务注册中心服务注册中心是主要用来提供所有服务注册信息进行中心存储的地方, 并且它还负责把服务注册信息更新通知以实时的方式Push给服务消费者, 这主要是借助特定机制来达成的。3、服务消费者服务消费者主要职责如下1、服务的消费者们, 当启动之时, 会去从服务注册中心那里, 将所必不可少的服务注册信息给获取过来。2、将服务注册信息缓存在本地3、针对监听服务注册信息的变动情况, 要是接收到了来自服务注册中心所发出的服务变更通知, 那么便在本地进行缓存。存中更新服务的注册信息4、依据本地缓存里头的服务注册消息, 去构建服务调用的请求, 并且按照负载均衡的策略, 像是随机负载均衡、策略负载均衡之类的, 来对请求进行转发。5、针对服务提供方是不是存活, 展开检测, 要是存在服务不可用的那种服务提供方, 就会把它从本地缓存里给剔除掉。当服务消费者处于自身初始化以及服务变更的阶段时, 才会对服务注册中心设有依赖, 于该阶段里的单点故障借助集群予以保障, 在整个服务调用的进程当中, 服务消费者不对任何第三方服务存在依赖。四、总结这段话从提升系统安全性, 以及达成应用服务组件化的视角着手给出了应用系统多层架构设计方案, 还有实践方法, 并且针对Web服务安全、服务发布注册/查找机制给出了实现方法建议, 可供产品设计开发人员以及项目实施人员参考。