加入收藏 | 设为首页 | 会员中心 | 我要投稿 网站开发网_盐城站长网 (https://www.0515zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长百科 > 正文

为什么一家传统券商选择将交易系统容器化?

发布时间:2021-01-08 02:32:24 所属栏目:站长百科 来源:网络整理
导读:副标题#e# 《为什么一家传统券商选择将交易系统容器化?》要点: 本文介绍了为什么一家传统券商选择将交易系统容器化?,希望对您有用。如果有疑问,可以联系我们。 交易系统是命根子,为什么这家传统券商选择将其全部容器化?本文根据梁启鸿在InfoQ举办的CNU

金融IT,正好生存在这么一个“极端斯坦”——这里复杂系统内部充满难以察觉的相互依赖关系和非线性关系,这里概率分布、统计学的“预测”往往不再生效.塔勒布称之为“第四象限”,我们,作为证券交易的IT,刚好在这个象限里谋生.

(塔勒布《黑天鹅》第四象限图)

上述这一切,和云计算有什么关系呢? 我们觉得非常紧密,逻辑如下:

  • 世界越来越数字化、更加“数目字可管理”- 一切效率更高.
  • 本来就数字化的金融世界,日益是个“极端斯坦”,只能更快、更复杂,面临更多黑天鹅事件.
  • 应对数字世界的黑天鹅,只能用数字世界的手段(而不是“人肉”手工方法),就像《黑客帝国》,你必须进入Matrix,用其中的武器和手段,去解决里面的问题(并影响外面).
  • 云计算,不过是世界数字化进程里的一步 – 把承载数字世界的物理载体也进一步数字化,但是它刚好是我们应对数字黑天鹅的基本工具 – 运算资源本身也是“数目字可管理”,并且正因为如此而可以是自动的和智能的.

即便到了今天,相信很多企业、机构的机房里的运算资源,依然不是“数目字可管理” – 这本身真是一个讽刺.但直到云技术出现,才解决这个问题.结合云计算的技术,交易系统不再是“your grandmother‘s trading system”.

“反脆弱”的技术系统

黑天鹅事件是不可预测的,但是并非不可应对.《黑天鹅》的作者塔勒布,在其另一本有巨大影响力的著作《反脆弱》(Anti-Fragile)里,提到了如何在不确定中获益.这本闪烁着智慧之光的著作,早已超越了金融而进入到政治、经济、宗教、社会学的思考范畴,对IT系统技术架构的设计,同样具有启发意义.

想想,一个经常被黑天鹅事件光顾的交易系统,如果不仅没有坍塌、还随着每一次的考验而技术上变的越来越周全和强壮,这对于任何开发工程师、运维工程师来说,是不是一个梦想成真?

实际上,这个过程对于任何IT工程师而言都是非常熟悉的,因为我们中很多人每天的工作,可能就是在不断的以各种应急手段紧急救援不堪重负的生产系统、或者在线弥补技术缺陷,在这过程中我们发现一个又一个在开发和测试时没有发现的问题、一次又一次推翻自己在开发时的各种假设、不断解决所遭遇到的此前完全没有想象过的场景.如果项目、系统活下来了,显然它变得更加健壮强韧.

只不过,这一切是被动的、低效的、“人肉”的,而且视系统架构和技术而定,变强韧有时是相对容易的、有时则是不可能的 – 正如一艘结构设计有严重缺陷的船,打更多的补丁也总会遇到更大的浪把它打沉.

如果基于《反脆弱》的三元论,也许大部分IT系统大致上可以这么看:

  • 脆弱类:绝大部分企业IT系统,依赖于大量技术假设与条件,不喜欢无序和不稳定环境,暴露于负面“黑天鹅”中.
  • 强韧类:小部分大规模分布式系统(也许通常是互联网应用),适应互联网相对不可控的环境(如网络延迟与稳定性、客户端设备水平和浏览器版本、用户量及并发请求变化),经受过海量用户与服务请求的磨练,相对健壮.
  • 反脆弱类:能捕捉到正面“黑天鹅”- 系统不仅在冲击中存活,并且变的更加强韧,甚至在这过程中获益.

这里所谓的“脆弱”,并不是指系统不可靠、单薄、技术不堪一击,而是指这类系统厌恶变化、厌恶不稳定不可控环境、本身架设在基于各种稳定性假设前提的精巧设计上,无法对抗突如其来的、此前无法循证的事件(黑天鹅),更无法从中自适应和壮大.就这个角度看,证券行业甚至整个金融业里,大部分的系统可能都是脆弱系统.传统IT系统有以下一些常见的技术特点,例如:

  • 一切以关系型数据库为中心(RDBMS-centric).
  • 很多历史遗留系统(legacy system)有数以百计的表、数以千计的存储过程.
  • 业务逻辑高度依赖数据库.
  • 中间层与数据层高度紧耦合.
  • 多层架构(multi-tiered architecture),层与层之间依赖于高度的约定假设(协议-protocol、接口- API、数据格式 – data format 等),并且这些约定经常来不及同步(例如某个团队改变了维护的接口而没有通知其他团队、或者数据库的表结构改变了但是中间层的对象库因为疏忽而没有及时步调一致的重构),有些约定甚至只存在于协作的开发者脑海中而没有形成文档(即便形成文档也经常因需求变化频繁而无法及时更新).
  • 应用程序依赖于某些第三方的代码库,而这些代码库很有可能依赖于某个版本的操作系统及补丁包,并且这种依赖关系是传递的 – 例如某个第三方代码库依赖于另一个第三方代码库而该库依赖于某个版本的操作系统……
  • 系统设计,往往没有考虑足够的失败场景(因此可能完全没有容错机制),没有考虑例如不稳定网络延迟对业务逻辑的影响(例如大部分企业系统都假设了一个稳定的LAN).
  • 组件、模块、代码库、操作系统、应用程序、运维工具各版本之间具有各种线性、非线性依赖关系,形成一个巨大的复杂系统.

(编辑:网站开发网_盐城站长网 )

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!