概要设计背景:
1.由于我们的上游C系统的解耦重构一系列优化, 使得我们B系统也要进行配合优化。
2.C 系统 采用的是EGL,COBOL 等语言编写,数据库使用DB2。本次C系统将部分功能逻辑使用Java语言及相关框架过渡开发。
3. B系统 采用JavaWeb模式,2020年做过Maven 重构,B系统较为庞大,其子系统包括(从B系统衍生出来的系统,非JavaWeb 系统 ),Kafka节点子系统,ATM节点子系统,移动端节点子系统等。
4.本次我方涉及配合改造内容是消息队列节点。
原消息队列模式:
C系统将消息推送至IP网关(老模式2001款),我方B系统主项目启动后会有个专门监听IP网关的一个功能,当C系统推送消息到IP网关后,我方可实时监听到消息,并对消息进行处理。
新消息队列模式:
C系统在Java Spring 平台生产消息,将消息存入到一张数据表中(Mysql 表),C 系统的Kafka节点会监听该表的变化,当有数据插入或者更新,Kafka 的消息生产者就会将消息推送至 Kafka 消费者群主。我们B系统只需要在我方的Kafka消费者节点配置上Topic等相关信息可以获得消息推送
详细设计分析:
源消息格式:
100000000000@@00000000000 E111F-SGA 999999 00200009980105431
第一步: 我们先假定C系统消息是这样的,该消息的获取方式为,先做一笔旧就交易获取。
第二步: 分析我们B系统原程序处理流程,及其分支的多种情况,这些情况需要列举在概要设计中,并告知C方。
第三步: 分支我方系统的kafka 消息接收方式。当了解了我方的kafka消息接收方式后,分析如何与我方系统进行消息的传递(注:由于系统原因,我方B系统 Java Web 项目未接入Dobbo 方式,但2016年我方对B系统进行增幅,建立了一个子系统(B-Service),该系统可以与B系统进行Http,XML的方式进行消息传输)。
第四步:B-Service 作为 B系统的对外代理系统,起到了承上启下的作用。
问题1:为什么不直接在B系统直接接到Dobbo服务?
答:B系统过于老旧,系统内容庞大,相关功能追溯至九几年,不易于较大改动。
问题2:为什么不直接用Kafka 消费者节点与B系统直接进行Http,XML形式的信息交互。
答:安全起见,B系统设计到很多账务信息,所以建议在外部设置一个代理系统。
第五步:最终定稿,将流程图绘制出来。
第六步:撰写概要设计,将思路与上层架构师进行描述,方案评审。与需求提出者进行交谈,然后最终定稿,实现。
心得:
1.态度:
对一个需求而言,设计者要从需求提出者的角度思考问题,同时设计者要从开发人员的角度考虑问题。思路一定要清晰,明确自己下一步要做什么,以及设计进度的把握。
2.沟通(communication):
要善于沟通,无论与上游C系统负责人,还是与B系统的开发人员,都要进行沟通。拿出敏而好学,不耻下问的精神。语气平和,勿急躁。一旦遇到自己解决不了,或者困惑的事情及时与自己的上层领导进行沟通。
面对面沟通 > 电话沟通 > 办公通讯软件沟通
注: > 为 大于号
本次是我第一次写概要设计
欢迎关注kaki 的码云,以及B站 KakiNakajima