3.1　H公司容器云建设案例

本节以H公司为例，该公司在中国开设了数百余家分支机构和营业网点。在互联网保险业务领域，它通过技术创新和业务拓展，极大提升了互联网保险业务的竞争力。

3.1.1　H公司业务需求

为了进一步提升企业在中国保险市场的竞争优势，H公司希望利用云计算、大数据等技术，为业务增长提供更为有力的支撑，推动创新业务转型升级。但是，在数字化转型的过程中，它发现IT系统建设面临着严峻的挑战。首先，互联网保险业务正处于快速的演进之中，不但用户需求不断进化，业务环境也瞬息万变，这就对企业的敏捷响应、快速开发能力提出了严格的要求。而客户既有的IT系统基于闭源技术打造，缺乏自主能力，当业务拓展亟需开发创新应用时，IT部门很难敏捷地响应应用开发、升级等需求，不利于对客户自身需求的敏锐洞察与引导。

此外，互联网保险业务具有大规模、高并发的特征，大量的应用需要从海量用户生成的庞大数据中抽丝剥茧，对数据洞察、反馈的响应速度往往需要达到秒级甚至更高，这就对IT系统的处理能力、可用性提出了严苛的要求。由于H公司近几年积极推动互联网保险业务拓展，IT系统需要处理的业务与数据出现快速增长，在高负载的压力下，旧的系统很快出现了运行速度慢、可用性差等问题，如果要通过持续升级软硬件的方式来应对，将会给成本控制带来巨大考验。

3.1.2　业务需求的技术实现

H公司的业务需求，可以转化为以下三方面技术需求。

• 云环境应用基础设施：通过建立一个稳定、高效、标准化的平台，促进产品创新，促使IT运营更加敏捷灵活，为未来企业发展奠定坚实基础。
• 支持快速弹性伸缩：实现IT基础设施资源的合理利用、按需动态调整容量，支持应用系统的快速部署和灵活调度。
• 实现应用快速迭代：促进协同合作，缩短应用开发迭代周期，加快产品推出速度，更好地支持各类版本投产、日常运维和互联网应用等的快速发展。

在上面的需求中，前两个属于PaaS平台的需求，第三个属于DevOps的需求。最终，H公司决定构建基于容器和Kubernetes的容器云平台，并选择了红帽的OpenShift平台。容器云平台使用的持久化存储方案为红帽的Ceph。通过容器云平台，H公司打造了基于容器云的业务（包括但不限于）：互联网核心、销售管理系统、自主经营分析平台、保全无纸化、活动量、增援。

H公司一期项目实施历时4个月，具体实施内容如表3-1所示。

一期项目实施后，H公司的业务能力有了明显的提升，我们可以从如表3-2所示的6个方面进行对比。

接下来我们查看容器云的系统架构图，如图3-1所示。

在图3-1中，客户的请求会先经过DMZ区的A10负载均衡器，转发到OpenShift的Ingress，然后转发到WebServer Pod上。在OpenShift上的WebServer Service中部署Tomcat应用，Consul集群（一主二从）在OpenShift中使用DeploymentConfig形式进行部署，在对集群内部提供服务的同时又可以满足高可用的要求。ActiveMQ作为消息中间件，以主从方式部署到OpenShift上。Web应用与后端的应用交互，通过ActiveMQ实现松耦合。此外，H公司将Redis以三主三从的模式部署到OpenShift上，为应用提供分布式缓存。持久化数据通过在物理服务器部署的Ceph实现。Redis上没有的数据，将会从Ceph中获取。

应用发布图如图3-2所示，一共部署两个容器云集群：第一个集群运行非生产环境，包括SIT、UAT、Pre-Prod三个环境，通过Namespace进行隔离；第二个容器云集群为生产环境，非生产环境成功发布的容器镜像通过容器镜像仓库复制到生产环境的容器镜像仓库进行部署。CI工具使用OpenShift S2I和Jenkins相结合的方式，S2I实现从源码构建，Jenkins实现Pipeline的管理。

借助上述容器云架构，H公司实现了“小核心、大外围”的架构。容器云平台对接的外围系统包括微信销售平台、渠道管理平台、电子保单、易保核心等。

在实施容器云之前，H公司的业务系统主要部署在物理服务器上。所以我们在实施容器云的时候，就会涉及对现有传统应用的容器化改造。在传统物理机或者虚拟化环境中，用得最多的App Server是WebLogic和WAS。但在容器环境中，无论是客户还是ISV，都不会倾向于直接在容器云上部署WebLogic，而是倾向于使用类似Tomcat这样轻量级的App Server。H公司的应用拆分和应用服务器迁移，主要是在ISV主导下完成的，迁移后运行在容器化的Tomcat中。

在介绍了H公司业务需求的技术实现后，接下来介绍项目实施成功的关键因素与难点。

3.1.3　项目实施成功的关键因素与难点

我们知道，一个项目的顺利实施，取决于人、流程、技术三方面。

本次项目实施领导小组的组长是H公司的IT经理，该领导同时管理开发部门和运维部门，且H公司技术人员的项目参与度很高，这相当于扫清了开发部门和运维部门在管理层的壁垒。在项目实施过程中，H公司和红帽都设有项目经理。项目采取项目管理的机制，每周举行项目周例会，沟通一周的实施情况（每次会议时间不必太长，1个小时以内为宜）以及遇到的困难，了解并控制项目实施周期。因此，H公司的容器云项目实施先天就消除了人和流程方面的障碍。具体项目管理周期如表3-3所示。

项目实施过程中的难点主要是H公司与红帽OpenShift产品之间的技术分歧。社区和容器云相关的开源项目多达几十个，在每一个功能点都可以有不同的选择。H公司站在技术自主可控的角度，在技术细节选择方面有自己的主张。OpenShift作为企业级容器云方案，在构建容器云时，也会集成社区开源组件，并经过大量稳定性测试和Bug修复，才能正式发布。这就带来一个问题：OpenShift默认集成的某些开源组件，未必是最新版本，也未必是H公司想采用的。

例如在本次项目中，H公司的技术需求点（包括但不限于）如下所示：

• 容器云入口控制器采用Nginx；
• 容器云SDN使用Calico；
• 应用服务注册发现使用Consul。

这三个技术需求点，都是H公司基于开源社区的技术提出来的。经过红帽与H公司的沟通，站在项目按时上线、风险最低的角度，二者最终达成了一致。

• 针对入口控制器，项目最终使用容器化HAProxy，在七层实现上HAProxy的功能和性能并不比Nginx差，而且红帽提供对HAProxy的技术支持。
• 在SDN方面，H公司主要认为Calico的网络开销小，性能更好；而OpenShift默认使用OVS。虽然OpenShift与Calico会在当前最新的OpenShift版本上发布官方认证，但红帽不会提供Calico Kernel Bug级的问题修复，因此红帽建议H公司在生产环境中使用OVS，以便获得企业级支持。在开发测试环境，可以部署基于Calico的容器云（项目实施过程中，OpenShift发布了对Calico的认证），以便进行功能和性能对比。
• 在服务注册发现方面，Kubernetes和OpenShift都使用etcd。最终，容器云平台保留使用etcd，应用的服务注册发现使用Consul，且应用和Consul均以模板方式部署。

开源社区的技术发现日新月异，迭代很快。但客户在生产环境使用相关的技术时，需要从功能性和稳定性综合考虑，使用某个开源技术最新的版本或者最“潮”的技术未必最合适。像红帽这样的开源技术厂商，它会有清晰的产品路径，紧跟开源社区的技术发展趋势，可以防止陷入开源社区的技术债务。

H公司由于IT部门技术水平较高，因此未提出中文化的需求，使用OpenShift原生的英文界面。在其他的容器云项目中，有的客户对中文化UI提出了较高的要求，即使本身提供中文化UI的容器云厂商，其界面也未必能满足客户对UI的所有需求，因此在项目实施过程中，需要花费较大的成本和较多的时间进行UI的定制化开发，而且结果往往不如人意。从技术角度，建议客户着重关注PaaS平台本身的稳定性和健壮性，而对中文化的UI需求，可以适当予以控制。或者通过单独的开发商进行UI的定制化开发，千万不要将UI操作的便捷性作为容器云平台选型的主要标准。

在介绍了H公司的容器化建设案例后，接下来我们介绍S公司的容器云建设案例。 CspDA+uDlhkEJzUrMu+gOKArDhbyqkcaqUpB4/sWZs78otM5KE6QqfXVsCawcz/w