Construct公司 从 0 到 1 基于 Kitex+Istio 的微服务系统建设

本文根据 2024 年 5 月 25 日在上海举办的“云原生✖️AI 时代的微服务架构与技术实践”CloudWeGo 技术沙龙上海站活动中，Construct 服务端总监 Jason 的演讲《从 0 到 1 基于 Kitex + Istio 的微服务系统建设》整理而来。

在微服务架构的浪潮中，企业面临着从单体应用到分布式系统的转型挑战。本文以 Construct 公司为例，探讨其如何利用 CloudWeGo 框架和 Istio 服务网格，从零开始构建起一个高效、稳定的微服务系统。

关于 Construct

Construct Tech（肯斯爪特），成立于 2019 年，目前旗下 Litmatch 等产品，已覆盖海外十几个国家，并处于各国社交榜前 10 的位置，每月数千万用户使用。

一、从 0 到 1 的微服务系统建设

1. 服务端架构的演进

服务端架构的演进反映了互联网业务从简单到复杂的发展需求。Construct 公司见证了从单体架构，再到微服务架构的服务注册与发现机制，最终到服务网格（Service Mesh）的演进。

在互联网的早期阶段，应用相对简单，许多人可能还记得那个时代——个人站长主导的时期。那时的系统架构具有一种烟囱式结构，这种结构从上至下垂直延伸，简单直观，易于理解和使用。数据共享主要通过底层数据库实现。

随着业务需求的增长和互联网的快速发展，传统的烟囱式架构开始显得力不从心。为了解决这个问题，SOA 架构（Service Oriented Architecture）应运而生。SOA 引入了抽象层，以促进服务的更好复用，核心围绕着服务的解耦和服务总线的概念。服务总线作为通信的中介，使得服务调用方和服务提供方能够相互独立。然而，随着业务量的激增，服务总线逐渐成为系统的性能瓶颈。例如，当每秒查询率（QPS）飙升，用户数量大幅增长时，服务总线的任何故障都可能导致整个服务系统的瘫痪，这无疑是一场噩梦。

为了应对这一挑战，微服务架构应运而生。它进一步细化了服务的拆分，摒弃了中心化服务总线的概念，转而采用服务注册和发现机制来管理服务间的调用。这样，服务提供者和消费者可以通过注册中心相互发现并建立联系，有效解决了依赖问题。

在微服务架构的基础上，进一步发展出了服务网格（Service Mesh）架构，例如基于 Istio 的实现。服务网格进一步抽象了服务间的通信、注册和依赖关系，实现了语言无关性，使得不同编程语言编写的服务能够在同一架构下无缝交互和通信。这种解耦合的方法为多语言环境下的企业提供了更大的灵活性和扩展性。

2. 背景、约束与技术选型

作为一家拥有多款海外社交产品的公司，Construct 公司需要处理数千万月活用户的数据。面对业务的全球化和复杂化，公司决定采用微服务架构来提升系统的灵活性和可维护性。

今天，我们主要讨论的是我们公司从单体架构向服务网格（Service Mesh）架构的转型，这一转型是基于 Istio 实现的。接下来，我将分享我们转型时面临的背景和约束条件。

在我们着手构建新的微服务架构之前，公司已经拥有了一个基于 Python 的成熟单体架构。面对这一现实，我们需要解决的一个关键问题是如何确保新系统与现有系统的无缝交互和兼容性。这不仅是一个技术挑战，更是我们必须达成的硬性目标。通过深入分析，我们决定采用单向依赖的方法来简化集成过程。在接下来的架构演示中，我将详细阐述这一点。

接下来是我们的技术选型问题。面对众多的微服务框架，我们经过深思熟虑，最终将选择范围缩小到了两种：广泛使用的 gRPC 和新兴的 Kitex。尽管 gRPC 因其流行度和长时间的市场验证而备受关注，但我们最终选择了 Kitex。这一决策基于几个核心因素：Kitex 的易用性、高性能，