转载

探探如何三个月完成微服务改造,以及踩过的“坑”

在探探创建之初,单体架构很好满足了业务的发展与迭代,但随着业务和流量的快速增长,传统的单体架构受到了巨大的挑战,从而需要进行微服务重构以满足开发及公司发展需求。本文主要分享探探微服务架构演进的过程、问题、解决方法,以及微服务架构体系建设、思考及落地。

探探如何三个月完成微服务改造,以及踩过的“坑”

本文字数: 5610字

精读时间: 10分钟

也可在5分钟内完成速读

00

前言

大家好! 我叫彭亮,主要跟大家分享一下探探微服务架构的演进过程,主要分四个部分:

第一,我们碰到了哪些问题,为什么需要微服务;

第二,对微服务的认知;

第三,微服务实施的过程;

第四,微服务实施过程中遇到的关于 Go 的坑和解决办法。

01

探探为什么需要微服务

主要是技术带宽的限制,我们产品的需求非常多,但是开发的进度跟不上,并且代码的耦合度太高,职能划分不是很清晰,引用新的框架跟技术也不是很方便;因为都是单体应用,所以部署的时间非常长。我们几十上百台机器上部署一个服务,基本是很久的过程,每个人都在排队部署,出现一个小的Bug对整个的QPS影响非常大。

       探探如何三个月完成微服务改造,以及踩过的“坑”        

后端服务架构

这是前期的架构,大家可以看到绿色的部分是gateway,蓝色的部分是服务。

探探如何三个月完成微服务改造,以及踩过的“坑”

这些是之前一个大的单体应用,它做了很多事情,类似于滑动、聊天、朋友圈,都被包括在一个服务里面,而且这些服务都是共用DB的。我们有很多DB,这些DB每个服务都可以访问,包括BI和数据仓库的同步,这样其实有很多的问题,比如其他的服务写了一个很慢的SQL, 会影响整个的db性能,也可能导致db直接崩溃。

02

什么是微服务

微服务定义

微服务架构很多人都谈过,但到底怎么样拆分?到底一个微服务有多微?这里引用敏捷开发专家Martin Fowler的对微服务的定义,我觉得可以分为三个部分:

一、职责单一,一个微服务只需要做一件事情。

二、服务是自治的,可以独立开发、独立部署,可以有自己的技术栈。

三、最终目的是实现敏捷开发。  

探探如何三个月完成微服务改造,以及踩过的“坑”        

微服务不是银弹

当然微服务也有很多的问题,比如开发过程中会变得更复杂,以前的单体应用是一个函数一个调用,现在一个请求都是变成一个rpc,链路很长,开发成本也很高,有很多的组件和应用接口,每个组之间都要进行协调过程,沟通成本非常高。测试也更加复杂,环境更加脆弱,依赖不同的基础设施,每个基础设施有不同的特性,如果基础设施出问题的话,对我们来讲是不可用的状态。工作量也大了很多,复杂度也会受影响。特别是服务高可用,如果一个请求经过十个服务,每个服务原本都是4个9的可用性,这个请求可能变成3个9了。

探探如何三个月完成微服务改造,以及踩过的“坑”

03

如何“微”服务

我们是怎么实施微服务?

依据组织架构和团队职能

我们实现微服务过程是非常精彩的。去年年初的时候,探探后端大概80%到90%都是新人,来自不同的技术栈,我们仅仅用了3个月的时间,把整个的后台的代码全部推倒重写。

首先,对团队的职能进行划分,每个业务的垂直领域由一个团队负责,虽然里面有多个微服务,其实大家都不需要关心,只要把相关接口暴露出来就可以了。

探探如何三个月完成微服务改造,以及踩过的“坑”      

业务梳理,边界划分

其次,对业务进行了梳理。上面是API层,主要是外部服务的调用和第三方回调;中间是业务层,主要功能是业务逻辑的开发;下面是基础服务层,主要是基础化的数据;最下面是业务扩展层,类似于推送服务,他们都是通过grpc调用基础服务层对数据访问和修改。一个领域的数据修改会写到kafka集群里去,我们称之为DCL,这类似于一个领域事件。

探探如何三个月完成微服务改造,以及踩过的“坑”      

服务通讯

服务的通讯选的是gRPC,主要考虑gRPC的Streaming功能。

探探如何三个月完成微服务改造,以及踩过的“坑”

还有DCL,这是我们自己定义的名字,全称是Domain Commit log,基于数据表的变更,将这些变更写入到kafka集群中。它的主要功能是解耦,上游跟下游的服务进行异步解耦,达到最终一致性。一个服务请求,在写多个表的情况下,如果要保证强一致性,那么就要做分布式事务,这样开发就会变得复杂,也可能会导致整个链路延迟变高。我们会使用DCL进行解耦。比如现在有两个DB,一个请求修改两个DB,两个worker消费同一个topic再写入到这两个DB里去,保证幂等,这样就能做到最终一致性。然后是事件溯源,为什么需要这个东西?在DB里存储的的数据和状态都是最终态的,没有办法进行溯源,无法知道数据变更的历史版本信息,我们通过DCL就可以实现溯源的动作。

探探如何三个月完成微服务改造,以及踩过的“坑”      

DCL的产生,有两种方式:双写和CDC。双写主要是一致性的问题,如果写DB成功了,写kafka不成功,数据就不一致,如果要做到一致就需要分布式事务,这样分布式事务的延时会增加,复杂度也会增高。但是我们为什么没有选择CDC呢?我们为了降低db复制延迟,基本用的都是物理复制,而不是用逻辑复制的方式,所以就没有办法进行数据捕获。(我们的业务)表变更比较频繁,如果表总是变更,导致捕获程序不断变更的话,处理过程相对比较麻烦。我们毕竟是做互联网不是做金融,对一致性要求没有那么高,权衡之后,还是采用双写的方案。

探探如何三个月完成微服务改造,以及踩过的“坑”      

链路追踪    

大家可以看到在一个请求过来,会形成一个TraceID和SpanID,调用chat服务的话,将TraceID和SpanID传过去,chat服务会自己生成一个新的SpanID,再一层一层传递下去,包括DCL和Push。如果一个请求过来,就会通过TraceID把整个链路串联起来,TraceID和服务的Span等信息都会传递给日志中心。这样在日志中心就可以通过一个TraceID将请求经过的所有服务的日志都串联起来了。

探探如何三个月完成微服务改造,以及踩过的“坑”      

进程内上下文

进程内上下文的传递,一般有两种方案。一是接口变更,Context传递,这种方式对代码侵入比较高;需要Context的每个接口都得变。二是goroutine的局部存储,这个方法比较hack,如果你用了这个方法,你的Go 版本升级,可能会遇到一定的麻烦。Go官方也没有提供一个方案做goroutine局部存储,其也建议在函数参数中传递context的方式来达到这种目的。最终我们认为长痛不如短痛,还是采用更改接口的方式。

探探如何三个月完成微服务改造,以及踩过的“坑”      

进程间上下文

进程间上下文传递,我们在middleware中处理了RPC和DCL的相关逻辑,这个对业务是透明的,业务开发人员感知不到传递了这些信息。

探探如何三个月完成微服务改造,以及踩过的“坑”      

链路分析

我参考了几个开源的APM组件,最终还是使用采用了jaeger方案,它是Uber开源的链路追踪工具。它的主要原理是把Trace信息打到Agent上去,做一个聚合,收集到数据收集器,然后写入DB。然后会跑一个SparkJobs脚本,分析服务的依赖和流量的来源。

  探探如何三个月完成微服务改造,以及踩过的“坑”      

通过服务链路,我们可以知道一个请求经过多少服务,请求时间的长短,同时也可以知道它做了哪些具体的操作,这样就可以对请求进行性能优化。

探探如何三个月完成微服务改造,以及踩过的“坑”      

服务的依赖,这里可以看到,左边就是服务依赖分析,可以看到这个服务调用了哪些服务以及哪些服务调用了它。

jaeger原生的UI只提供了服务级别的流量情况,我们自己修改了spark以及UI,增加了API层面的依赖和流量分析。

可以看到右边的grpc服务的90%的数据流量是来自于这个Http的服务,其中有47%的流量调用了gRPC的这个接口,这样子你会对一些请求进行优化。同时,我会很清楚的知道这个服务有多少的流量,是来自于哪个服务的哪个接口以及调用了这个服务的哪个接口。

探探如何三个月完成微服务改造,以及踩过的“坑”      

高可用

APP流量会经过API Gateway,会做一些鉴权等安全性验证,也充当着LB的角色,包括健康检查、限流、熔断。限流是通过Redis实现的一个简单的分布式限流,它会对每一个用户进行限流的动作,再去根据每一个API进行限流动作。健康检查,如果API gateway发现这个服务已经故障的,会把它踢出去。一个请求调到用户服务集群,集群会对每一个服务进行限流,然后会调用User服务,失败的话会重试。请求失败次数会被监控、日志系统捕获到,最后对数据进行聚合动作,聚合结果会产生报警,推送给TSP,打电话或者其他方式通知给服务负责人,如果服务负责人不进行ACK的话,会继续往上一级通知。最后可以通过降级接口对服务降级,这个降级只是提供一个flag,具体的逻辑得由业务实现。

    探探如何三个月完成微服务改造,以及踩过的“坑”      

对于高可用,大家实现可能都大同小异,我就不讲具体的实现了,就讲我们一个非常核心的业务踩过的一个坑。刚开始我们做的时候比较好,因为很多东西对业务自己是有保障。业务开发的时候没有对参数进行校验,就往DB上传,导致db driver就开始报错,报这个参数不正确,业务开发也没有对错误的信息进行校验,直接把它传给熔断器,所以把整个DB给熔断了。

探探如何三个月完成微服务改造,以及踩过的“坑”      

AB 测试

微服务前我们做一个测试很方便的,直接拉一个分支做ab修改,然后部署到ab集群,在将流量路由到ab集群。做了微服务之后,包括同步、异步,都得把信息传递下去,我们通过网关层对流量做了染色,将上下文信息一层一层的传下去,这样下游的服务就知道这个请求来自于某个ab了。这样有一个小问题,刚才说了,请求产生的事件会写DCL,因为AB有可能会改DCL结构,会导致我们的服务都跟着改,如果不跟着改,AB改动点就不知道了。这个我们后续会优化。

探探如何三个月完成微服务改造,以及踩过的“坑”      

CI&CD

CI&CD我们做的还不错,git push会触发gitlab CI,然后会启动pipeline,pipeline对代码进行静态检查,以及单元测试和集成测试,最终会部署到相应的环境中。静态代码检查和测试的结果,会推送到sonar平台,然后我们会知道代码存在着多少的BUG,代码质量如何,测试的覆盖率等等。

探探如何三个月完成微服务改造,以及踩过的“坑”      

重复性工作

我们在做微服务的时候很多工作都是重复性的,包括一些初始化工作,Client跟server的构造过程,还有测试的编写,包括部署的脚本,它们其实都是一样的。于是我们在做微服务的过程中,做了一个代码生成器,它定义了服务具有哪些特性,http还是rpc,哪些接口,需要哪些东西,我们可以通过工具生成相关的代码。刚开始做微服务的时候这个工具还是挺有用的,服务数量比较多,每个人都做同样的工作,避免这些重复工作。但是到了后面,我们的微服务数量没有那么多,维护这个东西比较麻烦。而且如果改动某一个微服务框架,每改一个地方,代码生成器也得跟着改。

探探如何三个月完成微服务改造,以及踩过的“坑”      

探探如何三个月完成微服务改造,以及踩过的“坑”

04

Go 和微服务

到这里整个微服务的重构过程就结束了,重构过程用了不到3个月,而且,参与重构的同学80到90%都是新人且来自于不同技术栈。我们在短短三个月时间能把这个东西重构,这个跟技术人员的技术功底及项目管理较好之外最大的原因还是Go本身的特性——上手比较简单。如果你之前做C++的话,我估计最多两天就可以写代码了。如果今天用的是Java,我觉得重构的过程不可能在3个月内做完,且上线时候也没有出现任何的故障。

Context

我主要讲下 Context 和 pprof 的使用经验和遇到的坑。

第一个Context。一个流量请求从A服务到B服务,B 服务到 C 服务。B服务开启一个 goroutine 请求D服务,如果这个时候C服务响应了B服务,B又响应了A,意味着请求已经结束了,B就会把goroutine传递 Context Cancel掉,然后B 服务产生的 goroutine 会传递 RST 帧给服务D,服务 D 会把请求Cancel 掉。这个时候会有三种情况,第一种服务请求已经成功完成,这个时候不希望把它Cancel掉。第二种情况请求超时(C 超时),你其实想把D Cancel掉。还有一种,C 报错,需要把 D Cancel 掉。对于这三种情况,我们之前也进行了简单培训,但是没有引起很多其他技术栈同学的重视。所以做Go的同学有一部分没有踩这个坑,但是其他的同学基本踩了这个坑。

探探如何三个月完成微服务改造,以及踩过的“坑”

为了解决这些问题,我们会做类似于把Context进行派生或繁衍的工作,会把cancel和 deadline 移除掉,这种时候C服务不管成不成功,都会让B服务调成功。还有把deadline传递下去,这种情况类似于C服务如果成功了,不需要特殊处理。

探探如何三个月完成微服务改造,以及踩过的“坑”

pprof

这有一个微服务的典型案例,案例中我们是如何通过pprof发现活锁的过程的。当时有一个Push的服务,作用很简单——消费 DCL,调用第三方的Http2.0服务进行消息推送。在这个过程中我们对Push服务并发做了限制,最高的限制是100,(看图可以发现)流量在这个时候并发已经达到最高,但可用的QPS却是0。不知道什么原因,这个问题持续了好几次,第一次没有太多重视,就给第三方服务沟通了下,他们说刚才改了一个东西,然后马上回滚。那我们就认为是第三方厂商的问题了,直到再次出现的时候,我们觉得这个事情不正常了,但是事情已经发生了,没有什么现场数据可参考的。我们每一个服务都有提供一个debug的接口,通过这个接口可以获取 goroutine 的调用栈信息,于是我们就写了一个脚本,每隔两三分钟会拉取堆栈信息,拉完之后我们才发现问题不是我们想象的那样子的。

探探如何三个月完成微服务改造,以及踩过的“坑”

大家可以看一下堆栈信息,(第一个红色箭头)这个地方是一个goroutine获得锁,但是 IO wait 持续了五分钟。另一些 goroutine 也在等待锁,也等了五分钟。从堆栈信息可以看出,这个goroutine已经发出请求了,并且已经超时了,需要要把它reset掉。stream的 reset必须进行加锁的过程,系统会调用write,write 会返回EAGAIN。Go 的 IO 层运用epoll边缘触发的方式,返回EAGAIN就表明不可以写入了,需要等待epoll的通知。这个连接等了很久,持续了五分钟,肯定是出问题了。

  探探如何三个月完成微服务改造,以及踩过的“坑”

当时我大概总结了可能是这样的原因:首先,可能是网络不稳定导致丢包。 然后Http2.0 Client发现超时,就会cancel掉超时的请求,cancel需要给 connection 加锁,发送Reset帧。之后会调用系统调用write,write返回EAGAIN,Client开始等待epoll“可写”通知。而且,Go的http客户端的Transport维护了一个连接池,发送请求时候会遍历连接池中连接是否可用,判断是否可用要加锁,而刚好步骤1中的连接一直在等待epoll通知,无法释放锁,导致其他http client一直拿不到锁。之后,http 超时时间并没有应用到 io 层,导致步骤 3 中的连接开始不断重传,直到连接断开。

探探如何三个月完成微服务改造,以及踩过的“坑”                 探探如何三个月完成微服务改造,以及踩过的“坑”

之后,我们当时修改 RTO 参数来验证上面的分析是否正确。

探探如何三个月完成微服务改造,以及踩过的“坑”

后来,我在网上查了一下,发现Go本身就有这个问题,别人也提过相关的 issue。刚刚分享了两个案例,通过Context踩了哪些坑,epoll解决哪些问题,希望对大家有所帮助。我的分享大概就到这里,大家看到我们微服务的架构跟微服务治理,相对一些大厂处于比较初级的阶段,这也意味着我们还有很多的事情可以做。

最后,我们探探在招Go的工程师,大家如果感兴趣的话可以聊一聊。谢谢大家!

重磅活动预告

Gopher Meetup Plus 深圳站即将开启。来自腾讯、华为云、OPPO、广发证券、平安科技的超豪华讲师阵容将带来 Go 开发领域的一线实践经验分享,更有 Asta 现场空降,尽在1月4日,腾讯大厦!

报名请戳: 阅读原文

探探如何三个月完成微服务改造,以及踩过的“坑”

欢迎联系 GoCN

国内最具规模和生命力的 

Go 开发者社区

讲师

GopherMeetup GopherChina 演讲

探探如何三个月完成微服务改造,以及踩过的“坑”
探探如何三个月完成微服务改造,以及踩过的“坑”
探探如何三个月完成微服务改造,以及踩过的“坑”

投稿

探探如何三个月完成微服务改造,以及踩过的“坑”

展示个人/团队原创文章

聪明又努力的 Gopher 们,你 “在看” 我吗?

探探如何三个月完成微服务改造,以及踩过的“坑”

原文  http://mp.weixin.qq.com/s?__biz=MjM5OTcxMzE0MQ==&mid=2653373500&idx=1&sn=2413c3cd6cae73306c4debbdd5884ba3
正文到此结束
Loading...