按照一般的处理逻辑来说,一般会分为报文分发和报文处理2个部分.
通常的系统设计一般为:
报文的乱序主要体现在当我业务系统向外发送一个报文以后,有可能会收到多个报文,而这种多个报文需要按照一定的顺序来进行处理.在微服务的体系下,有专门的服务在对接报文系统的时候,报文系统需要对外部乱序的报文做顺序处理.
以银行票据系统为例,票据系统给票交所发送031报文,票交所会同时返回033和034报文.这2种报文需要在票据系统中按照顺序进行处理.还有类似的同行内的兑换报价,成交清算报文等等.
而到目前为止,对于这种报文乱序的处理都是通过业务状态来进行判断实现的.
直到目前为止,还有很多同学对"微服务架构"和"中台架构"存在很多疑问,写此文以做探讨
因为专业缘故,本文举例使用以银行系统为例
上古时代(大约2000年以前),没有系统架构的说法,因为系统都很简单,核心系统承担主要功能.所有的功能都在核心系统完成,包含柜面,存款,计息,信贷,计提等等.为了运行那么大且复杂的程序,所以一般需要机器性能非常高,小型机甚至中型机是常见选择.在那个时代,国外无论是HP还是18M,都是风头无量的.
到了2005年左右,18M中有一个聪明的脑袋,想出来SOA架构,是通过soap协议,在公司内部形成ESB(企业服务总线),将原有复杂的应用进行拆分.形成了下面的图.
又有系统爆出安全性问题了....正好,找了个契机,说说前后端分离和系统安全的话题.
简单总结一下常见的前后端分离模式的开发和部署情况.
在常见的内管系统里面,其实是没有太多问题的,一般安全问题也考虑的比较少.但是,问题就是后面的但是.
有时候猿粪到了,这边说说分布式任务调度的事.
先说说分布式任务调用系统的重要性吧.分布式任务调度,在企业中都是处于核心位置,而且处理的任务一般为一些应用系统的上游,比如大型金融系统的跑P,应用数据的ETL过程.
而目前开源领域对于分布式任务系统,各种五花八门,杂乱纷呈.
在某些应用内,框架的作用其实并不大,某些情况还不如我写的qilu-task来的灵活实在.我也曾经见过某大行的分布式任务,集成各种中间件,最后做了个寂寞.
那如果我们要定制一个分布式任务调度系统,应该如何来实现呢?
除了监控界面以外,还有哪些东西需要考虑的呢??
有时候,猿粪到了,啥都可以说说.
一般IT建设的流程内,测试是非常关键和重要的一环,传说中,测试就是最后的守门员,重要性可想而知.
所以,现代的软件研发,不再把宝压在最后的测试阶段,而是准备建立完善的测试体系,让问题在最终上线前,大面积的暴露,在上线前达到稳定.
基于上述理念,在软件的研发流程里面,和质量相关的测试环节主要包含,单元测试,功能测试,非功能测试三种情况.
执行单元测试的角色一般是开发.让开发做测试,一般来说开发是不愿意的.
提示
开发的职责是创造,需要把没有的东西创造出来.所以,从性格上来看,开发一般比较奔放,思维跳跃性较高,但是缺乏稳重,对重复的事情很容易感到厌烦.
在过去的几年,金融科技被大范围传播,风头无量.也有大型银行放出话来,要成为数据公司和科技公司.在数据和科技的背景下又加上过去大数据,AI各种牛逼的名词加持下,风控系统成为这些领域的突破点.
去年的这个时候,黄浦江畔的"老年人俱乐部","当铺思想",曾经的教主跌落神坛,成为互联网上嘲讽的对象.其实我一直觉得,阿里的公关方向是存在严重问题的.其实背后的思维逻辑很简单,因为阿里有非常强大的风控体系和能力,那是不是可以创新一点,放松点监管,而舆论的导向却变成对监管的不尊重,不要监管.
提示
说说2%的资本充足率
试想一下,蚂蚁2%的资本充足率,在当前的金融体系里面,还有哪个同学敢这么做??2020年建设银行年报,被认定的不良贷款总额2607.29亿,贷款总额161910.67亿,简单估算坏账率为1.61%,如果算上没有被认定的不良贷款,再加上只有2%的资本充足率,建行是要倒闭的.(这边只是举个例子,真实的坏账率计算是很复杂的)
技术方案的首要前提是,能不能落地?有不能纯粹的考虑技术方案能不能落地,就会陷入技术人员用自己熟悉的技术的局限内.
技术方案还需要使用场景,使用场景不一定要是对现有系统全方位的改造,可以是针对当前的方案的改造.
技术方案的创新不一定要体现推翻原有系统.任何的推翻意味着对前面的否定,推翻的越多,阻力也就越大,况且,是否真正明白当时方案的选择和妥协???
从A->B中间加个C,变成A->C->B是一种创新,从A->C->B,中间去掉一个C也是一种创新.
针对微服务的架构来说,方案都能说清楚,但是面临的系统在业务中的解释是不一样的.
