架构设计一些思路

 

架构设计

 

 

服务设计的一些思想：之前是一个一个项目一个服务后面是把这些服务中共有的部分抽成基础服务。有调用关系的服务、有公用服务的服务都都放在一起（基础服务层），形成调用的上下游

 

 

 

请求返回对象的设计：各大请求都是调用向上银行的一个接口，后续步骤根据接口参数的url具体调用不同的接口（服务端），统一格式返回-----这种接口设计思路非常好，参数、返回数据的实体设计也很好

 

架构组织：springcloud 风格

纵向---接入层，服务层jar（公共服务层），数据库层（每一层都有controller,service）

 

横向---页面交互层war，服务层（纵向），前置隔离层war， 定时任务war

               服务层通过(war)其接入层gateway分发到各子系统，每个子系统一个单独jar(controller，service,dao---springcloud的设计这三个在一个子系统中，dubbo则是seveice是一个jar(用dubbo时的服务层)，controller（用dubbo时的接入层）是一个war)

 

gateWay   是专门用来路由分发到内部各子系统(geteway中：SanxiangLoanApplyServiceImpl  在geteway的依赖项目中， TaskLoanApplyController（投保申请） （geteway） 由定时任务task项目读表配置ioc获取对应的bean，  业务定时配置)，不同的service  bean导向调用不同的子系统(达到分流)，同一内部系统直接gateway调，不需要api

 

 hb_api    的非军事化是靠设置服务器的网络策略实现的,api都是gateway对外，外对gateway的路口，军事化区也以此为界（SanxiangExchange   就在api项目中，项目中callback controller 调用  有ioc获取对应的bean 不通业务模块不同的exchange  api  ---对接不同的银行银行（达到分流））(没有和数据库交互  都是转发进来，出去的请求（非军事化区的中专项目）)

task     的用处 放在redis中，数据库中排队，然后用定时任务一个一个去消费---辅助用状态  ---qps大

 

===============这种架构适合高并发设计

 调整之后：

 

 

 

 

 

 

支付等银行对接系统的设计：

 

业务子系统

 

 

业务子系统对所有银行有关请求入口系统   组装数据，调用资金网关   有自己的数据库 

 

 

 接受入口系统请求和银行交互的前置系统   校验数据  调用银行----相当于前置机（外界只能接触到业务子系统，请求入口系统,不能直接对资金网关发起攻击）  有自己的数据库

 

 

参数的包装

1，建立一个实体，里面有一些外围属性（例如区分业务类型，订单号，用户等后面待传参数的归属标志），

2，这实体中专门有一个字段放置参数的字符串例如json

 

工具类的包装：

        通过用工具类包装，传入参数不同请求不同----引入设计模式