「回忆2022，展望2023，我正在参与2022年终总结征文大赛活动」

本文从研制规范层面、应用服务层面、存储层面、产品层面、运维布置层面、反常应急层面这六大层面去剖析一个高可用的系统需求有哪些关键的规划和考虑

高可用架构和系统设计经验

一、高可用架构和系统规划思维

可用性和高可用概念

可用性是一个可以量化的目标，核算的公式在维基百科中是这样描述的：依据系统损害、无法运用的时刻，以及由无法运作康复到可运作情况的时刻，与系统总运作时刻的比较。行业内一般用几个9表明可用性目标，对应用的可用性程度一般衡量规范有三个9到五个9；一般咱们的系统至少要到 4 个 9（99.99%）的可用性才干谈得上高可用。

高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中止地履行其功用的才干，代表系统的可用性程度，是进行系统规划时的准则之一。服务不或许 100% 可用，因而要进步咱们的高可用规划，就要尽最大或许的去添加咱们服务的可用性，进步可用性目标。一句话来表述便是：高可用便是让咱们的服务在任何情况下都尽最大或许可以对外供给服务。

高可用系统规划思维

高可用系统的规划，需求有一套比较科学的工程办理套路，要从产品、开发、运维、基建等全方位去考量和规划，高可用系统的规划思维包含但不限于：

  • 做好研制规范，系统都是研制人员规划和编码写出来的，因而首要要对研制层面有一个规范和规范
  • 做好容量规划和点评，首要是让开发人员对系统要抗住的量级有一个根本认知，方便进行合理的架构规划和演进。
  • 做好服务层面的高可用，首要是负载均衡、弹性扩缩容、异步解耦、毛病容错、过载保护等。
  • 做好存储层面的高可用，首要是冗余备份（热备、冷备）、失效转移（确认，转移，康复）等。
  • 做好运维层面的高可用，首要是发布测验、监控告警、容灾、毛病演练等。
  • 做好产品层面的高可用，首要是兜底战略。
  • 做好应急预案，首要是在呈现问题后怎样快速康复，不至于让咱们的反常事态扩展。

二、研制规范层面

计划规划和编码规范

研制规范层面这个是咱们简略忽视的一个点，可是，咱们一切的规划，都是研制人员来完结的，包含从规划文档到编码到发布上线，因而，研制层面也是有一个规范流程和套路，来让咱们更好的去研制和保护一个高可用的系统：

  • 规划阶段

    • 规范好相关计划规划文档的模板和提纲，让团队内部保持一致，可以参阅我的文章《技能计划规划模板》
    • 计划规划后必定要进行评定，在咱们团队中，新项目必定要评定，重构项目必定要评定，大的系统优化或许升级必定要评定，其他的一般研制工作量超越一周的主张要评定的。

  • 编码阶段

    • 履行代码规范
      • 工程的 layout 目录结构规范，团队内部保持一致，尽量简洁
      • 遵从团队内部的代码规范，一般公司都有对应言语的规范，假如没有则参阅官方的规范，代码规范可以大大削减 bug 而且进步可用性。
    • 单测掩盖率
      • 代码编写完需求有必定的单测来确保代码的健壮性，一起也能保障咱们后续调整逻辑或许优化的时分可以确保代码的稳定
      • 包含增量掩盖率、全量掩盖率，具体的掩盖率要到达多少可以依据团队内部的实践情况来定，在咱们团队，定的规则是 50% 的掩盖率。
    • 日志规范
      • 不要随便打日志
      • 要接入长途日志
      • 要可以散布式链路追寻

  • 发布上线阶段，参阅下面运维布置层面那一章节的灰度发布和接口测验相关说明

容量规划和点评

容量点评，是指咱们需求点评好，咱们这个系统，是为了应对一个什么体量的事务，这个事务恳求量的平均值、高峰的峰值大概都在一个什么等级。假如是新系统，那么就需求依据产品和运营同学对事务有一个大体的预估，然后开发同学依据产品给的数据再进行具体的点评。假如是老系统，那么就可以依据历史数据来点评。点评的时分，要从一个全体角度来看全局的量级，然后再细化到每个子事务模块要承载的量级。

容量规划，是指咱们系统在规划的时分，就要可以初步规划好咱们的系统大致可以抗多少的量级，比方是十万仍是百万等级的恳求量，或许更多。不同的量级对应的系统架构的规划会彻底不相同，尤其到了千万、亿等级的量级的时分，架构的规划会有许多的考量。当然这儿需求留意的是，咱们不需求一上来就规划出远超于咱们当时事务实在流量的系统，要依据事务实践情况来规划。一起，容量规划还涉及到，咱们系统上下流的各个模块、依靠的存储、依靠的三方服务，别离需求多少资源，需求有一个相对可以量化的数据出来。容量规划阶段，更多是要依靠本身和团队的经历，比方要了解咱们的 log 的功用、redis 的功用、rpc 接口的功用、服务化结构的功用等等，然后依据各种组件的功用来归纳点评自己规划的系统的全体功用情况。

容量点评和容量规划之后，咱们还需求做一件工作，便是功用压测，最好是可以做到全链路压测。功用压测的意图是为了确保你的容量规划是准确的，比方我规划的这个系统，我规划的是可以抗千万等级的恳求，那么实践上，真的可以抗住吗 ？这个在上线之前，首要要依据经历来判别，然后是必定要经过功用压测得出准确结论的。**功用压测要关注的目标许多，可是要点要关注是两个目标，一个是 QPS、一个是响应耗时，要确保压测的结果符合预期。**压测的进程可以先分模块独自压测，最终假如情况允许，那么最好履行全链路压测。

QPS 预估（漏斗型）

QPS 预估（漏斗型），指的是一个实在的恳求过来后，从接入层开始，别离经过了咱们整个系统的哪些层级、哪些模块，然后每一个层级的 QPS 的量等级离有多少，从恳求链路上来看，层级越往下，那么下流层级的量级应该会逐渐削减的，由于每经过一个层级，都有或许会被各种条件过滤掉的一部分恳求。比方说进入活动页后查看产品概况然后下单这个例子，首要进入活动页，一切的恳求都会进入拜访；然后只会有部分用户查询产品概况；最终查看产品概况的这些用户又只会有部分用户会下单，因而这儿就会有一个漏斗，从上层模块到基层模块的量级必定是逐渐削减的。

QPS 预估（漏斗型）便是需求咱们按照恳求的层面和模块来构建咱们的预估漏斗模型，然后预估好每一个层级的量级，包含但不限于从服务、接口、散布式缓存等各个层面来预估，最终构成咱们完好的 QPS 漏斗模型。

三、应用服务层面

无情况和负载均衡规划

一般要做到系统的高可用，咱们的应用服务的惯例规划都是无情况的，这也就意味着，咱们可以布置多个实例来进步咱们系统的可用性，而这多个实例之间的流量分配，就需求依靠咱们的负载均衡才干。无情况 + 负载均衡 既可以让咱们的系统进步并发才干，也可以进步咱们系统的可用性。

假如咱们的事务服务运用的是各种微服务结构来开发的，那么大概率在这个微服务结构里边就会包含了服务发现和负载均衡的才干。这是一整套流程，包含服务注册和发现、负载均衡、健康情况查看和主动除掉。当咱们的任何一个服务实例呈现毛病后会被主动除掉掉，当咱们有新增一个服务实例后会主动添加进来供给服务。

假如咱们不是运用的微服务结构来开发的，那么就需求依靠负载均衡的署理服务，比方 LVS、Nginx 来帮咱们完成负载均衡。

弹性扩缩容规划

弹性扩缩容规划是应对突峰流量的十分有用的手段之一，一起也是保障咱们服务可用性的必要手段。弹性扩缩容针对的是咱们的无情况的应用服务而言的，由于服务是无情况的，因而可以随时依据恳求量的巨细来进行扩缩容，流量大就扩容来应对许多恳求，流量小的时分就缩容削减资源占用。

怎样完成弹性扩缩容呢？现阶段都是云原生年代，大部分的公司都是选用容器化（K8s）布置，那么依据这个情况的话，弹性扩缩容就十分简略了，只需求装备好 K8s 的弹性条件就能主动依据 CPU 的运用率来完成。

假如不是容器化布置，是物理机布置的方法，那么要做到弹性扩缩容，有必要要有一个公司内部的基础建造才干，可以在运营渠道上针对服务的 CPU 或许 QPS 进行监控，假如超越必定的比例就主动扩缩容，和 K8s 的弹性原理是相同的，仅仅需求自行完成。

异步解耦和削峰规划（音讯行列）

要想咱们的系统可以高可用，那么从架构层面来说，要做到分层、分模块来规划，而分层分模块之后，那么各个模块之间，还可以进行异步处理、解耦处理。意图是为了不相互影响，经过异步和解耦可以使咱们的架构大大的提高可用性。

架构层面的异步解耦的方法便是选用音讯行列（比方常见的 Kafka），而且一起音讯行列还有削峰的效果，这两者都可以进步咱们的架构可用性：

  • 异步解耦：选用音讯行列之后，可以把同步的流程转换为异步的流程，音讯生成者和顾客都只需求和音讯行列进行交互，这样不仅做了异步处理，还讲音讯生成者和顾客进行了阻隔。异步处理的优势在于，不论音讯的后续处理的事务服务是否 ok，只需音讯行列还没满，那么就可以履行对外供给服务，而消费方则可以依据本身处理才干来消费音讯后进行处理。解耦的优势在于，假如消费方反常，那么并不影响生产方，仍然可以对外供给服务，音讯顾客康复后可以继续从音讯行列里边消费数据后履行事务逻辑

  • 削峰：选用音讯行列之后，还可以做到削峰的效果，当并发较高的时分，乃至是流量突发的时分，只需音讯生产者可以将音讯写入到音讯行列中，那么这个音讯就不会丢，后续处理逻辑可以渐渐的去音讯行列里边消费这些突发的流量数据。这样就不会由于有突发流量而把整个系统打垮。

毛病和容错规划

任何服务，必定会存在失败的情况，不或许有 100% 的可用，服务在线上运转进程中，总会遇到各种各样意想不到的问题会让你的服务呈现情况，因而业界来点评可用性 SLA 都是说多少个 9，比方 4 个 9(99.99%)的可用性。

为此，咱们的规划主张遵从”design for failure”的规划准则，规划出一套可容错的系统，需求做到尽早回来、主动修复，细节如下

  • 遵从 fail fast 准则，Fail fast 准则是说，当咱们的主流程的任何一步呈现问题的时分，应该快速合理地结束整个流程，赶快回来过错，而不是比及呈现负面影响才处理。

  • 具备自我保护的才干。当咱们依靠的其他服务呈现问题的时分，要赶快的进行降级、兜底等各种反常保护措施，要防止呈现连锁反应导致整个服务彻底不行用。比方当咱们依靠的数据存储呈现问题，咱们不能一直重试然后导致数据彻底不行用。

过载保护规划（限流、熔断、降级）

系统无法高可用的一个重要原因就在于，咱们的系统经常会有突发的流量过来，导致咱们的服务超载运转，这个时分，首要要做的当然是快速扩容，而且咱们事前就要预留好必定的冗余。另外一个情况下，就算咱们扩容了，可是仍是会超载，比方超越了下流依靠的存储的最大容量、或许超越了下流依靠的三方服务的最大容量。那么这个时分，咱们就需求履行咱们的过载保护战略了，首要包含限流、熔断、降级，过载保护是为了确保服务部分可用然后不至于整个服务彻底不行用。

  • 限流。限流是指对进入系统的恳求进行限流处理，假如恳求量超越了咱们系统最大处理才干或许超越了咱们指定的处理才干，那么直接拒绝恳求，经过这种丢掉部分恳求的方法可以确保整个系统有必定的可用性，然后不至于让整个系统彻底不行用。怎样判别超越最大处理才干呢？ 一般便是针对 QPS 来判别，假如 QPS 超越阈值，那么就直接拒绝恳求。

    • 限流有许多细节的战略，比方针对接口限流、针对服务限流、针对用户限流。

  • 熔断。熔断，断路（开路）的价值在于约束毛病影响规划。咱们希望控制、削减或中止和毛病系统之间的通讯，然后降低毛病系统的负载，有利于系统的康复。一般咱们的服务都会有许多下流依靠，假如下流依靠的服务呈现问题，比方开始超时乃至响应十分慢的情况下，假如咱们不做任何处理，那么会导致咱们的整个恳求都被卡住然后超时，那么咱们的事务服务对外就无法供给任何正常的功用了。为此，熔断战略就可以处理这个问题，熔断便是当咱们依靠的下流服务呈现问题的时分，可以快速对其进行熔断（不建议恳求），这样咱们的事务服务至少可以供给部分功用。熔断的规划至少需求包含 熔断恳求判别机制算法、熔断康复、熔断告警 三部分

  • 降级。降级是指咱们划分好系统的中心功用和非中心功用，然后当咱们的系统超越最大处理才干之后，直接关闭掉非中心的功用，然后保障中心功用的可用。关闭掉非中心的功用后可以使咱们的系统释放部分资源，然后可以有资源来处理中心功用。

    • 熔断和降级这两个战略，看着比较像，字面的意思上来看都是要快速拒绝掉恳求。可是他们是两个维度的规划，降级的意图是应对系统本身的毛病，而熔断的意图是应对咱们系统依靠的外部服务毛病的情况。

四、存储层面

在当时的互联网年代，应用服务根本都是无情况的，因而应用服务的高可用相对会比较简略，可是关于数据存储的高可用，相对来说，会杂乱许多，由于数据是有情况的，那具体咱们要怎样保障数据存储的高可用，咱们来剖析下。

存储层面的高可用计划的实质都是经过经过数据冗余的方法来完成高可用，将数据仿制到多个存储介质里边，可以有用的防止数据丢掉，一起还可以进步并发才干，由于数据是有情况的，因而，这儿会比服务的高可用要杂乱许多，首要体现在如下几个方面

  • 数据怎样仿制？
  • 各个节点的责任是什么？
  • 怎样应对仿制延迟？
  • 怎样应对仿制中止？

常见的处理存储高可用的计划有两种：集群存储和散布式存储。业界大多是围绕这些来构建，或许是做相关衍生和扩展。

集群存储（会集式存储）

集群便是逻辑上处理同一任务的机器调集，可以属于同一机房，也可分属不同的机房。集群存储，便是把多台机器上的存储数据组合在一起对外构成一套一致的系统。集群存储合适事务存储量规划一般的场景，惯例的事务数据存储一般都是集群存储方法就足够了。现在咱们一般关于事务数据存储的运用，默许都是集群方法，比方 Redis、MySQL 等存储类型，一般中大型互联网公司，默许必定都是集群存储的方法。

集群存储便是咱们常说的 1 主多备或许 1 主多从的架构，写数据经过主机，读数据一般经过从机。集群存储首要需求考虑如下几个问题：

  • 主机怎样将数据仿制给备机（从机）

    • 数据的写入都是经过主机，因而数据同步到备机（从机），便是要经过主机进行数据仿制到备机（从机）。
    • 还需求考虑主备同步的时刻延迟问题。

  • 备机（从机）怎样检测主机情况

  • 主机毛病后，备机（从机）怎样切换为主机

    • 主从架构中，假如主机毛病，可直接将备机（从机）切换为主机

1，主备仿制

主备仿制是最常见也是最简略的一种存储高可用计划，简直一切的存储系统都供给了主备仿制的功用，例如 MySQL、Redis、MongoDB 等。

主备架构中的“备机”首要仍是起到一个备份效果，并不承当实践的事务读写操作，假如要把备机改为主机，需求人工操作。因而一般运用场景都是在一些内部的后台办理系统中运用。

2，主从仿制

主从仿制和主备仿制尽管只有一字之差，可是两者是不相同的规划思路，“从”意思是“随从、仆从”，“备”的意思是备份。”从“ 的机制是要干活的，因而是承当数据的“读”操作的，一般便是主机担任读写操作，从机只担任读操作，不担任写操作。

3，主从切换

主备仿制和主从仿制计划存在两个共性的问题：

  • 主机毛病后，无法进行写操作。
  • 假如主机无法康复，需求人工指定新的主机人物。

主从切换（主备切换）便是为了处理这两个问题而发生的，具体的规划便是在原有计划的基础上添加“主动切换”的才干，当主机反常后，经过系统检测而且主动将备机或许从机切换为主机。这个是实践应用中比较多的一个计划之一，由于咱们必定可以有机制确保主机反常后从机可以主动切换为主机。

4，主主仿制

主主仿制指的是两台机器都是主机，相互将数据仿制给对方，客户端可以恣意选择其间一台机器进行读写操作，假如采取主主仿制架构，有必要确保数据可以双向仿制。这个相对来说，要求较高。

散布式存储

集群指的是将几台服务器会集在一起，完成同一事务。而散布式是指将不同的事务散布在不同的地方，散布式中的每一个节点，都可以做集群。

散布式存储便是经过网络运用企业中的每台机器上的磁盘空间，并将这些涣散的存储资源构成一个虚拟的存储设备，数据涣散的存储在企业的各个角落。散布式存储中的每台服务器都可以处理读写恳求，因而不存在会集式存储中担任写的主机那样的人物。但在散布式存储中，有必要有一个人物来担任履行数据分配算法，这个人物可所以独立的一台服务器，也可所以集群自己选举出的一台服务器。散布式存储合适十分大规划的数据存储，事务数据量巨大的场景可以选用这种方法。常见的散布式存储比方 Hadoop(HDFS)、HBase、Elasticsearch 等。

五、产品层面

产品层面的高可用架构处理计划，根本上便是指咱们的兜底产品战略。降级/限流的战略，更多的是从后端的事务服务和架构上的规划来考虑相关处理计划。这儿说的兜底战略，也可叫做柔性降级战略，更多则是经过产品层面上来考虑。

  • 比方，当咱们的页面获取不到数据的时分，或许无法拜访的时分，要怎样友爱的告知用户，比方【稍后重试】之类的。

  • 比方 当咱们的实在的页面无法拜访的时分，那么需求产品供给一个默许页面，假如后端无法获取实在数据，那么直接烘托默许页面。

  • 比方服务器需求停机保护，那么产品层面给一个停机页面，一切用户只会弹出这个停机页面，不会恳求后端服务

  • 比方抽奖产品给一个默许兜底产品

  • …

六、运维布置层面

开发阶段-灰度发布、接口测验规划

灰度发布、接口测验、接口拨测系列规划包含但不限于：

  • 灰度发布，咱们服务发布上线的时分，要有一个灰度的进程，先灰度 1-2 个服务实例，然后逐渐放量调查，假如一切 ok，再逐渐灰度，直到一切实例发布结束

  • 接口测验，每次服务发布上线的时分，服务供给的各种接口，都要有接口测验用例，接口测验用例跑过之后，服务才干发布上线，意图是为了查看咱们对外供给的接口是否可以正常，防止服务发布上线后才发现有问题

灰度发布和接口测验，一般在大公司里边会有相关的 DevOps 流程来确保。

开发阶段-监控告警规划

监控告警的规划，在大公司来说，根本不是问题，由于必定会有比较专门一拨人去做这种基础才干的建造，会有对应的配套系统，事务开发的同学只需求装备或运用即可。那假如说公司内部没有相关基础建造，那么就需求自己别离来接入对应的系统了。

监控系统

一般在监控系统这方面的开源处理计划包含但不限于这些：

  • ELK (Elasticsearch、Logstash、Kibana) 日志搜集和剖析
    • 咱们的日志记录不能都本地存储，由于微服务化后，日志散落在许多机器上，因而有必要要有一个长途日志记录的系统，ELK 是不二人选
  • Prometheus 监控搜集
    • 可以监控各种系统层面的目标，包含自定义的一些事务目标
  • OpenTracing 散布式全链路追寻
    • 一个恳求的上下流这么多服务，怎样可以把一个恳求的上下流全部串起来，那么就要依靠 OpenTracing，可以把一个恳求下的一切链路都串起来而且有具体的记录
  • OpenTelemetry 可观测系统规范
    • 最新的规范，大一统，调集了盯梢数据（Traces），目标数据（Metrics），日志数据（Logs）来观测散布式系统情况的才干

咱们会依托开源系统进行自建或许扩展，乃至直接运用都行，然后咱们的监控的目标一般会包含：

  • 基础设施层的监控：首要是针对网络、交换机、路由器等低层基础设备，这些设备假如呈现问题，那么依托其运转的事务服务必定就无法稳定的供给服务，咱们常见的中心监控目标包含网络流量(入和出)、网络丢包情况、网络衔接数等。

  • 操作系统层的监控：这儿需求包含物理机和容器。常见的中心目标监控包含 CPU 运用率、内存占用率、磁盘 IO 和网络带宽等。

  • 应用服务层的监控：这儿的目标会比较多，中心的比方主调恳求量、被调恳求量、接口成功率、接口失败率、响应时刻（平均值、P99、P95 等）等。

  • 事务内部的自定义监控：每个事务服务自己的一些自定义的监控目标。比方电商系统这儿的：浏览、付出、发货等各种情况的事务目标

  • 端用户层的监控：前面的监控更多的都是内部系统层面的，可是用户真实拜访到页面，中心还有外网的情况，用户真实获取到数据的耗时、翻开页面的耗时等这些信息也是十分重要的，可是这个一般便是需求客户端或许前端去进行计算了。

告警系统

这些系统接入完了之后，还仅仅做到监控和计算，当呈现问题的时分，还需求进行实时告警，因而还要有一个实时告警系统，假如没有实时报警，系统运转反常后咱们就无法快速感知，这样就无法快速处理，就会给咱们的事务带来严峻毛病和灾难。告警规划需求包含：

  • 实时性：完成秒级监控；
  • 全面性：掩盖一切系统事务；
  • 实用性：预警分为多个等级，监控人员可以方便实用地依据预警严峻程度做出准确的决议计划；
  • 多样性：预警方法供给推拉模式，包含短信，邮件，可视化界面，方便监控人员及时发现问题

开发阶段-安全性、防进犯规划

安全性、防进犯规划的意图是为了防刷、防黑产、防黑客，防止被外部恶意进犯，这个一般有几个战略：

  • 在公司等级的流量进口做好一致的防刷和鉴权的才干，比方再一致接入层做好封装

  • 在事务服务内部，做好相关的事务鉴权，比方登录态信息、比方添加事务鉴权的逻辑

布置阶段-多机房布置（容灾规划）

一般的高可用战略，都是针对一个机房内来服务层面来规划的，可是假如整个机房都不行用了，比方地震、火灾、光纤挖断等。。。。那么这个情况怎样办？这就需求咱们的服务和存储都可以进行容灾了，容灾的一个常见计划便是多机房布置了。

  • 服务的多机房布置，这个比较简略，由于咱们的服务都是无情况的，因而只需姓名服务可以发现不同机房的服务，就可以完成调用，这儿需求留意的是姓名服务（或许说负载均衡服务）要可以有就近拜访的才干。

  • 存储的多机房布置，这个会比较难搞一点，由于存储是有情况的，布置在不同的机房就涉及到存储的同步和仿制问题。

条件不允许的情况下，咱们确保多机房布置事务服务就可以了。

线上运转阶段-毛病演练（混沌试验）

毛病演练在大公司是一个常见的手段；在业界，Netflix 早在 2010 年就构建了混沌试验东西 Chaos Monkey，混沌试验工程关于提高杂乱散布式系统的健壮性和可靠性发挥了重要效果。

简略的毛病演练便是模仿机房断电、断网、服务挂掉等场景，然后看咱们的整个系统运转是否正常。系统的就要参阅混沌试验工程来进行具体的规划和规划，这个是一个相对比较大的工程，效果挺好，可是需求有许多人力去开发这种基础建造。

线上运转阶段-接口拨测系列规划

接口拨测，和巡检类似，便是服务上线后，每隔一个固定时刻（比方 5s）调用后端的各种接口，假如接口反常则进行告警

针对接口拨测，一般也会有相关配套设施来供给相关的才干去完成，假如没有供给，那么咱们可以自己写一个接口拨测（巡检）的服务，定时去调用重要的接口。

七、反常应急层面

前面做了这么多保障，可是终究架不住线上的各种反常情况，假如真出问题了，让咱们的服务反常，无法供给服务后，咱们还需求最终一根救命稻草，那便是应急预案，将服务反常的丢失降低到最小。

应急预案便是咱们需求事前规划好，咱们事务系统在各个层级呈现问题后，咱们需求第一时刻怎样康复，制定好相关规则和流程，当呈现反常情况后可以按照既有的流程去履行，这样防止呈现问题后手忙脚乱导致事态扩展。

最终

  • 这篇文章首发在我微信大众号【后端系统和架构】中，点击这儿可以前往大众号查看原文链接，假如对你有帮助，欢迎前往关注，愈加方便快捷的接收最新优质文章

引荐阅览

引荐阅览我的其他文章：

  • 《高并发架构和系统规划经历》

  • 《TCP 长衔接层的规划和 在 IM 项目中实战应用》

  • 《万字解读云原生年代，怎样从 0 到 1 构建 K8s 容器渠道的 LB（Nginx）负载均衡系统》

  • 《我终于一致了团队的技能计划规划模板》