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

技术界不乏认为容器对软件技术产生革命性影响的观点,本人倾向于认同这种观点,因为：

• 容器影响开发者的开发方式、开发习惯,“强迫”他们去思考例如无状态的服务、业务逻辑粒度的控制、资源的弹性伸缩、应用代码的发布形态、系统里面每一个细节的可监控性等等.
• 让真正的DevOps成为可能 – 自动化测试、持续集成(CI)、持续交付(CD)、自动化部署、无人值守的运维… 开发与运维的角色差异进一步缩小,而效率则最大程度提升.
• 让“不可变基础设施”(Immutable infrastructure)成为可能——这将颠覆传统软件系统的升级发布和维护方式.

为什么作为金融系统、交易平台的研发者,我们挑容器出现的时候跳进云计算,而在更早阶段虚拟机系列相关技术成熟时却并没有大的投入.

最根本原因在于,作为研发组织,我们从研发视角,基于具体应用场景去持续、积极寻觅能解决强韧性、健壮性问题的解决方案 – 这是一种“Top-Down Thinking”,例如在交易量波动过程中,我们能否有自动化的技术去可靠的应对、实现计算资源的弹性伸缩并且保持超级高效?

有什么技术可以帮助我们解决复杂交易系统发布、升级、打补丁的危险和痛苦?交易故障出现时系统内部防止雪崩效应保持快速响应的“熔断”(circuit-breaker、fail-fast)机制有什么更规范的做法?用现有云计算的理论和技术倒着去套,显然是无解的,因为：

• 虚拟机级别的资源调度,太沉重,可编程接口太弱,无法“融入”到一个高性能运算(HPC – High Performance Computing)的应用中.
• 仅仅为了资源的弹性伸缩,去引入一个第三方解决方案,例如一个PaaS(诸如CloudFoundry、OpenShift等),对于交易系统而言,代价太大、可控性太低、编程模型受入侵程度太高.
• 不是为了云计算而云计算 – 一切“革新”需要合理、充分的应用理由,场景不符合,架构就不合理.

“Bottom-up Thinking”,即从基础设施的可管理、资源充分共享、运维更高效等角度去看问题,是一个典型的“运维”视角或者所谓CIO的视角,这种思考,关注的是TCO(Total Cost of Ownership)——成本的降低(IT在垂直行业一直被认为是一个成本中心 – 在现在这个时代这是一个错误观点,但这是另一篇文章的讨论范围了)；可是和核心业务应用非常脱节.

对于一个传统行业尤其是受监管行业的IT而言,技术氛围往往是保守和审慎的,采用云技术这种在互联网界以外还很大程度被认为是“新生事物”的东西,并不是一件容易的事情：在行业繁荣、企业赚钱的时候,公司很可能并不关注运维除了稳定以外的事情 – 包括用虚拟机还是用物理机、能否节省一点成本等等；

在市场不景气、公司亏钱的时候,IT却又需要以非常充分的数据来证明建立或者采用云平台能带来显著的大幅的成本节省效果,但是这往往首先涉及第三方软件的采购、机房的改造… 这本身就是一个巨大障碍.

所以,悲观一点的看,很大一部分传统行业IT,很可能需要等到云技术成熟为新世代IT系统的标配,就像mainframe时代向client-server时代转变、client-server时代向多层架构/web技术时代切换,云技术成为一个主流的、企业决策者不再需要加以思索的事物(“no-brainer”)时,才会顺利进入企业世界.此时,运维的视角也许才能被充分接受.但是,对于以创新为本业的金融科技,那已经太迟.

早期的云技术,从运维视角去看是自然的,因为虚拟化技术最开始是把基础设施数字化的一个进程.容器化技术的出现,改变了这一切.容器天然与应用服务结合的更紧密、天然需要程序员的深度介入,“上帝的归上帝,凯撒的归凯撒”,容器里面的归程序猿(code monkey),容器外面的归运维狗(watchdog)——不一定对,只是作为笑话简单粗暴的类比一下,但想说明的是容器内外的关注点是不一样的、而运维与研发的协同则是深度的.

在Docker刚出现的时候,一直带着前述问题的我们,从其理念已经体会到容器技术对构建一个强韧交易系统的好处.

容器技术的到来,让我们在观念上“弯道超车”：

• 在软件安装、发布方面,我们还需要去学习、模仿Oracle、IBM们研发什么工具吗?不需要了 – 采用容器、容器编排技术、容器镜像管理技术、容器目录(catalog),我们轻易的“一键发布”,而且谁都可以执行.
• 在打补丁方面,我们还要去参考Redhat开发个升级工具吗?没必要了,因为我们不打补丁,已经发布的容器里内容永远不会改变(Immutable),需要修复缺陷或者升级版本,我们就发布新容器 – 发布组件乃至整个全新交易系统,成本都是很低的(并且必须永远维持那么低).因此,我们也不一定需要什么中心化的、统一的、集中的可视化配置管理工具.
• 灰度发布、在线升级、多版本生产环境、回滚现在都是容器化系统天然自带的——因为整个系统的发布、部署是低成本的和快速高效的,只要有硬件资源就再发布一套,不行就切换回旧的那套 – 技术界已经在不断总结最佳实践,总有一款套路适合你.基于容器的微服务,天然支持多服务版本并存；对于回滚,数据库可能是个问题,但首先一切以数据库为中心就是个很有可能是错误的观念(当然,视应用场景而定),在分布式架构里,关系型数据库有可能不在系统关键路径上、事务有好些办法可以规避、通过很好的面向对象设计解耦内存与持久层的耦合… 实际上,经验告诉我们,关系型数据库被滥用是企业应用软件的通病.

而比解决运维问题更有趣的,是这几方面：

• Infrastructure As Code – 现在总算不是口号了,对着容器、容器编排技术进行编码,让“无人值守”、“智能运维”真正成为可能.虽然Puppet、Chef、Ansible这些技术早就存在,但是它们基本上仅限于操作基础设施的物理、虚拟资源,与一个专业应用系统通过API深度结合然后基于业务场景、系统业务指标来自我维护,是非常困难的.而容器,基本上只是一个进程,通过其API可以轻易深度整合到交易系统里.
• 容器技术出现后,也衍生出更多其他新兴技术,例如CoreOS、RancherOS、Unikernel.对于无止境追求极速性能的交易系统,交易软件到底层硬件之间的耗损越少越好,这和我们所遵循的mechanical sympathy技术理念完全一致.类似Unikernel这样的所谓“library OS”非常有趣,因为整个操作系统萎缩成一系列的基础库,由应用软件直接调用以便运行在裸机(bare metal)上.想象一个超级轻量的交易中间件,无缝(真正意义上)运行在裸机上的毫无羁绊裸奔的“爽”…
• 在广发证券IT而言的所谓“弯道超车”,其实更包括几方面的含义：一是观念上的,颠覆传统软件研发的思维,不必要去做追随者；二是技术成长方面的 – 虽然有些技术如Unikernel并未成熟到可以真正运用,但是两三年前的Docker不也一样吗?重要的是团队和一个革命性技术的共同成长,前瞻性技术的研发投入终将回报(capitalize)；三是实际效果上的,虽然在云计算发力的前几年,我们并未投入到IaaS、PaaS的“基建”,但是从容器化入手,忽然间就获得了一定的“计算资源集合使用”的能力 – 此前只有技术实力较强的科技企业能做Grid Computing.

在证券业,我们不是孤独者.华尔街投行的表率高盛,今年2月份宣布了他们一年内把90%的运算能力容器化的计划.

（编辑：ASP站长网）