58 是一组由架构开发的业务实例管理平台，该平台基于内部服务的容器技术。它支持业务实例按需扩展和缩放。该平台提供友好的用户交互过程以及标准化的测试和在线流程。它旨在使开发人员和测试人员摆脱基本环境的配置和管理，以便他们更多地关注自己的业务。本文在实施私人云平台期间与您分享了相关的集装箱技术实践。

本文主要讨论以下三个部分：

背景：当前的问题是什么以及为什么使用容器技术

整体体系结构：整个容器技术的体系结构解决方案

核心模块的设计方案：某些核心模块的选择决策和解决方案

为什么使用容器技术

在使用容器化技术之前，我们遇到了这些问题：

资源利用问题

不同的业务方案对资源有不同的要求，包括CPU密集型，内存密集型和网络密集型，这可能会导致不合理的资源利用。例如，如果部署在计算机上的服务是网络密集型的，则将浪费CPU资源和内存资源。一些企业可能只专注于服务本身，而忽略机器资源利用率的问题。

混合部署交叉影响

对于在线服务，如果机器需要以混合方式部署多种服务，则服务之间可能会产生相互影响。例如，如果由于某些原因而导致的网络流量突然激增，则可能会填充整个机器的带宽，而其他服务将受到影响。

低膨胀/收缩效率

当需要扩展/收缩业务节点时，从下线到应用程序部署和测试的周期相对较长。当企业遇到突然的交通高峰时，手工部署机器后可能已经通过。

多环境代码不一致

由于过去的内部发展过程不规则，因此存在一些问题。测试环境完成后，可以在沙箱中修改和调整业务测试的代码，然后在线打包和启动。这将导致不一致的测试代码和在线运行代码，这将增加在线服务的风险，并增加对在线服务进行故障排除的困难。

缺乏稳定的离线测试环境

在测试过程中，您将遇到问题。该服务取决于的其他下游服务不能提供稳定的测试环境，这使得无法模拟在测试环境中测试的整个在线过程。因此，许多测试学生将使用在线服务进行测试，这在这里具有很高的潜在风险。

为了解决上述问题，建筑线云团队进行了技术选择并重复演示，并最终决定使用容器技术。

整体架构

58个私有云的整体架构如下：

基础设施

整个私有云平台接管了所有基础架构，包括服务器，存储和网络资源。

容器层

整个容器初始化层都在基础架构上方提供。容器初始化层包含IPAM；这是一个调度和管理组件；它被部署在主机上，以管理系统资源和基础基础架构，包括监视收集，日志收集，集装箱速度限制等。IPAM是用于管理整个网络系统的IP资源的网络管理模块。

资源管理

容器层上方是资源管理层，包括容器管理，减少容量，回滚和降级，在线发布，配额管理，资源池管理和其他模块。

应用层

运行一个用户提取的业务实例，该实例可以是任何编程语言。

基本组件

私有云平台为容器操作环境提供了必不可少的基本组件，包括服务发现，镜像中心，日志中心和监视中心。

服务发现

访问云平台的服务提供了统一的服务发现机制，以促进业务访问云平台。

镜面中心

存储业务图像，分布式存储，弹性扩展。

日志中心

集中收集业务实例日志并提供统一的可视化门户，以促进用户分析和查询。

监视中心

所有主机和容器监视信息，监视查看和警报自定义的摘要，为智能调度提供了基础。

统一门户

UI门户页面，标准化整个业务流程，简单的用户流程，并在整个云环境中动态管理所有资源。

全新的建筑带来了新的业务流通方式：

该平台定义了四个基本环境：测试环境，沙箱环境，稳定的环境和在线环境。业务根据SVN提交的代码构建图像，图像的整个生命周期都在4个环境中流动。由于实例是基于同一图像创建的，因此可以确保程序通过测试与在线运行的程序完全相同。

测试环境：测试人员进行功能测试并连接到离线环境；

沙盒环境：计划预发行环境，停靠在线环境；

在线环境：提供服务的在线环境；

稳定的环境：运行离线环境的实例，为其他上游服务提供稳定的测试环境实例。

核心模块的设计计划

开发58个私有云平台时需要考虑许多细节。在这里，我们将与您分享五个核心模块：容器管理，日志收集，网络模型，监视和警报以及 。使用这些核心模块，该平台具有可以操作的基本框架。

容器管理

我们调查了三个主要的管理平台：通过比较，我们终于选择了。功能太简单了，所以我首先通过了它。 +是一个成熟的解决方案，但是社区还不够活跃，在使用时，我必须熟悉两组框架。这是一个专门为容器技术提供的调度管理平台。它更加敬业，社区非常活跃，并且有许多支持组件和解决方案。越来越多的公司正在使用它。通过与某些公司的沟通，他们正在逐渐从上方迁移应用程序。下表显示了我们团队关注的一些比较：

应用隔离机制

//

资源类型

内存CPU端口

内存CPU端口

内存CPU端口

主机分组

过程标签

分组

分组

调度策略

资源使用

资源使用

资源使用 +应用节点余额

编排

不

是的

是的

网络模式

本国的

支持自我建造

支持自我建造

主要高可用性

双主开关

ZK

等

收缩和扩展

二级发展

API修改

API修改

健康检查

不

是的

是的

故障转移

不

是的

是的

应用程序升级

不

不

是的

负载平衡

不

k

群集大小

小的

中间

中等，改进

生产和使用

较少的

大规模使用

大规模使用

网络模型

网络模型是任何云环境都必须面临的问题，因为一旦网络量表扩展，它将带来各种问题。网络选择基于顺序特征的特征，以下是：

网络模型

优势

缺点

主持人

自从

与主机分享

高网络性能和简单的网络

容器不与主机隔离

港口冲突，需要隔离服务

带上自己的

高性能和简单的网络

使用可用的主机段IP

快速的IP消耗

多机iPS防止冲突

VLAN用于网络隔离，VLAN消费量很快

本国的

进来，官方支持

根据实现，容器可以任意指定子网

多收益通信和隔离是一个问题；网络更复杂，这不利于问题跟踪和调试

根据实施，容器具有独立的IP，并支持交叉纸网通信

性能损失略有大，与外部网络的沟通需要特定的解决方案，网络更复杂

完全通过第三层路由实现，没有其他IP转换，高性能

打开网络中的BGP协议，该协议可能达到路由器的路由容量

对于每个网络模型，云团队都进行了相应的性能测试，因为公司使用的计算机室不支持打开BGP协议，因此没有执行测试。

测试网络带宽结果如下：

测试TCP延迟结果如下：

测试UDP延迟结果如下：

从测试结果中，我们可以看到主机模式和模式的性能最接近主机，并且在其他网络模式中仍然存在一些差异，这与原理有关。

由于以下原因，私有云平台最终选择 + VLAN网络方法：

良好的性能，简单的网络以及与现有网络的无缝连接；它可以在容器，容器，容器和主机之间实现良好的通信。

故障很容易调试，可以通过传统的SA解决；它可以适应任何物理设备，并且可以大规模扩展

公司的内部服务基于RPC协议，其自己的服务发现机制可以非常兼容；现有的内部框架更改很小

由于最多有4096个VLAN，因此VLAN的数量有一个限制，这就是为什么有VLAN的原因。在当前的云平台网络计划中，VLAN就足够了。将来，随着使用量表的扩大和技术的发展，我们还将对更合适的网络方法进行深入的研究。

还有一些学生在上反馈IPIP模式网络性能，这也很高。但是，考虑到目前存在许多陷阱，需要一个特殊的网络组来支持云团队缺乏的网络组，因此没有深入的研究。

这里还有另一个问题。默认使用模式是每个主机都配置了不同网络段的地址，因此分配给不同主机上的容器的IP不会冲突，但这也会导致大量IP浪费。计算机室的环境中的IP资源有限，并且无法以这种方式配置网络，因此您只能为全局IP管理开发IPAM模块。 IPAM模块的实现是指开源项目

（）实现，将可分配的网络段写入ETCD。启动实例后，将通过IPAM模块从ETCD获得可用的IP。当实例关闭时，将返回IP。整体架构如下：

此外，由于不支持CNM，我们已经修改了源代码。

在网络中还有另一点要考虑：网络速度限制。由于空间原因，我不会在此处详细介绍，稍后我将详细讨论。

镜子仓库

镜像仓库使用官方的镜像仓库，但我们选择了后端提供的存储系统。本地磁盘的默认方法不能应用于在线系统。具体选择如下：

通过比较，我们可以看到CEPH最合适，但最终，由于以下原因，云团队选择使用HDFs作为镜像仓库的后端存储：正式默认值是官方默认值支持的存储类型，但是构建一组设置并确保其稳定的操作需要深入研究。由于人员有限，尚未使用所有人员，Ceph也没有根据相同的原则做出选择。 HDFS 拥有专门的数据平台部门用于管理和维护。他们更专业，云团队可以充满信心地在HDF上托管镜子。但是，HDFS本身也存在一些问题，例如在压力很高时无法及时做出反应。将来，我们将考虑将后端存储迁移到建筑线部门内的自发对象存储，以提供稳定，高效的服务。

日志系统

当传统服务转移到容器环境时，记录是一个大问题。由于已准备好使用容器，因此在关闭容器后，也将删除容器的存储空间。尽管可以将容器中的日志导出到主机上指定的位置，但容器通常会漂移。故障排除时，我们还需要知道在历史上的某个时刻，哪个主机正在运行。由于用户没有主机登录权限，因此用户无法很好地获得日志。在容器环境中，需要新的故障排除方法。在这里，一个一般解决方案是采用集中式日志解决方案，以统一的方式收集和存储分散的日志，并提供灵活的查询方法。私有云平台采用以下解决方案：

用户配置要在管理门户上收集的日志。私有云平台通过环境变量将其映射到容器中。要收集的日志是根据环境变量获得的，并启动集合。将日志上传到原始日志，上传的日志可确保严格的订单。有两个订户，一个将日志上传到搜索服务中，以用于管理门户网站查询。其他将日志上传到HDFS以查询和下载历史日志。用户还可以自己编写程序来分析指定的日志。

监视警报

资源监视和警觉也是云平台不可或缺的一部分。有许多成熟的开源软件可供选择用于容器监视，而58还具有特殊的监视组件。云团队还选择了如何更好地监视的相应模型。

最后，云团队选择将其用作容器的监视组件。由于它集成了物理机器和警报逻辑，因此我们不需要进行相应的开发，因此我们只需要开发容器监视部分的组件，我们可以很好地自定义它来满足内部监视需求。 + +是一个官方的监视组件，在较大的情况下使用它并不是一个问题，但是当它很大时可能会有问题，因为它正在进行轮询以获取所有节点的监视信息。