微服务不香了？单体化改造为我们节省上万核 CPU！

云

张敏2023年11月14日约 9 分钟

# 关注并星标腾讯云开发者

# 谈谈我在腾讯的架构设计经验

# 第9期 | 基于腾讯 tRPC-Go 单体化改造

微服务一直以来是服务治理的基本盘之一，落地到云原生上，往往是每个 K8s pods 部署一个服务，独立迭代、独立运维。

但是在快速部署的时候，有时候，我们可能需要一些宏服务的优势。有没有一种方法，能够 “既要又要” 呢？本文基于 tRPC-Go 服务，提出并最终实践了一种经验证可行的方法。

本文原文发布在腾讯内网平台中，随着腾讯 tRPC 框架正式开源，笔者决定将敏感信息脱敏后发布至外网，也助力 tRPC 的推广。

《腾讯开源 tRPC：多语言、高性能 RPC 开发框架》

微服务是云原生的大潮流，它的优势非常明显：

微服务大大降低了模块间的耦合。当某个模块 / 微服务需要变更时，只需要调整这个微服务即可，其他服务无感知；
微服务化使得模块的更新能够平滑过渡，避免了停机更新的问题，也适合大型团队或多个团队间合作构建；
微服务模块的输入 / 输出定义很明确，非常适合融合 DDD 理念进行设计；
问题排查时，能够快速定位出现问题的模块，对运维也很友好。

然而微服务也存在劣势：

当系统趋向复杂时，随着微服务的拆分、功能的繁杂和细化，微服务越来越多，一窥系统全貌的难度越来越大；
模块间通信通过 RPC 实现，RPC 带来了时间和网络流量的开销；
依赖于完备的服务治理体系，对小团队而言，部署成本较高；
多租户隔离部署时，运维难度也成倍增加。

我们是心悦俱乐部首页 Feeds 流推荐系统的开发团队。但我们推荐系统也接入了其他业务，比如我们在接入游戏知几项目的一个功能后，全量发布前的压测中发现 CPU 开销大到难以接受。

2.1 分析

我们的系统是简单按照 “业务 -> 分流 -> 重排 -> 精排 -> 召回” 的推荐系统微服务化部署，没有做编排化：

观察压测数据，我们会发现，在分流层前后的服务，网络开销非常大：

服务	峰值网络 IO
业务	36.4 + 1.68 = 38.1 Gbps
分流	41.0 + 40.2 = 81.2 Gbps
重排	3.14 + 40.5 = 43.6 Gbps
精排	3.01 + 2.19 = 5.20 Gbps
召回	0.849 + 1.23 = 2.08 Gbps

分流服务是推荐系统的总入口，它没有很强的业务属性，而是在整个推荐系统的前面、在业务数据的基础上，加入 A/B Test 参数，供整个推荐系统使用。所以它对于业务负载基本是透传的。

很明显，业务服务发给推荐系统的数据流量非常大，而作为透明传输业务数据的分流服务，入参需要反序列化，出参需要重新序列化，这些都是无谓的算力消耗。

从分流服务的火焰图上也可见一斑——作为主要逻辑的查询实验参数，仅占了不到 10% 的 CPU，剩下的 CPU 都花在 gc、序列化反序列化、RPC 上面：

从代码上看，占流量大头的数据结构，在整个调用链路上都是一致的，我们自然想到，省去网络开销，直接在内存里存取该多好啊。

其他内部团队其实也曾经提出一个 “单体大应用融合落地方案”，给了我们很大启发。不过，文档里面只是提出了将所有的微服务合并在一个 pod 中进行部署，服务间调用依然是 RPC 而不是内存调用。

实际上我们观察一下 tRPC 的 RPC 调用方法，可以看到所有的 RPC 调用，对 Go 业务代码来看是以一个 Go interface 的形式给出的；而实现方实现对外提供服务的方式，从业务层面也只是实现相应的 server interface 就可以。也就是说，服务的 client 端和 server 端，看到和实现的，都只是普通的 Go 函数。在此思路上，我们团队的同学在该文档的基础上，提出了一个将 RPC "mock" 成本地函数调用的方案，并由我落地验证了。

本文旨在向读者详细说明基于 tRPC 的微服务单体化方案的一种实现方法。代码改造还是有必要的，但我们的目标是尽可能减少代码改造量，避免入侵业务。

3.1 RPC 背景

以我们的重排服务为例，重排服务需要实现这样的一个 PB：

service FeedsRerank {  rpc GetFeedList (GetFeedRequest) returns (GetFeedReply) {}}

通过 tRPC 命令行工具 build 之后，会生成一个xxx.trpc.go文件，其中包含 service 接口:

type FeedsRerankService interface {  GetFeedList(ctx context.Context, req *GetFeedRequest) (*GetFeedReply, error)}

作为服务端，需要实现这个接口，并在 main 函数中调用 RegisterFeedsRerankService 注册实现, tRPC 会自动对接框架和代码实现。

同时还会生成另外一个 client 接口：

type FeedsRerankClientProxy interface {  GetFeedList(ctx context.Context, req *GetFeedRequest, opts ...client.Option) (*GetFeedReply, error)}

一般而言，任意一个 client 要调用重排服务的话，只需要 client := pb.NewFeedsRerankClientProxy()，然后就可以直接调用 GetFeedList 方法了，tRPC 帮调用方隐藏了底层 RPC 细节。对调用方而言，这就只是一个函数而已。对，函数！！！

3.2 代码改造

Client 侧

我们的思路是：作为 rerank 这个微服务，要将自己的入口映射到某处；而 client 方不要自行 new 下游的 proxy，而是从这个地方统一取（我们把这个叫做 proxy API），这样我们就可以实现了。用 Go 的语言来描述, 调用方看到的只是一个 interface, 那我们就在内存把被调用方的代码按照这个 interface 进行实现, 然后想办法让 client 端直接用上这个实现，就可以了！

考虑到绝大部分的 trpc proxy 都只是使用默认参数进行初始化即开箱即用，因此我们就将这些都统一收拢起来，构建了一个获取各种 client proxy 的 repo 仓库（比如就简单命名为 "api"），clent 方从这个仓库的 getter 函数中获取自己需要的 client，如：

    rerank := api.FeedsRerank()        rsp, err := rerank.GetFeedList(ctx, req)        // .....

Server 侧

Server 是提供服务的一侧，每个微服务，首先要把自己的业务代码完全抽出来，不要放在 main 包中——这个改造并不难。各微服务的业务逻辑，可以抽取出来称为 service 包，对外暴露一个 Register 函数，这个函数的入参中包含 trpc-go/service.Server 类型，用于调用 tRPC 服务注册函数，如重排服务：

 pb.RegisterFeedsRerankService(server, rerankImpl)

这是原本就有的常规操作。但是除此之外，还需要调用前文的 proxy API，将自己的实现 mock 一下。需要注意的是，tRPC 的 client proxy 函数参数，相比 server 侧实现的方法，多了一个 opts ...client.Option 参数。不过绝大多数情况下，我们忽略这些参数就好了。

还是以重排为例，简单用以下代码 mock 一下自身：

type rerankProxy struct {    impl *rerankImpl}
func (r *rerankProxy) GetFeedList(    ctx context.Context, req *pb.GetFeedRequest, opts ...client.Option,) (*pb.GetFeedReply, error) {    rsp := &pb.GetFeedRequest{}    err := r.impl.GetFeedList(req, rsp)    return rsp, err}
func (impl *rerankImpl) mockProxy() {    r := &rerankProxy{impl: impl}    proxyAPI.RegisterFeedsRerank(p)}

可以看到, 除了通过 rerankImpl 类型实现了作为 server 端的 FeedsRerankService 接口之外, 也通过 rerankProxy 类型实现了 client 端的 FeedsRerankClientProxy 接口。这样，当上游调用时, 统一从 proxy API 中获取 proxy 接口实现, 在微服务场景下，那么就是一个正常的 RPC 调用；但是在单体场景下，不知不觉地就只是一个内存的调用了。

main 包

我们在原有逻辑中，每一个微服务的逻辑都写在 main 包中。支持单体化的改造之后，每一个微服务的逻辑都应挪到一个非 main 包中，并且微服务依赖的各种组件尽量使用注入，而不是由微服务内部初始化。包括微服务所依赖的 client proxy 接口。

Proxy API 实现

前文提到的 Proxy API 的实现原理很简单，各 client proxy 只需要默认调用 NewXxx 函数初始化即可（比如对应前文的 NewFeedsRerankClientProxy），得益于 tRPC 的懒初始化机制，这些 Proxy 创建了之后，只要不去调用它，那么即便配置里不包含相关的 client 配置，就不会报错。因此，虽然在 Proxy API 中初始化了多个 Proxy，也不会对具体到某个微服务造成影响。

至于 mock 动作，则通过 RegisterXxxx 函数（比如前文的 RegisterFeedsRerank）实现。具体落到细节处，也只不过是一个个的私有成员变量而已。

Proxy API 的代码大致框架如下:

package proxyapi
type API interface {    FeedsRerank() pb.NewFeedsRerankClientProxy    RegisterFeedsRerank(p pb.NewFeedsRerankClientProxy)}
func DefaultAPI() API {    return defaultAPIImpl}
type apiImpl struct {    internalFeedsRerankClientProxy pb.FeedsRerankClientProxy    internalXxxxClientProxy        pb.XxxxClientProxy // 作为实例, 其他的微服务模式类似, 下同    // ...}
var _ API = (*apiImpl)(nil)var defaultAPIImpl = new()
func new() *apiImpl {    return &apiImpl{        internalFeedsRerankClientProxy: pb.NewFeedsRerankClientProxy(), // trpc 的默认 client 初始化逻辑        internalXxxxClientProxy:        pb.NewXxxxClientProxy(),        // ...    }}
func (a *apiImpl) FeedsRerank() pb.NewFeedsRerankClientProxy {    return a.internalFeedsRerankClientProxy}
func (a *apiImpl) RegisterFeedsRerank(p pb.NewFeedsRerankClientProxy) {    if p != nil {        a.internalFeedsRerankClientProxy = p    }}
// ...