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

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

• 容器影响开发者的开发方式、开发习惯,“强迫”他们去思考例如无状态的服务、业务逻辑粒度的控制、资源的弹性伸缩、应用代码的发布形态、系统里面每一个细节的可监控性等等.
• 让真正的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在垂直行业一直被认为是一个成本中心 – 在现在这个时代这是一个错误观点,但这是另一篇文章的讨论范围了)；可是和核心业务应用非常脱节.

（编辑：网站开发网_盐城站长网 ）

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