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

能否释放云计算的威力,取决于很多因素.到一个公有云上使用几个虚拟机,也算一个小小的进步,毕竟它可能(1)缩短了一些传统企业采购硬件、机器上架等等的周期；(2)帮不擅长互联网技术的传统企业解决一部分“互联网最后一公里”问题.然而,这只不过是使用了一些虚拟化基础服务,如果部署在上面的系统本身是一个脆弱系统,那么它在云上依然是一个脆弱系统.

实现一个强韧甚至反脆弱的技术系统,你首先得有一个恰当的技术架构,而实现这样的技术架构,你首先需要有研发团队 – 不错,个人观点是,在现阶段如果不具备软件研发能力,那么你的组织其实无法真正利用、享受到云技术带来的福利.

怎样的架构才能利用和释放云计算能力?

首先,架构设计需要遵循Reactive(响应式)原则(根据“响应式宣言”)：

• Elasticity – 弹性响应系统负载变化,基于实时性能监控指标以便通过预测性(predictive)和响应性(reactive)算法来对系统进行扩容.
• Resiliency – 通过复制(replication)、包容(containment)、隔离(isolation)和委托(delegation)等机制,保障在故障发生时系统能继续高度可用.
• Responsive – 系统及时探测侦察问题并解决问题,保障对外的及时响应.
• Message-driven – 采用消息驱动的、非堵塞的异步通讯机制,降低系统内部组件模块间的耦合度,提升吞吐量.

其次,在技术研发过程中,我们采用一系列的所谓“Cloud-native patterns”(原生,或者说“天然”的云计算架构模式)来实现我们的系统,以便让系统达到Cloud-ready(具备云感知能力 – 借用IBM与Intel相关中文版论文的概念).

此外,“云感知”和上述“响应式”原则,是完全一致的,云感知也关注“故障恢复能力”、“延迟恢复能力”、“扩展的灵活性”.事实上,在一流的金融IT团队里,这些原则、实践要求,从来都是被遵循的,因为金融的应用系统天然需要这些能力.无论是否在云计算时代,这些原则、要求均非常合理.

那么容器化技术在这其中有什么作用呢?实践告诉我们,作用很大.最重要一点是,很多pattern的具体技术实现,可以挪到容器层面去处理.例如Circuit-breaker和Fail-fast这类模式,过去的做法,是各个具体的服务,采用自己的技术工具(例如Node.js的守护进程PM2)和办法,基于开发者自己的理解,各自实现.

容器化的好处,是把复杂系统里一切异构的技术(无论以Go、Java、Python还是Node.js实现)都装载到一个个的标准集装箱里,然后通过调度中心基于各种监控对这些集装箱进行调度处理.也就是说,Cloud-native的架构模式,有不少是可以在容器编排调度与协同的这一层实现的.