为什么一家传统券商选择将交易系统容器化？(2)

金融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).
• 组件、模块、代码库、操作系统、应用程序、运维工具各版本之间具有各种线性、非线性依赖关系,形成一个巨大的复杂系统.

然而,以下这些变化是任何IT系统所不喜欢却无法回避的,例如：

• 多层架构里,任何一个环节的约定独立发生细微改变,必定导致系统出错(只是严重性大小的差别),这几乎无法很好的避免 – 研发团队的素质不够高、软件工程的水平低、瞬息万变的市场导致的频繁更改等,总是客观存在.
• 因为安全原因,需要对操作系统进行打补丁或者升级,导致应用程序所依赖的代码库发生兼容性问题 – 在打补丁或升级后通过测试及时发现兼容问题已经算是幸运的,最怕是在生产环境运行过程中才触发非线性关系的模块中的隐患.
• 跨系统(尤其是不同团队、部门、组织负责的系统)的调用协议与接口发生变化,是一个常态性的客观事实.
• 互联网环境、甚至企业内部的网络环境,并不是一成不变的,网络拓扑出于安全、合规隔离、性能优化而变化,可能导致延迟、吞吐等性能指标的变化,应用系统本来没有出现的一些问题,有可能因为运行环境的变化而浮现,而系统内部容错机制往往没有考虑到这些问题.
• 业务需求永远在变,以数据库为中心的系统,不可避免产生表结构(schema)调整,系统升级需要做数据迁移,而这总是有风险的(例如data integrity需要保证万无一失).

（编辑：ASP站长网）