大家好，今天小编来为大家解答交易平台系统架构图怎么做这个问题，信贷系统架构图很多人还不知道，现在让我们一起来看看吧！

本文目录

1. php开发中app怎么接入支付宝
2. 信贷系统架构图
3. B/S 构架系统的实现

一、php开发中app怎么接入支付宝

APP支付接口：alipay.trade.app.pay

登录蚂蚁金服开放平台-->创建应用-->添加App支付功能。具体查看官方文档

下载官方 SDK(PHP版本资源)——当前SDK版本:106生成时间:2017-07-25 11:46:10

将SDK原码放置在TP5的vendor目录下的alipay文件夹(可根据实际使用框架技术进行实际调整)。

应用公钥(商户自身的RSA公钥)：支付宝使用该公钥验证该交易是商户发起。

支付宝公钥(支付宝的RSA公钥)：商户使用该公钥验证该结果是支付宝返回的。

4、支付场景具体实现流程(最详细图解)

在集成App支付能力时，建议实现如下支付流程，创建订单并支付，根据返回的结果确定支付状态，并进行相应的异常处理，其过程如下图所示.

商家APP在创建订单并且唤起支付宝APP支付，流程如上图所示，根据第2.2，3步返回的支付结果，确定支付状态，并且做相应的异常处理(必要时关闭订单)

步骤1：商户APP端请求商户服务器接口，提交订单数据。

步骤2：商户服务器端接收数据，然后对数据进行签名，返回请求参数到商户APP端。

官方接口文档：

//vendor();为TP5框架的方法，作用：导入第三方框架类库

vendor('alipay.aop.AopClient');

vendor('alipay.aop.request.AlipayTradeAppPayRequest');

$aop->gatewayUrl="";//支付宝网关

$aop->appId=“应用ID,填写你的APPID”;

$aop->rsaPrivateKey="商户私钥，您的原始格式RSA私钥()";

$aop->alipayrsaPublicKey="支付宝公钥";

$aop->apiVersion='1.0';

$aop->signType="签名方式，如 RSA2";

$aop->postCharset='UTF-8';

//实例化具体API对应的request类,类名称和接口名称对应,当前调用接口名称：alipay.trade.app.pay

$appRequest= new\AlipayTradeAppPayRequest();

//SDK已经封装掉了公共参数，这里只需要传入业务参数

'body'=>'余额充值',//订单描述

'subject'=>'充值',//订单标题

'timeout_express'=>'30m',

'out_trade_no'=>‘20170125test01’,//商户网站唯一订单号

'total_amount'=>'0.01',//订单总金额

'product_code'=>'QUICK_MSECURITY_PAY',//固定值

$appRequest->setNotifyUrl($url);//设置异步通知地址

$appRequest->setBizContent($bizcontent);

//这里和普通的接口调用不同，使用的是sdkExecute

$response=$aop->sdkExecute($appRequest);

//htmlspecialchars是为了输出到页面时防止被浏览器将关键参数html转义，实际打印到日志以及http传输不会有这个问题

echo htmlspecialchars($response);//就是orderString可以直接给客户端请求，无需再做处理。

//如果最后有问题可以尝试把htmlspecialchars方法去掉，直接返回$response

说明：sdkExecute()方法，作用生成签名，详细步骤如下：

将请求参数组装分下列3步，以最后第三步获取到的请求为准。

1)将请求参数的键按字典排序，然后按照key=value&key=value方式拼接，得到未签名原始字符串如下：

app_id=2015052600090779&biz_content={"timeout_express":"30m","product_code":"QUICK_MSECURITY_PAY","total_amount":"0.01","subject":"1","body":"我是测试数据","out_trade_no":"IQJZSRC1YMQB5HU"}&charset=utf-8&format=json&method=alipay.trade.app.pay¬ify_url=×tamp=2016-08-25 20:26:31&version=1.0

app_id=2015052600090779&biz_content={"timeout_express":"30m","product_code":"QUICK_MSECURITY_PAY","total_amount":"0.01","subject":"1","body":"我是测试数据","out_trade_no":"IQJZSRC1YMQB5HU"}&charset=utf-8&format=json&method=alipay.trade.app.pay¬ify_url=×tamp=2016-08-25 20:26:31&version=1.0&sign=cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj+y48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp/M45w1ZsDOiduBbduGfRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ77Lo5J0PpUUWwyQGt0M4cj8g=

3)最后对请求字符串的所有一级value(biz_content作为一个value)进行encode，编码格式按请求串中的charset为准，没传charset按UTF-8处理，获得最终的请求字符串：

app_id=2015052600090779&biz_content=%7B%22timeout_express%22%3A%2230m%22%2C%22product_code%22%3A%22QUICK_MSECURITY_PAY%22%2C%22total_amount%22%3A%220.01%22%2C%22subject%22%3A%221%22%2C%22body%22%3A%22%E6%88%91%E6%98%AF%E6%B5%8B%E8%AF%95%E6%95%B0%E6%8D%AE%22%2C%22out_trade_no%22%3A%22IQJZSRC1YMQB5HU%22%7D&charset=utf-8&format=json&method=alipay.trade.app.pay¬ify_url=http%3A%2F%2Fdomain.merchant.com%2Fpayment_notify&sign_type=RSA2×tamp=2016-08-25%2020%3A26%3A31&version=1.0&sign=cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj%2By48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp%2FM45w1ZsDOiduBbduGfRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ77Lo5J0PpUUWwyQGt0M4cj8g%3D

步骤3：商户APP接收从商户服务器端返回的请求参数，然后调起支付宝支付面板。

若用户支付成功，支付宝会同步给商户APP端返回一个支付结果。相应地，支付宝也会通过异步通知给商户服务器端返回一个支付结果。

注意：由于同步通知和异步通知都可以作为支付完成的凭证，且异步通知支付宝一定会确保发送给商户服务端。为了简化集成流程，商户可以将同步结果仅仅作为一个支付结束的通知(忽略执行校验)，实际支付是否成功，完全依赖服务端异步通知。

步骤4：服务端异步通知处理机制(支付宝主动发起通知，该方式才会被启用)

官方接口文档：

1)必须保证服务器异步通知页面(notify_url)上无任何字符，如空格、HTML标签、开发系统自带抛出的异常提示信息等;

2)支付宝是用POST方式发送通知信息，因此该页面中获取参数的方式，如：$_POST[‘out_trade_no’];

3)程序执行完后必须打印输出“success”(不包含引号)。如果商户反馈给支付宝的字符不是success这7个字符，支付宝服务器会不断重发通知，直到超过24小时22分钟。一般情况下，25小时以内完成8次通知(通知的间隔频率一般是：4m,10m,10m,1h,2h,6h,15h);

4)当商户收到服务器异步通知并打印出success时，服务器异步通知参数notify_id才会失效。

$aop->alipayrsaPublicKey='请填写支付宝公钥，一行字符串';

$flag=$aop->rsaCheckV1($_POST, NULL,"RSA2");//验证签名

$out_trade_no=$_POST[‘out_trade_no'];//商户订单号

$trade_no=$_POST[‘trade_no'];//支付宝交易号

$trade_status=$_POST[‘trade_status'];//交易状态trade_status

$total_amount=$_POST[‘'total_amount'];//订单的实际金额

$app_id=$_POST[‘app_id'];

if($app_id!=$this->config['app_id']) exit('fail');//验证app_id是否为该商户本身

//只有交易通知状态为TRADE_SUCCESS或TRADE_FINISHED时，支付宝才会认定为买家付款成功。

if($trade_status!='TRADE_FINISHED'&&$trade_status!='TRADE_SUCCESS')

//1、商户需要验证该通知数据中的out_trade_no是否为商户系统中创建的订单号;

//2、判断total_amount是否确实为该订单的实际金额(即商户订单创建时的金额);

//3、校验通知中的seller_id(或者seller_email)是否为out_trade_no这笔单据的对应的操作方(有的时候，一个商户可能有多个seller_id/seller_email)。

//上述1、2、3有任何一个验证不通过，则表明本次通知是异常通知，务必忽略。在上述验证通过后商户必须根据支付宝不同类型的业务通知，正确的进行不同的业务处理，并且过滤重复的通知结果数据。

//校验成功后在response中返回success，校验失败返回failure

步骤5：当商户APP端接收到支付宝的同步返回结果为成功时，商户APP端再请求商户服务器端API，判断订单最终支付结果，并做出最终响应。

二、信贷系统架构图

架构是金融产品经理为数不多的审核抽象能力和业务熟悉度的能力，也是产品经理由点到面窥视顶层设计的必经之路。

有的同学可能会问，什么是架构图？官方的回答是清晰展示各种系统和功能模块，传递数据和信息，阐述产品设计思路的过程。

我理解的架构图是一种思维方式，是一种沟通工具。

产品经理通常只需要理解和绘制三张图，即业务架构图、系统(技术)架构图和产品架构图。

画业务架构图是为了了解业务部门目前在做什么，怎么做，未来要做什么。

产品设计的目标来自于对业务的支持程度。如果支持好，能引领业务发展，那就是好产品。如果我们明白他们想做什么，我们的设计就不会偏离。

如果什么都不懂，先看看竞品是怎么做出来的，不要直接说竞品有多高。先看你的业务阶段在哪里，文案也需要结合业务阶段。

比如竞品已经有1000亿的贷款余额，而如果你的贷款余额只有100亿，那么注定的配套产品就不一样了。当然，下面我会讲产品架构的演变。

上面的业务架构图简单描述了一家大昌消费金融公司(以下简称大昌)的业务模式，其中每一块内容都有一个独立的业务流程，比如资金运作，包括资金谈判、资金准入、资金头寸、资金roi计算等一系列流程。

大昌在产品上有自己的个人现金贷、个人消费带、小微企业贷、产业链金融、区块链金融。

在合作模式上，如果是自有资金借贷，就是自营模式，也区分了助贷和联贷。

运营上，大昌有资本接入和运营、资产接入和运营、风险管理和运营、客户运营、统计分析和新产品设计团队。

接下来，我们产品架构设计的原则是匹配大昌目前不同产品、合作模式、渠道的业务流程。

以上是大昌公司的简化技术架构图。在客户端，内部通道和外部通道是有区别的。不同的渠道有不同的接入方式。

根据产品的类型，信用体系可以分为若干个信用子系统，通常根据不同的产品建设不同的信用子系统。

比如，如果个人信贷和企业信贷是两个产品，由两个团队运营，系统是组织架构的体现，那么就要建立两个子系统，防止个人信贷团队和企业信贷团队打架。

在信用支持领域，抽象出各个信用子系统所需的公共能力。比如客户在产品A和产品B中的额度不能超过100万，那么额度就不应该放在系统A或者系统B中，要找一个单独的系统来管理，于是额度系统就应运而生了。

在基本支持领域，较低级别的支持系统是集中的。这些支持系统可能不仅支持信贷领域，还支持其他产品线，比如大昌理财线。

客户中心统一管理对公、对私客户的添加和修改，以及客户的文字和图片资料。

支付负责外部支付机构的接入、支付路由、各业务条线的资金扣款。

营销平台负责营销凭证的申请、发放和核销，以及各项营销活动的承办。

大数据平台负责规范数据标准、数据抽取、数据建模，为各产品线输出统一的数据呈现效果。

统一镜像负责客户镜像的统一存储、更新和下载。

电子签名系统负责电子签名的引入和电子签名的功能。

数据接入负责大数据的接入和计费管理。

会计系统负责首付款凭证的管理，财务生成

下一步是拆分具体信贷产品的产品功能。

以上简化了大厂个人征信系统的功能设计。由于统计分析交给了其他系统，个人征信系统主要负责信贷业务流程的串联、基础配置、运行监控、各种渠道的支持。

渠道管理负责接入各种合作渠道，产品管理负责配置不同的产品类型，资金管理负责管理资金人要素，授信申请负责管理授信订单，合同管理负责合同配置和查询；

额度管理负责查询额度，客户管理负责查询客户基本信息，提款申请负责更改额度，路由管理负责配置资产与资金的匹配关系，贷款管理负责查询借款单，还款管理负责查询还款单，对账管理负责清算结算。

利息减免负责异常客户的利息减免，线下还款负责发起线下还款流程和审批，代偿申请负责配置人工代偿申请和审批，核销管理负责坏账核销申请和审批；

财务管理负责财务公司接入，结算管理负责客户结算申请和结算凭证管理。空间有限，以后只能拆分各个子系统。

画这三张图的好处是，可以借此机会查漏补缺，提高产品规划能力，同时可以在日常工作中明确系统边界体系，避免不同系统之间的纠纷，降低沟通成本。

上图也是变化的，不是标准答案，因为业务总会变化，架构设计也遵循架构演进的路径。

第一阶段，大昌公司刚成立，信贷业务还为零的时候，实际上没有也不需要这么多的系统。这时，大厂建立了单一的信用体系。

第二阶段跟着大昌的业务发展，变成了个人信贷和企业信贷部门，于是大昌建立了个人信贷和企业网贷系统。

第三阶段，由于关联资产较多，大厂构建了新的资产接入系统。

第四阶段，大厂的业务线在增加。

第五阶段，大昌加强了营销和客户运营智能化阶段，当一个客户获客之后，即可通过业务流程中心给客户推荐什么业务。

这么看我们上面画的系统架构图目前属于大昌公司的第四阶段。

在做信贷产品规划的时候，我们需要提前2-3年的空间，甚至是提前为商业化做准备。

信贷产品指的是无需抵押和担保的信用贷款产品，目前主要有以下这些信贷产品：

1、银行信贷产品：各银行都推出了信贷产品，比如建行快贷、平安新一贷、招行闪电贷、浦发银点贷等等。

2、网络信贷产品：大部分网络贷款都属于信贷产品，比较知名的有借呗、花呗、金条、白条、微粒贷、网商贷等。

3、消费金融信贷产品：消费金融公司也推出了一些信贷产品，比如说招联消费金融好期贷、中银消费金融新易贷-微贷款、包银消费金融包你还和包你贷等。

相关问答：您都知道哪些企业信贷产品？

既然是信贷产品，那么往往指的是银行的授信产品，接下来我们按照客户的不同需求来简单说一下都有哪些银行信贷产品。

这种贷款是你我们最常见的贷款产品，特点是“简单粗暴”，贷款主要用于补充企业的生产经营所需资金，一般都是1年期的，也有两年的（中期流动资金贷款），不用分期偿还本金，到期一次性偿还本金即可，而利息是一般是按月付的（也有按季度付息的）。

像我们国家目前支持民营企业发展的资金一般都是流动资金贷款，就目前而言这种贷款利率往往不高，审批手续相对简单一些，只是相对简单一些。

PS：这种贷款需要受托支付，就是说贷款发放下来之后不是直接给借款企业的，而是按照借款企业与其上游企业签订的购销合同，银行将钱直接打给其上游企业，也就是说借款企业不经手的。

这类贷款从名称上就能理解，贷款资金就是用于固定资产的建设的，比如房地产的开发贷款、酒店、公寓等等的建设都是适用这种贷款的。

这种贷款相较上文说的流动资金贷款而言审批较为复杂，要根据固定资产项目的可研报告等材料经过合理的测算进行贷款，贷款的用途比较明确，就是用于项目的建设，不能用来干别的。

这种贷款往往设置宽限期，不是贷款之后马上就要求还款，而是等到项目打产了之后每年按照一定金额偿还本金。

这类贷款都是基于真正的贸易背景而产生的，有很多细分产品，所以放在一起说一下。

1、非融资性保函，保函又分很多种，有履约保函、质量保函、预付款保函、投标保函等等。我以其中一个为例您就明白保函是啥意思了，比如履约保函，甲乙两个企业做买卖，乙方给甲方供货，甲方验货没问题，按道理说应该付款给乙方了，但是甲方怕万一未来货物有问题怎么办，就要求乙方给开出一个保函，类似于保证的一个材料，规定如果未来货物有问题，就拿着这个保函找乙方要赔偿，当然了保函是有期限的，期限由双方约定。

乙方自己写的东西甲方不认，所以就需要以乙方合作的银行的名义开出一张保函来，甲方才认可，当然了银行也不是随意就开立的，需要乙方在银行有授信额度或者存银行一定的保证金，银行才能为其开立。

2、应收账款质押，这个比较简单，甲乙两个企业交易，结算方式是赊销，比如账期是6个月，乙方供货供货给甲方，但是要6个月后才能收到甲方的钱，但是乙方准备生产也需要资金，怎么办呢，就找到银行，将应收的账款质押给银行，银行借钱给乙方，这样乙方的资金缺口就解决了，未来一旦不还款，那银行就可以拿着应收账款的凭证找甲方要钱了。

3、信用证相关的信贷产品，信用证本身是一种结算方式，但也是因为开立信用证日期与实际付款日期有差距，所以卖货的一方为了补足流动资金缺口也可以拿着信用证来融资，俗称“押汇”，就是把信用证的受偿权卖给了银行，银行扣除一定的金额将资金发放下去的一个过程。

4、其他种类，贸易融资项下的信贷产品有很多，不同的银行的名称不一样，但背后的原理都是差不多的，都是基于真是的贸易背景为贸易双方解决资金问题的产品。

总结一下，普通贷款类主要分为流动资金贷款和固定资产贷款，而在贸易融资下还有很多产品包括保函、信用证、应收账款等等信贷产品，背后的逻辑都是一样的。

三、B/S 构架系统的实现

C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系

统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。

传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高，效率低。

B/S（Browser/Server）结构即浏览器和服务器结构。它是随着

Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端

（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。

以目前的技术看，局域网建立B/S结构的网络应

用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地

点，以不同的接入方式（比如LAN,WAN,Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服

务器数据库也很安全。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。

管理软件技术的主流技术与管理思想一样，也经历了三个发展时期。首先，界面技术从上世纪DOS字符界面到Windows图形界面（或图形用户界面GUI），直至Browser浏览器界面三个不同的发展时期。其次，今天所有电脑的

浏览器界面，不仅直观和易于使用，更主要的是基于浏览器平台的任何应用软件其风格都是一样的，使用人对操作培训的要求不高，而且软件可操作性强，易于识

别；再者，平台体系结构也从过去单用户发展到今天的文件/服务器（F/S）体系、客户机/服务器（C/S）体系和浏览器/服务器（B/S）体系。

C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国Borland公司

最早研发，B/S是美国微软公司研发。目前，这两项技术以被世界各国所掌握，国内公司以C/S和B/S技术开发出产品也很多。这两种技术都有自己一定的市

场份额和客户群，各家企业都说自己的管理软件架构技术功能强大、先进、方便，都能举出各自的客户群体，都有一大群文人墨客为自己摇旗呐喊，广告满天飞，可

（1）、应用服务器运行数据负荷较轻。

最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果，应用服务器运行数据负荷较轻。

（2）、数据的储存管理功能较为透明。

在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。

（3）、C/S架构的劣势是高昂的维护成本且投资大。

首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。

其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。

目前，软件系统的改进和升级越来越频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。

大家都知道windows在桌面电脑上几乎一统天下，浏览器成为了标准配置，但在服务器操作系统上windows并不是处于绝对的统治地位。现在的趋势是凡使用B/S架构的应用管理软件，只需安装在Linux服务器上即可，而且安全性高。所以服务器操作系统的选择是很多的，不管选用那种操作系统都可以让大部分人使用windows作为桌面操作系统电脑不受影响，这就使的最流行免费的Linux操作系统快速发展起来，Linux除了操作系统是免费的以外，连数据库也是免费的，这种选择非常盛行。

比如说很多人每天上“网易”（原文为新浪）网，只要安装了浏览器就可以了，并不需要了解“网易”的服务器用的是什么操作系统，而事实上大部分网站确实没有使用windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。

（3）、应用服务器运行数据负荷较重。

由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服务器就行了，用户界面主要事务逻辑在服务器（Server）端完全通过WWW浏览器实现，极少部分事务逻辑在前端（Browser）实现，所有的客户端只有浏览器，网络管理人员只需要做硬件维护。但是，应用服务器运行数据负荷较重，一旦发生服务器“崩溃”等问题，后果不堪设想。因此，许多单位都备有数据库存储服务器，以防万一。

Client/Server是建立在局域网的基础上的，Browser/Server是建立在广域网的基础上的。

（1）、硬件环境不同：C/S一般建立在专用的网络上，小范围里的网络环境，局域网之间再通过专门服务器提供连接和数据交换服务。

B/S建立在广域网之上的，不必是专门的网络硬件环境，例如电话上网，租用设备，信息自己管理，有比C/S更强的适应范围，一般只要有操作系统和浏览器就行。

C/S一般面向相对固定的用户群，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S结构适宜，可以通过B/S发布部分可公开信息。

B/S建立在广域网之上，对安全的控制能力相对弱，面向是不可知的用户群。

C/S程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑。

B/S对安全以及访问速度的多重的考虑，建立在需要更加优化的基础之上。比C/S有更高的要求，B/S结构的程序架构是发展的趋势，从MS的.Net系列的BizTalk2000Exchange2000等，全面支持网络的构件搭建的系统。SUN和IBM推的JavaBean构件技术等，使B/S更加成熟。

C/S程序可以不可避免的整体性考虑，构件的重用性不如在B/S要求下的构件的重用性好。

B/S对的多重结构，要求构件相对独立的功能。能够相对较好的重用。就如买来的餐桌可以再利用，而不是做在墙上的石头桌子。

系统维护是软件生存周期中，开销大，相当重要

C/S程序由于整体性，必须整体考察，处理出现的问题以及系统升级难，可能是再做一个全新的系统。

B/S构件组成方面构件个别的更换，实现系统的无缝升级。系统维护开销减到最小，用户从网上自己下载安装就可以实现升级。

C/S程序可以处理用户面固定，并且在相同区域，安全要求高的需求，与操作系统相关，应该都是相同的系统。

B/S建立在广域网上，面向不同的用户群，分散地域，这是C/S无法作到的，与操作系统平台关系最小。

C/S多是建立在Window平台上，表现方法有限，对程序员普遍要求较高。

B/S建立在浏览器上，有更加丰富和生动的表现方式与用户交流，并且大部分难度减低，降低开发成本。

C/S程序一般是典型的中央集权的机械式处理，交互性相对低。

B/S信息流向可变化，B－B、B－C、B－G等信息流向的变化，更象交易中心.

关于交易平台系统架构图怎么做，信贷系统架构图的介绍到此结束，希望对大家有所帮助。