网上银行 Web开发架构设计

最近太忙了,参与了某银行集团的网上银行架构改造。

抽时间自己整理了一下思路。记录下来以便学习交流,和总结经验。

网上银行针对的客户端有PC端(browser)和智能手机端(mobile)。

系统解决大体思路如下:

  1. Browser和Mobile过来的请求通过DNS(IIJ)作负载均衡到A center和B center.
  2. A center和B center分配到的request,通过设置一个presentation层配置的NDP(Big-IP),分配到2个Web 服务器系统。
  3. Web服务器上分配到的request, 经由Application Server送到各个共通业务Server.
  4. 共通业务Server上接收到的request, 被在同Server上配置的 Java application系统取得。

    Java Application系统,根据request的种类,进行处理。

    处理被实行的时候,根据request的种类,迁移到DB Server, MDp, MainHub等周边系统,发出业务要求进行处理。

  5. Java Application 系统,把从各个系统过来的处理结果取得,返回给Application Server.
  6. Application Server上,把发出去request后返回的应答结果,把画面构筑好,通过Web Service~DNS,向Browser和Mobile终端发出应答。
  7. A center或者B center由于灾害或者障害发生的时候,

    根据DNS的广域负荷分散系统,把通向障害系(非在线)center的分配停掉。

    在线center继续使用,service继续提供服务。

    并且,如果在各个center内的某特定server进行维护或发生障害,可以根据各层配置好的NDP(Big-IP),把非在线的server停掉,继续使用在线的server

以上是一些粗线条的总结。备忘,继续学习。

时间: 2024-11-13 11:03:51

网上银行 Web开发架构设计的相关文章

web开发架构设计

2015-07-31 13:10:38 一, web服务器 .负载均衡 .不做对URL的rewrite逻辑判断, 全部转发到代码服务器的单一入口文件, 由代码去全权处理 二, 代码服务器 .单一入口, 在入口处准备好基本数据(userinfo, 数据库配置, 缓存配置, 云服务配置, 当前URL, 请求参数(模块名, controller, action, view...), 登录URL, 退出URL...全局变量 ), 不再后续重复去查询 .服务化/微服务, 用户/会员管理系统, 支付系统,

关于Django Web应用架构设计开发的几个问题

1.关于分层,做过传统JEE应用的同学肯定知道JEE应用会分很多个设计层.根据传统Web应用架构设计一般从上到下分这么几个层(太懒了,不画图了):Web前端层.Web后端交互层.业务层.基础数据设施层,Web前端层在浏览器里面由JavaScript来做,暂时不表,数据设施层,Django的数据操作接近Active Record模式,相当完善,基本不用再做封装加工,重点谈谈交互层和业务层,交互层主要接受请求数据,调用业务逻辑完成用户交互. 2.关于业务层的独立存在问题,Django中业务层独立有没

Web网站架构设计考虑的因素

转自http://blog.csdn.net/moshengtan/article/details/8990052 1    Web负载均衡 1.1 - 使用商业硬件实现 最常用的F5 与citrix netscaler.比如12306前端的web好像用的就是F5 的BIGIP.如果公司资金足够的话,相对使用开源软件来说理方便. 优点:维护方便,性能稳定 缺点:费用太高 1.2 - 使用开源软件 可选择使用lvs或者nginx做web应用的负载均衡. Lvs工作在tcp 协议4层下,而nginx

[转]全 Javascript 的 Web 开发架构:MEAN

引言 最近在Angular社区的原型开发者间,一种全Javascript的开发架构MEAN正突然流行起来.其首字母分别代表的是:(M)ongoDB——NoSQL的文档数据库,使用JSON风格来存储数据,甚至也是使用JS来进行sql查询:(E)xpress——基于Node的Web开发框架:(A)agular——JS的前端开发框架,提供了声明式的双向数据绑定:(N)ode——基于V8的运行时环境(JS语言开发),可以构建快速响应.可扩展的网络应用. MEAN的支持者宣称,如果整个开发栈均能使用JS,

基于asp.net的Web开发架构探索

问题由来 最近在研究适合团队开发的web架构解决方案,该架构即要适合分工协作又要有一定扩展性,适合不同的数据库需要,因此我查阅了一些资料,初步构想出了一套架构,请各位多多指教. 探索 web开发架构最经典莫过于三层架构,表示层.逻辑层.数据处理层. 数据访问层:其功能主要是负责数据库的访问. 业务逻辑层:是整个系统的核心,它与这个系统的业务(领域)有关. 表示层:是系统的UI部分,负责使用者与整个系统的交互.理想的状态是表示层不应包括系统的业务逻辑. 这些是经典的解释,如果要适合不同的数据库则需

Web开发与设计之Google兵器谱-Web开发与设计利器

Web开发与设计之Google兵器谱-Web开发与设计利器 博客分类: Java综合 WebGoogleAjaxChromeGWT 笔者是个Java爱好者也是用Java进行web开发的工作者.平时笔者最喜欢的浏览器就是Firefox,因为它能带个笔者很多IE所不具备的优秀调试功能,说心里话笔者一直觉得MS貌似很不重视浏览器.无论功能还是性能,IE在笔者心里基本都是垃圾...今天偶然看到一篇介绍利用Google提供的免费用具进行Web开发与设计的文章,十分经典摘过来和大家分享下: Google 的

【转】全Javascript的Web开发架构:MEAN和Yeoman【译】

引言 最近在Angular社区的原型开发者间,一种全Javascript的开发架构MEAN正突然流行起来.其首字母分别代表的是:(M)ongoDB——noSQL的文档数据库,使用JSON风格来存储数据,甚至也是使用JS来进行sql查询:(E)xpress——基于Node的Web开发框架:(A)agular——JS的前端开发框架,提供了声明式的双向数据绑定:(N)ode——基于V8的运行时环境(JS语言开发),可以构建快速响应.可扩展的网络应用. MEAN的支持者宣称,如果整个开发栈均能使用JS,

架构设计:前后端分离之Web前端架构设计

在前面的文章里我谈到了前后端分离的一些看法,这个看法是从宏观的角度来思考的,没有具体的落地实现,今天我将延续上篇文章的主题,从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案,该方案和我原来设想有了很大的变化,但是核心思想没变,就是控制层是属于Web前端的. 在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分,原方案的构想在实际的生产开发里很难做到,我觉得核心还是控制层和视图层的技术异构性,这样后果使得系统改造牵涉面太大,导致在项目团队里,沟通.协调以及管理成本相对较高,

web系统架构设计中需要知道的点(前端篇)

上周没写东西,这周写点互联网系统开发中需要了解的技术点,每个点都可以发散出去,连接更多的知识点,打算做个逐步细化的记录. 一个应用的整个生命周期中(生,老,病,死)都需要有一个整体规划. 前期 评估需求,根据需求提炼出其中隐含的非功能性要求,做为容量评估的参考.一般就是大致估算一下,技术发展到现在,如果是聊天或游戏应用,随便一个服务器单机能能维持100W-160W左右的tcp长连接并进行通讯.所以普通的创业起步阶段的应用一般不必太担心设计问题,可以等业务量慢慢上来慢慢调整系统架构. 互联网上许多