有一种不切实际的看法，认为只要把单体应用放进容器，就能轻松获得现代架构在扩展能力和速度方面的优势。
事实上，一项KubeKon 2018调查显示，约55%的受访者表示，他们将容器“用作现有应用的虚拟机替代方案”，这表明上述情况确实正在发生。其他调查显示，大量企业级Java应用正在容器中运行。一项2018年Diamanti调查显示，虽然大多数受访者（54%）将容器用于云原生应用，但近三分之一（31%）使用容器对旧版应用进行现代化改造。
所提及的原因通常与运维有关。尽管需要管理的动态组件数量激增，但容器仍被认为更易于管理。性能和许可费用也往往是决定采用容器时的考量因素。
但这一转变并非只是将旧版应用打包后放入容器那么简单。
事实上，单体应用（即传统的客户端-服务器应用和Web应用）具有某些特性，因此很难直接迁移到容器中并获得运维优势。容器和微服务并不一定相伴而生，但二者都倾向于采用现代应用可用性所依赖的“为故障而设计”原则。如果您不熟悉这一原则，它指的是：如果一个容器发生故障，只需启动另一个容器来替代它。所有容器都像牲畜一样可以替换，彼此没有区别。
在有意采用的现代无状态应用架构中，确实如此。但在传统的有状态应用架构中，情况并非如此。
客户端-服务器架构及其后继的三层Web应用通常都是有状态的。它们会在会话中保留客户端与应用交互的某些信息。该会话可能存储在应用服务器或Web服务器的内存中，也可能存储在单独的数据库中。无论这些数据存储在何处，正是它们使应用具有状态。这些数据与应用的运行密切相关，十分重要，其中包括购物车、上次访问的页面以及其他应用特定信息。
可以想象，如果存储这些信息的Web或应用服务器突然不可用，客户端体验就会受到影响。购物车里的商品不见了，我必须重新找到之前的位置，基本上只能从头开始。
这种行为与消除应用有状态运行的现代架构原则背道而驰。正是现代应用和服务的无状态特性，使其能够在出现问题时无缝地用一个实例替换另一个实例。这是“为故障而设计”理念得以实现的基础。如果重新引入状态，整个体系就会突然崩溃。
虽然应用仍可运行，但用户却无所适从。用户流程被中断，交易也仿佛石沉大海，再也无法找回。
正是这一问题催生了应用服务保持状态的需求。客户端一旦连接到特定的应用或Web服务器，就必须在整个会话期间始终连接到同一台服务器。为确保每次请求都路由到同一台服务器，人们开发了Cookie持久性等机制，从而保持状态。
实际情况是，除非贵公司是一家从零起步的初创企业，否则目前通常会同时运行传统应用和现代应用。尽管不同研究的结果有所差异，但“63%为旧版应用，37%为新应用”这一比例长期以来基本保持稳定。这意味着贵公司需要同时支持传统架构和现代架构。
如果尚未解决有状态与无状态之间的差异，仅仅将单体应用迁移到容器中并不能解决问题。
架构分层
管理单体应用向容器化环境迁移时，一种较为简便的方法是确保即使面对容器集群中无状态的混乱局面，仍能妥善处理状态。这需要在集群边缘，也就是南北向流量与东西向流量交汇的入口处部署一些智能功能。
双层方法既支持传统和现代运维模式，也支持将传统有状态应用迁移到容器化环境。借助F5 Container Ingress Services（CIS），网络运维团队可以继续满足有状态应用在迁移到容器化环境过程中的需求。这种连接可确保采用持久性的传统负载均衡方法继续运行，并将请求定向到正确的容器或直接转发到传统环境。
同时，BIG-IP可将现代应用和API的请求定向到容器集群内的入口控制器，并根据需要将请求分发到相应数量的无状态容器。
转型需要时间
实际情况是，大多数组织需要支持多达5种截然不同的应用架构，包括单体架构、移动应用和微服务。如果同时支持数量相当且各不相同的网络和运维模式，运维团队必然会不堪重负，转向现代架构和环境所带来的优势也会被抵消。采用战略性的双层方法，组织可以在向以容器化为主的环境过渡期间，充分发挥这两种模式在运维和业务方面的优势。
重构方案
为简化这一转型过程，可以重构旧版应用，使其能够利用共享会话。这些会话存储在与Web服务器或应用服务器分离的位置（通常是某种数据库），任何Web服务器或应用服务器只要拥有正确的会话ID即可访问。仍需跟踪会话ID，但通常可以通过Cookie实现；无论Web服务器或应用服务器处于何种状态，该Cookie都会持续保留。如果旧版应用尚未采用共享会话模型，与对整个应用进行平台迁移相比，重构应用以采用该模型通常并不复杂。
此类转型需要时间，毕竟目前几乎所有组织仍在采用多云模式。因此，应寻找并利用合适的架构方案，在不影响可用性和安全性等客户核心需求的前提下，尽可能发挥优势。采用双层架构既能兼顾这些需求，又不会限制容器化进程。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。