知乎云原生的架构实践

作者 | 王路

编辑 | 王瑞平

日前，在51CTO主办的WOT全球技术创新大会上，王路带来了主题演讲《知乎云原生的架构实践》，为大众呈现出全新视角。

云原生是一种新兴的软件架构和开发模式，它旨在实现高度可扩展、可靠和可持续的应用程序部署与管理。它的核心理念是将应用程序设计为可运行于云计算环境中的微服务，并采用容器化、自动化管理和弹性伸缩等技术手段来优化应用程序的开发、交付和运维过程。主要特点包括：容器化、微服务架构、自动化运维、持续交付、弹性伸缩等。

文章摘选自王路WOT期间演讲的精彩内容，主要讲述了知乎云原生架构演进的历程和云原生架构的实践。

云原生的出现使软件开发人员能够更好地利用云计算、容器技术和自动化运维等先进的技术手段，构建出高效、可靠和可扩展的应用程序。它为企业提供了更灵活、高效的应用交付和管理方式，也推动了云计算和微服务架构的发展。

与此同时，云原生也带来了一系列的挑战和变革，需要组织和开发团队进行相应的技术转型和组织变革，以适应云原生时代的发展需求。

王路2016年加入知乎，目前担任公司内部云原生团队负责人，负责知乎内部在线基础设施原生架构的建设工作，并亲历了知乎云原生架构演进和实践的全过程。

重新认识云原生：架构演进

云原生就像一个筐，什么东西都可以装进去，但又很难解释清云原生究竟是什么。王路以云原生架构演进为切入点，重新解读了云原生的概念。现在简单了解一下云原生架构的演进历程：

如图所示，业务的演变经历了从单体架构到SOA架构再到微服务架构。基础设施则经历了从物理机到虚拟机再到容器的演进过程。最终，双剑合璧，云原生时代终于到来！

而伴随着云原生的出现，业务架构和基础架构的联系也比以往更密切了。具体表现在：基础架构能够更细致地解决业务问题，真正关注业务痛点而不是基础设施问题。

云原生计算基金会官方对于云原生技术栈的定义包括以下几个部分：一、容器；二、不可变基础设施；三、声明式API；四、服务网格，最后一个是微服务。

其中，微服务属于业务架构，其它4个属于基础架构。在实践过程中，需要将几个技术围绕微服务划分成几个方向，比如，微服务部署、调度以及编排。

另一个比较重要的方向则是微服务的流量管理能力，既包括服务网格，也包含消息队列。并且，服务网格只处理东西向流量管理问题，其实还有南北向流量管理问题。

这些方向最终都需要落地到业务或者使业务受益于云原生基础设施，为此，必须提供DevOps平台，使业务受益于云原生架构。

越早改变，成本越低

知乎云原生架构的演进历程

知乎进行云原生改造时间较早，2014和2015年开始在业务方面进行微服务改造以及容器化。演进历程大概分以下几个阶段：

2016年，知乎完成了全部业务的容器化。当时，知乎的流量和规模较小，改造成本也相对较低。

2016年，知乎完成全部业务的容器化，当时用的是Mesos加自研framework的组合形式。服务发现、注册还有通信用的是注册中心HAproxy。

该阶段过后过渡到下一阶段。2018-2019年，Mesos被替换成了Kubernetes，还将中间件容器化，主要是将HAProxy和卡夫卡都进行了容器化。

下一个阶段是2021年，最大的改变是引入了Service Mesh，部分替换掉原来的注册中心+HAProxy服务的发现和注册方式。另一个比较大的变化是数据库已完成容器化，主要是TIDB和Redis。

如今，知乎主要变成了私有云状态，相当于云建设主要由自己进行；但是，该能力已转移至公有云，并提供了更大资源的弹性能力。另一块比较大的变化就是离在线混部，目前，已获得阶段性进展。

以上就是知乎云原生架构全部的演进历程。

基本架构

调度编排和Kubernetes的流量管理

上图是简单的云原生架构图，相对来讲比较简单。从下向上主要是物理机、虚拟化层，上面则是调度编排层，再往上还构建出了Kubernetes的核心基础服务。

比如，流量管理主要是服务网格、服务网关和消息队列，而对应的服务网格则是东西向的流量管理。

而微服务网关则是南北向的流量管理，消息队列是异步流量管理。中间件有一部分和流量管理重合，比如，Kafka和Pulsar，可能承载了部分流量管理、消息队列的能力，还有TIDB和Redis也都承载于Kubernetes之上。

重点是调度编排层、Kubernetes、流量管理以及可观测、建设在基础设施之上的平台应用，比如，部署平台、服务网格平台、网关平台还有可观测平台。

知乎云原生架构实践

调度编排Kubernetes

知乎在云原生实践过程中针对调度编排Kubernetes有哪些实践经验呢？

上图涵盖了知乎的全部业务。如果这个架构出现任何问题，影响的将是知乎整体业务。而Kubernetes在这个架构图里处于一个承上启下的位置，是整个云原生架构的基石。

如果Kubernetes出了任何问题，影响几乎是灾难性的，因此，稳定性至关重要。

接下来，列举两个Kubernetes稳定性建设核心经验：第一个是控制集群规模；第二个是保护好API server。

首先，控制集群规模对于Kubernetes集群管理来讲有两个主要方向：第一个是超大规模集群；另一个是多个小规模集群。

从知乎的角度看来，维护超大规模集群需要付出巨额的成本，比如，运维成本。而运维3个规模相对较小的集群和维护大集群的运维成本相对来说更低，因为，大规模集群面临的性能问题较多。其次是研发成本，如果运维一万家节点或五千家节点以上，可能需要付出研发成本和对原生组件进行改造。

另一个比较关键的点是故障的影响。业务如果完全放置于大集群，故障发生时的爆炸半径也是极大的。但是，如果分散在多个集群之中，即使某个集群完全崩溃，影响也微乎其微，而不是灾难性的。

从知乎的实践经验来看，多个小规模Kubernetes集群更实用，而不是大规模的超大集群。

但是，如果使用多集群，可能需要解决如下问题：第一个是进行多集群应如何划分；第二个是多集群之间资源需要如何调度；第三个是多集群间如何进行服务发现和通信。

在维护API server稳定性方面。知乎发生过几次相关故障，比如，将异常流量“打挂”后会直接导致“血崩”。此时，需要复用内部网关能力，进行七层限流，可以限制异常流量，将关键组件流量保护住，使Apiserver能够快速恢复。

流量管理实践

服务网格、消息队列、网关

流量管理主要包含3个组件：服务网格、消息队列、网关。

首先解释下一个关键问题，在流量管理的过程中为什么要将东西向流量管理、异步流量管理以及南北向流量管理放在一起呢？

第一，随着业务发展，微服务之间的通信变得越来越复杂。对此提出过很多的治理能力需求，比如，自动配置限流能力和熔断能力等。

第二，现有方案改造，其实就是HAProxy+注册中心方式。理论上来说，你完全可以基于HA进行一整套治理能力的改进，但是研发成本较高。

第三，服务网格方案istio，提供了丰富的标准化流量治理能力。这相当于满足业务需求或业务对基础架构能力的需求。

从架构方面来看，性能上的优化或遇到的最大性能挑战是推送性能。istiod需要将所有配置都推送到Sidecar上。这既需要配置方面的优化，也需要架构上的优化。

现在，知乎自研了一整套限流组件，提供了本地限流能力，包括：全球限流能力，也遇到了负载均衡问题。

实践证明，中心化负载均衡效果较好，但是，当切换到Mesh或sidecar模式，每个sidecar和每个客户端都缺乏全局负载信息，使负载效果在某些业务方面就变得极差。

知乎也针对这些方面做出过一些改进。如果缺少全局信息，就需要将sidecar提上去，然后将一组实例当作单独的负载均衡集群，实现较为均衡的效果。该方案与之前的HAProxy最大的区别是它可以完整获取现有istiod的治理能力。 

可观测实践

Metric、Logging、Tracing

在可观测上实践方面，知乎的底层统一使用Victorial Metrics作为存储系统，而上层都是以Promesql格式进行存储的，既提供了原生的Promesql格式查询，也提供了自研的组件。

图：可观测指标系统

可观测性比较简单，Filebeat是收集端，存储是自研的，搜索依赖于存储，全量日志则是通过Flink落地HDFS。

Tracing统一使用Open Telemetry收集端。ClickHouse则用于存储和查询。性能相对来说可以满足需求。

写在最后

时刻关注业务需求和稳定性

基础架构要时刻关注业务架构的需求。架构升级一定为业务服务，而不是升级。你需要考虑架构升级有没有给业务带来好处，或者业务开发效率和稳定性是否因为架构升级变得更好。另外一点，架构升级的时机要好。

此外，稳定性永远是第一位的。如果保障不了稳定性，所有的架构升级都是空中楼阁。

未来，知乎会更多关注多云多活和离在线混部，继续在全时离在线混部上投入，实现全时混部，并且，Serverless也是未来的发展方向。