如何进行逻辑思维Go语言微服务改造

共计 6713 个字符，预计需要花费 17 分钟才能阅读完成。

如何进行逻辑思维 Go 语言微服务改造，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

1. 改造的背景

得到最早的 APP 就是一个单体的 PHP 的应用，就是图中最大的黄色块，中间蓝色块代表不同模块。下面的黄色部分代表 passport 和支付系统，这个是在做得到之前就存在的系统，因为公司早期有微信里的电商业务。

后来发现有一些业务逻辑并不需要从得到走，还有一些数据格式转换的工作也不需要跟业务完全耦合，所以加了一层 PHP 的网关就是下图看到的 V3 那部分。但是这样做也有一些问题，PHP 后端是 FPM，一旦后端的接口响应较慢，就需要启动大量 FPM 保证并发访问，从而导致操作系统负载较高，从这一点上来说，使用 PHP 做这部分工作并不合适。

1.1 屋漏偏逢连夜雨

1.2 改造目标

高性能

首先是性能要高，如果你单台机器跑几十 QPS，那么堆机器也很难满足要求。

服务化

服务化实际上在故障之前就已经开始了，并且由于我们不同的业务团队已经在负责不同的业务，实际上也是需要服务化继续做下去。

资源拆分隔离

随着服务化过程，就需要对资源进行拆分，需要每个服务提供相应的接口，服务之间不能直接访问其他服务的数据库或者缓存。

高可用

当时定的目标是 99.9 的可用性。

1.3 为什么选择 Go

Go 的好处很多，最重要的还是对 PHP 程序员来说，上手更容易，而且性能好很多。

2. 改造的过程

2.1 首先有一个系统架构图

对于系统改造来说，首先需要知道，系统需要改成什么样子。因此我们需要一个架构的蓝图。上面就是我们的架构蓝图。首先需要的是一个统一对外的 API GATEWAY，图中最上层的黄色部分。中间淡紫色的部分是对外的业务服务。浅绿色部分是基础资源服务，比如音频文稿信息，加密服务。下面红色部分是支付和 passport 等公用服务，最右侧是一些通用的框架和中间件。最下层是一些基础设施。

我们的框架跟基础设施的完善和系统重构是交织进行的，不是说一开始就有一个完全没问题的设计，随着业务的改造，会有很多新的功能加进来。

2.2 框架和基础设施完善

我不讲应用系统怎么拆分，因为每个公司业务系统都不一样，我讲一下我们在框架和中间件这部分事情。

API gateway

API gateway 是我们和陈皓（著名的左耳朵耗子）团队合作研发的。他们团队对于我们成功跨年帮助很大，在此先感谢一下。

目 的限流

API gateway 主要的目的就是限流，改造过程当中，我们线上有 400 多个接口，经常加新功能。我们可以保证新接口的性能，但是总有在改造过程中疏忽的老接口，通过 API gateway 限流可以保证在流量大的时候，老接口也有部分用户可用。

升级 API

大部分的 API 升级都是跟客户端解决的，但是我们不太强制用户升级，导致线上老接口存在很长时间，我们需要在 API gateway 这一层做一些把新接口数据格式转成老接口数据格式的工作。

鉴权

在拆分服务之后，需要统一对接口进行鉴权和访问控制，业界的做法通常都是在网关这一层来做，我们也不例外。

接下来看一下 API gateway 的架构

API gateway 由一个 write 节点和多个 read 节点，节点之间通过 gossip 协议通信。每个节点最上层有一个 CLI 的命令行，可以用来调用 Gateway 的 API。下层的 HTTPServer 等都是一个 plugin，由多个 plugin 组成不同的 pipeline 来处理不同的请求。在后面我会介绍这个的设计。每个节点都有一个统计模块来做一些统计信息，这个统计信息主要是接口平均响应时间，QPS 等。修改配置之后，write 节点会把配置信息同步到 read 节点上，并且通过 model 模块持久化到本地磁盘上。

请求经过了两段 pipeline，第一段 pipeline 基于请求的 url。可以在不同的 pipeline 上面组合不同的 plugin。假设一个接口不需要限流，只需要在接口的配置里头不加 limiter plugin 就可以了。第二段 pipeline 基于后端的 Server 配置，做一些负载均衡的工作。

接下来我们看整个 API gateway 启动的流程和调度方面

启动是比较简单的，去加载 plugin，然后再去加载相应的配置文件，根据配置文件把 plugin 和 pipeline 做对应。右上角的这个调度器分为静态调度和动态调度。静态调度是假设分配 5 个 go routine 来做处理，始终都有 5 个 go routine 来处理对应的请求。动态调度器是根据请求繁忙程度，在一个 go routine 最大值和最小值之间变化。

API gateway 鉴权方面比较简单，客户端调用登录接口，passport 会把 token 和 userid，传到 API gateway，API gateway 再把相应的 token 传到这个 APP 端。客户端下次请求就拿 token 请求，如果 token 验证不过，就返回客户端。如果验证通过再调用后端不同的服务获取结果，最后返回结果给客户端。

最后再强调一下 API gateway 如何进行

我们在 API gateway 里面引入两种限流的策略

1. 滑动窗口限流

为什么会根据滑动窗口限流呢？因为线上接口太多，我们也不知道到底是限 100 好 200 好还是限 10000 好，除非每一个都进行压测。用滑动窗口来统计一个时间窗口之内，响应时间，成功和失败的数量，根绝这个统计数据对下一个时间窗口是否要进行限流做判断。

2.QPS 的限流

为什么还会留一个 QPS 的限流呢？因为要做活动，滑动窗口是一个时间窗口，做活动的时候，客户拿起手机扫二维码，流量瞬间就进来了，滑动窗口在这种情况下很难起到作用。

服务框架

目的简化应用开发服务注册发现方便配置管理服务框架的常用架构

第一种方式是做成一个库，把相关功能编译进服务本身。这里有两个问题，第一个是我们兼容好几种语言，开发量比较大。还有一个是一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。在业界来说，spring cloud，dubbo，motan 都是用这样的机制。

还有一种方案是把 Lord Balancing 的功能拿出来做成一个 agent，跟 consumer 单独跑，每次 consumer 请求的时候是通过 agent 拿到 Service Provder 的地址，然后再调用 Service Provder。好处是简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。缺点也很明显，部署比较复杂；还有可用性检测会更麻烦一点，这个 agent 也可能会挂。如果 agent 挂掉，整个服务也要摘下来。百度内部的 BNS 和 Airbnb 的 SmartStack 服务发现框架也是这种做法。由于我们内部语言较多，因此选择了第二种做法。

在 Consul 集群中，每个提供服务的节点上都要部署和运行 Consul 的 agent，所有运行 Consul agent 节点的集合构成 Consul Cluster。Consul agent 有两种运行模式：Server 和 Client。这里的 Server 和 Client 只是 Consul 集群层面的区分，与搭建在 Cluster 之上 的应用服务无关。以 Server 模式运行的 Consul agent 节点用于维护 Consul 集群的状态，官方建议每个 Consul Cluster 至少有 3 个或以上的运行在 Server mode 的 Agent，Client 节点不限。

Client 和 Server 的角色在 DDNS 是没有严格区分的，请求服务时该服务就是 Client，提供服务时候就是 Server。

NNDS 提供出来的是一个 SDK 可以很容易的集成和扩展为一个独立的服务并且集成更多的功能。采用 agent 方式，将在每一个服务器部署安装得到的 agent，支持使用 HTTP 和 grpc 进行请求。

服务完成启动并可以可以对外提供服务之后，请求 agent 的接口 v1/service/register 将其注册的进入 DDNS；

注册成功则其他客户端可以通过 DDNS 发现接口获取到该 APP 节点信息；

如果注册失败，APP 会重复尝试重新注册，重试三次失败则报警；

假设服务 A 需要请求服务 B，服务名称为 bbb，直接请求本机的 agent 接口 v1/service/getservice，获取到 bbb 的服务节点信息。

对于 agent 而言，如果服务 bbb 是第一次被请求，则会请求 Consul 集群，获取到服务 bbb 的数据之后进行本地从 cache 并对服务 bbb 的节点进行 watch 监控，并定时更新本地的 service 信息；

如果获取失败，给出原因，如果是系统错误则报警；

这是服务框架基本的接口

这个就是客户端调用的封装，可以同时支持 HTTP 和 JRTC，在这个之后我们还做了 RBAC 的权限控制，我们希望能调哪些服务都是可以做权限控制的。

多机缓存

client 请求到 server，server 先在缓存里找，找到就返回，没有就数据库找，如果找到就回设到缓存然后返回客户端。这里是一个比较简单的模型。只有一级 cache，但是一级 cache 有可能不够用，比如说压测的时候我们发现，一个 redis 在我们的业务情况下支撑到接口的 QPS 就是一万左右，QPS 高一点怎么办呢？我们引入多级缓存。

越靠近上面的缓存就越小，一级就是服务 local cache，如果命中就返回数据，如果没有就去 L1 查，如果查到就更新 local cache, 并且返回数据。如果 L1 级也没有就去

L2 级查，如果查到数据就更新 L1 cache/local cache，并返回数据

我们上面看到的是针对单条内容本身的缓存，在整个栈上来看，gateway 也可以缓存一部分数据，不用请求透穿。这个 5 的虚线是什么意思呢？因为数据修改后需要更新，在应用层做有时候会有失败，所以读取数据库 binlog 来补漏，减少数据不一致的情况。

我一直觉得如果有泛型代码好写很多，没有泛型框架里面就要大量的反射来代替泛型。

php with redis cache

go with redis cache

go with big cache

go with object cache

免费专栏首页

100+

600+

2000+

12000+

付费专栏首页

200+

900+

2400+

14000+

多级缓存开始加了之后整个性能的对比，最早 PHP 是一两百，改成 Go 之后，也不强多少，后面 Go 和 big cache 的大概到两千左右的，但是有一些问题，后面会讲当问题。后面基于对象的 cache，把对象缓存起来，我们跑测试的机器是在八核，达到这样的结果还可以接受。

熔断降级

接口同时请求内部服务，service7、8、9 不一样，service5 是挂掉的状态，但是对外的服务还在每次调用，我们需要减少调用，让 service5 恢复过来。

打开的状态下，失败达到一定的阈值就关起来，等熔断的窗口结束，达到一个半开的状态接受一部分的请求。如果失败的阈值很高就回到关闭的状态。这个统计的做法就是我们之前提到的滑动窗口算法。

这里是移植了 JAVA hystrix 的库，JAVA 里面有很多做得很不错的框架和库，值得我们借鉴。

3. 经验总结

3.1 通用基础库非常重要

刚才讲的性能提升部分，QPS 从 600 提升到 12000，我们只用了一天，主要原因就在于我们通过基础库做了大量优化，而且基础库做的提升，所有服务都会受益。

3.2 善用工具

•generate + framework 提升开发效率

•pprof+trace+go-torch 确定性能问题

比如说我们大量的用 generate + framework，通过 generate 和模板生成很多代码。查性能的时候，pprof+trace+go-torch 可以帮你节省很多工作。Go-torch 是做火焰图的，Go 新版本已经内置了火焰图的功能。

这是根据我们的表结构生成相应的数据库访问代码，多级缓存是把所有的访问都要抽象成 K -V，K-LIST 等访问模式，每次这么做的时候手动去写太繁琐，我们就做了一个工具，你用哪一个表，工具就生成好，你只需要把它组装一下。

定位性能问题的时候，火焰图一定要用

比如说定位性能问题就要看最长的地方在哪里，着力优化这个热点的 code，压测的时候发现，大家 600、900 的火火焰图这里有问题，优化完成后如下图

3.3 其他经验总结

针对热点代码做优化

合理复用对象

尽量避免反射

合理的序列化和反序列化方式

GC 开销

举例来说我们之前有一个服务会从缓存里面拿到很多 ID 的 list，数据是存成 json 格式 [1,2,3] 这样，发现 json 的序列化和反序列化性能开销非常大，基本上会占到 50% 以上的开销。早上滴滴讲他们的 json 库，可以提升 10 倍性能，实际上在我们的场景下提升不了那么多，大概只能提升一倍，当然提升一倍也是很大的提升（因为你只用改一行代码就能提升这么多）。其次 json 饭序列化导致的 GC 的问题也很厉害，最猛的时候能够达到 20%CPU，即使是在 Go 的算法也做得很不错的情况下。最终解决的办法就是在这里引入 PB 替代 json。PB 反序列化性能（在我们的情况下）确实比 json 好 10 倍，并且分配的临时对象少多了，从而也降低了 GC 开销。

为什么要避免反射呢？我们在本地建了 local cache，缓存整个对象就要求你不能在缓存之外修改这个对象，但是实际业务上有这个需求。我们出现过这样的情况后就用反射来做 deep copy。JAVA 反射还可以用，原因是 jvm 会将反射代码生成 JAVA 代码，实际上调用的是生成的代码。但是在 Go 里面不是，本来 Go 的性能是和 C 接近的，大量用了反射之后，性能就跟 python 接近额。后来我们就定义一个 cloneable 的接口，让程序员手动来做这个 clone 工作。

压力测试

我们主要用的就是 ab 和 Siege，这两个通常是针对单个系统的压力测试。实际上用户在使用的过程当中，调用链上每一个地方都可能出现问题。所以在微服务的情况下，单个系统的压力测试，虽然很重要，但是不足以完全消除我们系统的所有问题。

举一个例子，跨年的时候罗老板要送东西，首先要领东西，领东西是一个接口，接下来通常用户会再刷一下已购列表看看在不在，最后再确认一下他领到的东西对不对。因此你需要对整个链路进行压测，不能只压测一下领取接口，这样可能是有问题的。假设你已购列表接口比较慢，用户领了以后就再刷一下看一看有没有，没有的情况下，一般用户会持续的刷，导致越慢的接口越容易成为瓶颈。因此需要合理的规划访问路径，对链路上的所有服务进行压测，不能只关注一个服务。

我们直接买了阿里云 PTS 的服务，他们做法就是在 CDN 节点上模拟请求，可以对整个访问路径进行模拟。

4. 正在做什么

4.1 分库分表和分布式事务

选择一个数据库跟你公司相关的运维是相关的。分布式事务在我这里比较重要，我们有很多购买的环节，一旦拆了微服务之后，只要有一个地方错，就需要对整个进行回滚。我们现在的做法是手动控制，但是随着你后面的业务越来越多，不可能所有的都手动控制，这时就需要有一个分布式事务框架，所以我们现在基于 TCC 的方式正在做自己的分布式事务框架。

分库分表也是一个硬性的需求，我们在这里暂时没有上 tidb 的原因主要是 DBA 团队对 tidb 不熟悉。我们之前的分库分表也是程序员自己来处理，现在正在做一个框架能同时支持分库和分表，同时支持 hash 和 range 两种方式。

4.2API gateway

API gateway 上面有很多事情可以做，我们在熔断和降级做了一些事情。现在一些 Service mesh 做的很多事情是把很多工作放在内部 API gateway 上，是做控制的事情，实际上不应该是业务逻辑关心的事情。我们也在考虑怎么把 API gateway 和 SM 做结合。

4.3 APM

拆了微服务之后，最大的问题是不方便定位具体问题在哪里。我们有时候出问题，我叫好几个人看看各自负责的系统对不对，大家人肉看出问题的地方在哪，这是个比较蛋疼的做法。因入 APM+tracing 之后，就方便我们来追踪问题在哪里。

4.4 容器化

我们现在的线上环境，还是在用虚拟机。仿真环境和测试环境已经是容器，使用容器有很多好处，我就不一一列举了。这也是我们下半年要做的重点工作。

4.5 缓存服务化

我们现在有多级缓存的实现，但是多级缓存还是一个库的形式来实现的。如果把缓存抽出来，使用 memcached 或者 redis 的协议，抽出来成为一个独立的服务。后面的业务系统迭代的时候不用关心缓存本身的扩容缩容策略。

关于如何进行逻辑思维 Go 语言微服务改造问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。