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

时至今天,在Docker已经被团队广为接受、被应用到各种业务系统中去的时候,我们从两个方向同时继续推进容器化技术：

• 第一个方向,继续沿用上文所述的“Top-Down”思路,基于业务场景、具体应用需要,把容器(Docker)、容器编排管理(Rancher)的技术深度整合到交易系统中去,让其获得自伸缩(elastic)、自监控(self monitor)、自修复(self-healing)的自动化能力 – 这是“反脆弱”系统的一个必要非充分条件.至于什么时候伸缩、什么时候自修复、如何学习自己的运行行为以作自我调整、如何把低级的系统指标换算成业务级别的性能指标作为自己的健康“血压计”… 这些是需持续学习挖掘、测试验证的东西.
• 第二个方向,是上文所述的“Bottom-Up”思路,采用例如Kubernetes建立起一个多租户的CaaS(容器即服务)平台,支持非交易的应用系统(例如电商平台、机器人投顾服务、CRM等等)的跨云(公有云、私有云、传统机房)容器化.

在各种标榜“云”的科技公司层出不穷的今天,其实依然还没有任何“黑科技”帮阁下把你的脆弱系统瞬间变成一个强韧系统甚至一个具备反脆弱能力的系统.所以,容器技术也不过是一个也许必要但不充分的有用工具而已.

能否释放云计算的威力,取决于很多因素.到一个公有云上使用几个虚拟机,也算一个小小的进步,毕竟它可能(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的架构模式,有不少是可以在容器编排调度与协同的这一层实现的.