下载掌阅APP，畅读海量书库
立即打开
下面以A公司为例来介绍高可用的云服务框架是如何设计和构建的。A公司的例子将充分说明，高可用的云服务框架的构建是一种基于业务驱动、解决痛点、动态演化和发展的过程。
本节将以A公司的英语教学平台基于Kubernetes的容器化实践之路作为案例，来说明云服务架构的高可靠、高性能、高伸缩和高配置性。
从幼儿园、小学、中学、大学和出国留学，A公司几乎涉及每一个教育领域，是国内最大的线上加线下的民营培训机构之一。其教育产品线非常长，也非常复杂，用户量大，遍布各全国各地区。目前有16个云数据中心，包括自建、租用IDC，还通过云联网直接连接了阿里云和腾讯云，最终形成了一套横跨多个云提供商的混合云架构。A公司的云体系很特别，既有相对传统的部分，比如SQL Server、Windows和柜面服务程序，也有比较新的技术，比如TiDB、容器、微服务等。A公司云是一个比较典型的混合云＋容器化的架构体系。
A公司将Kubernetes视为介于PaaS和IaaS层之间的中间层，对下层的IaaS层和上层的PaaS层都制订了接口和规范。对于复杂的业务需求，A公司对Kubernetes引入了其他开源组件进行补充。
A公司的基本技术栈架构如图3-18所示。
图3-18 基于Kubernetes的资源管理架构
运行时组件基于Docker，Host主机操作系统选择的是Ubuntu，Kubernetes网络组件用的是Canal，同时采用Mellanox网卡加速技术。Rancher 2.0作为Kubernetes的管理平台，提供多用户管理、可视化、权限对接AD域等重要功能，同时提供一套稳定的图形化管理平台。
A公司面对的业务难点如下。
（1）提供资源和服务的物理硬件非常多，资源池庞大，增加和变更物理资源不可能依靠人力维护。
（2）在资源池之上必须有动态扩充和释放资源的能力，在业务高峰时，需要把更多资源投入在线课堂，峰值回落时要及时释放资源，节约成本。
（3）开发、测试、部署上线和维护环境必须尽量一致且自动化配置，否则一旦出现bug，会出现全球影响，对客户体验造成严重影响。
（4）整套系统，数千个服务节点，上万个容器，不能依靠人肉运维，必须全部自动化监控、告警和自动故障恢复。
基于上述业务难点，A公司采用基于Kubernetes的弹性容器化架构。
容器化管理的先决条件是解决镜像管理和分发问题。镜像管理，A公司使用的是Harbor（当前版本1.2），后端存储对接ceph对象存储，镜像分发使用的是阿里云开源的DragonFly，它可以将南北向的下载流量转换为东西向，使镜像在node之间的复制成为可能。当集群规模非常大时，减缓拉取镜像对Harbor服务器造成的压力负载。镜像分发系统如图3-19所示。
图3-19 A公司的镜像分发系统
该架构方式是为了解决内部流量问题。在上万个节点之间更新镜像或者更新容器（Docker版本）是不可想象的巨大流量。如果采用传统的中心化私有仓库方式，很快就会在节点更新时因为下载流量巨大导致仓库服务器失去响应。采用DragonFly的点对点分发方案可以有效地解决流量淤塞问题。主要由若干个种子节点从私有仓库中下载完镜像，所有服务节点之间就可以通过P2P协议转发，这样能有效削减集中的流量，A公司的镜像分发架构，可以在几分钟之内将数千个节点的镜像完全升级完毕。
此套节点镜像下发流程完全自动化正是“高可靠”的体现，首先无须人工介入，避免了出错的可能性，其次分发节点有多个，完全可保证即使某几个节点出现错误仍然有其他对等节点提供服务，P2P协议是完全点对点，所以不存在一个绝对的“主服务器”（Master Server），任何节点都能充当“主服务器”。
A公司的Kubernetes集群是运行在物理机上的，当集群规模大了之后，物理机增多，需要引用物理机的管理软件减少运维成本。A公司采用的是Ubuntu的Maas，它是裸机管理平台，可以将没有操作系统的物理机按照模板安装成指定的标准物理机。再结合Ansible初始化物理节点，将它变成业务想要的服务器类型加入集群。比如通过加载TiDB的role把标准物理机变成TiDB的节点，或者通过Kubernetes的role把标准物理机变成Kubernetes节点，同时在每一种role里将Osquery和Filebeat推到物理机上，它们可以收集物理机的机器信息，方便进行资产管理，如图3-20所示。
该结构是为了解决物力资源池如何向业务资源池过渡的问题。物力资源池每次新增加实体资源，都是数十台、几百台物理服务器进入数据中心。如果人工安装系统和基础软件，显然是不可能的。因此必须通过远程控制方案，从模板进行基础安装。当然，因为系统架构是弹性的，当某些节点从应用中释放，必须归还到物理资源池，相应的主机必须回到初始化状态，随时可以被改造成适用于其他服务的类型。通过上述架构，使用ubuntu mass初始化底层系统，通过ansible根据role来预装节点服务类型，将这种繁重的人工运维工作全部免除。
这种动态生成计算节点和回收的技术正是“高伸缩”的体现。因为静态的部署服务实际上无法完全匹配实际的资源消费并随时修改资源配置的。某些机器性能强悍，但是部署的服务不是关键服务，或者大部分的时间不会出现计算的高峰，那么这些服务运算能力完全可以被其他业务所使用。采用动态技术节点之后，闲置的算力可以被充分利用，如果出现普遍闲置则适当回缩计算资源，这样能极大地提高单位时间的资源利用能效比，节约成本。
图3-20 A公司的物理节点管理
这个主要和A公司的研发工程惯性有关。因为线上环境复杂，所以必须有一套和线上环境十分相似的开发、测试、集成环境供技术团队研发使用。工程师写完代码并做完单元测试之后，将代码提交至版本控制服务，通过Jenkins的自动脚本，自动打包到集成环境容器进行联调测试，通过后推送至私有仓库，然后QA团队从私有仓库下载镜像进行验收，验收通过后发布到正式环境。流程如图3-21所示。
图3-21 A公司的CI（Control Integration）流程
该架构就是为了解决研发过程中环境一致性和测试、集成、验收、部署上线的自动化问题。通过Jenkins的脚本调度Kubernetes安排相同的镜像在不同的环境中启动测试、销毁到最终上线。
自动化的交付流程是“高配置”的一种体现。首先是云本身的配置，不同的基础功能如音频、视频、课件播放、课程预约系统都是完全不同的环境配置，运行的数据库、缓存和应用程序环境参数成百上千，所以在Jenkins的自动部署过程中，环境变量必须依靠自动化进行配置。其次是用户的配置。因为A公司的大量课程由不同的供应商提供，其教学流程、作业、考评在业务上都是定制化的体现，因此必须不断地持续交付。如果不采用自动化的测试、验收和部署，全人工的处理这个工程几乎是不可能的。实际上，A公司在自动开发（建站）方面也提供了大量的代码生成器及模版，但是这并不体现在运维流程里面，每个供应商、供应商的不同雇员角色，都有不同的配置模版来针对。对于有运维能力的供应商，A公司也开放了配置管理接口。
集群监控方面，A公司现在用的是开源社区Prometheus的Operator。一开始用的是原生的Prometheus，但是原生的Prometheus在配置告警发现和告警规则上比较麻烦。引用了Operator以后，Operator能大大简化配置过程，比较好用。
图3-22 Prometheus的监控架构
为什么选择Prometheus？这是因为数以千计的节点、数以万计服务的监控量级是非常庞大的，并且维度非常多，同时还有部分时序监控的要求（比如上课开始时间、下课时间、老师进入课堂时间等），而Prometheus体系的特征是：采样节点可以被主动推送到服务的宿主机，时间序列数据通过维度名和键值对来区分，所有的维度都可以设置任意的多维标签，支持双精度浮点类型，标签可以用unicode编码，采样节点占用资源小，可以使用PromQL语句来方便地组合、分组以及进行四则运算，特别适合容器化微服务体系，具有强大的查询优势。
日志是针对两个级别来设置的。业务日志通过sidecar的方式运行Filebeat，把数据收集到Kafka集群里面，再由Logstash输入Elasticsearch，可以减轻ES的压力负载。系统日志直接写进Elasticsearch，如图3-23所示。
ELK（Elasticsearch，Logstash，Kibana）或EFK（Elasticsearch，Filebeat，Kibana）现在已经是分布式微服务平台事实上的日志处理标准解决方案。Elasticsearch独特的索引结构和并行分布处理框架，可以处理日均PB级别的日志输出。所以A公司采用EFK作为日志处理栈，是非常自然的选择。
监控和日志采集是“高性能”的一种体现。人们一般理解高性能，总是试图分析系统能够提供的TPS和QPS，看服务用户的吞吐量。A公司的监控系统本身就是一个非常庞大的独立运行系统，采用了负载均衡及分布式；日志采集更是用了Kafka和Elasticsearch这种分布式超大规模消息队列组件和搜索组件，这从侧面说明为了支持前台业务的高并发，后台也配备了同样规模和容量的服务支撑系统。
图3-23 A公司的日志采集流程
总之，A公司的平台架构，采用的是业界比较成熟的开源解决方案，适合这种大规模分布式节点和海量数据生成的业务。即便在一般场景下，业务规模不像A公司这么大，但其抽象结构仍然可作为后续业务平台仿效构建的一个范例，其技术栈已经能够解决绝大多数平台构建中遇到的问题。
（1）基于P2P方式的镜像分发的方式，可以进行7×24小时持续部署。基于自动化的快速部署，可以提高系统的高可用性。
（2）基于Kubernetes的动态节点管理针对不同服务动态伸缩保证了容量的高伸缩性。
（3）基于Jenkins的CI/CD流程保证了高配置性。
需要注意的是，不同的业务需要有不同的方案。A公司的模式并不是简单复制就能成功的。A公司之所以成功是因为其业务的特殊性和系统特性的良好结合。假如换成一个股权实时交易系统，也许节点分发就不是一个特别好的解决方案，节点分发有延时，而股权交易系统要求必须一致。分发产生的延时在教育系统内不算什么，因为它们可以根据课程安排空出足够的时间，但延时对股权交易系统是致命的。一个好的策略是宣布停机或者只读时间，在规定的时间内完成分发升级，到时后无论是否成功都必须启动或者整体回滚。架构高可用的保证方式多种多样，也绝不是仅仅分布式就能解决的。