Go微服务--常见的微服务框架

近几年诞生了很多微服务框架，比如JAVA的Spring Cloud、Dubbo;Golang的GoKit和GoMicro以及NodeJs的Seneca。几乎每种主流语言都有其对应的微服务框架。

Go在微服务框架中有其独特的优势，至于优势在哪，自行google。

1、GoKit框架

这是一个工具包的集合，可以帮助攻城狮构建强大、可靠和可维护的微服务。提供了用于实现系统监控和弹性模式组件的库，例如日志、跟踪、限流、熔断等。

基于这个框架的应用程序架构由三个主要的部分组成：

传输层：用于网络通信，服务通常使用HTTP或者gRPC等网络传输协议，或者使用NATS等发布订阅系统相互通信。

接口层：是服务器和客户端的基本构建块。每个对外提供的接口方法都会定义为一个Endpoint，一遍在服务器和客户端之间进行网络通信，每个端点使用传输层通过HTTP或gRPC等具体通信模式对外提供服务

服务成：具体的业务逻辑实现

2、GoMicro框架

这是一个基于Go语言实现的插件化RPC微服务框架。提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制，尝试简化分布式系统之间的通信，让开发者更专注于自身业务逻辑的开发。

GoMicro的设计哲学是可插拔的架构理念，提供了可快速构建系统的组件，并且可以根据自身的需求对GoMicro提供的默认实现进行定制。所有插件都可在仓库githubcom/micro/go-plugins 中找到。

之前写的同步发送通知随着业务量的增长，已经不再适用，所以快速实现一个基本的rq队列+grpc的方式来投递通知数据并交给rq的worker去调用grpc的服务。

但是之前调用的地方太多了，所以最好还是以patch的方式去修改

原有的结构大致为图1所示

首先flask调用grpc再由grpc请求微信服务器发送消息，然后由微信响应请求后返回通知结果给grpc，grpc再返回结果给flask最终返回给客户端，所以除非等到grpc返回调用结果，否则将会一直阻塞

现在则为

这里暂时只创建一个队列去分发所有类型的通知所以message的格式需要固定

{"method":"method_name", "data":{}} ，客户端调用publish传入对应的参数即可

给标题后面加了个（1），我知道这玩意儿很快就会还要修改

可能看到这里就会有同学问了，为啥不new一个thread去执行嘞？

当TIME_WAIT超过linux系统tw数量的阀值(可用数量不会大于65535)，系统会把多余的time-wait socket 删除掉，并且显示警告信息，如果是NAT网络环境又存在大量访问，会产生各种连接不稳定断开的情况，从而影响了服务的稳定性。

一、状态的产生

要解决TIME_WAIT状态过多的问题，先来研究下TIME_WAIT状态的产生，下面是TCP连接断开时的四次挥手状态转换图，说明一点，途中显示的是客户端主动断开连接，tcp连接也可以由服务器端主动断开连接。我们先来描述一下断开的状态：

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命,RFC规定一个MSL为2min，linux中一般设置为30s）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

可以看到TIME_WAIT状态产生是在tcp连接主动关闭的一端产生的正常tcp状态，超过两个MSL之后，就会关闭，释放占用的端口。基于以上的分析我们可以推断，在我们的应用中产生大量TIME_WAIT状态的根本原因是频繁创建断开连接TCP连接。要解决TIME_WATIT状态过多的问题，就要分析我们的应用把频繁创建的短连接改为长连接。

二、常见的短连接产生的场景

1服务连接服务

后台业务服务器，通常需要调用redis、mysql以及其他http服务和grpc服务，在服务相互调用中，如果使用的是短连接，高并发时就会产生大量TIME_WAIT，如何解决呢？一般情况下，redis等客户端会有连接池，我们要做的是设置好相关的连接服用参数，一般会有连接数、连接重用时间、连接空闲数等。所以在应用中通过设置合理的连接池参数可以避免TIME_WAIT状态过多的问题：

1检查http连接池

2检查grpc连接池

3检查redis连接池

4检查mysql连接池

我们来查看一个mysql连接池配置信息，最大连接数100，最大空闲连接数10，测试的并发数50，产生的效果如下：

可以看到TIME_WAIT状态快速上升，我们查看redis客户端的连接情况：

{MaxOpenConnections:100 OpenConnections:1 InUse:0 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:0 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:17 InUse:15 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:48 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:44 Idle:7 WaitCount:0 WaitDuration:0s MaxIdleClosed:82 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:90 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:126 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:49 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:131 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:181 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:233 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:240 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:46 InUse:38 Idle:8 WaitCount:0 WaitDuration:0s MaxIdleClosed:296 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:313 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:363 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:409 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:48 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:438 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:49 InUse:49 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:494 MaxLifetimeClosed:0}

分析发现MaxIdleClosed数据持续上升，此为mysql客户端连接池配置不合理产生大量TIME_WAIT状态的例子

2网络抖动

      网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接。同样网络情况不好并且无TIME_WAIT等待，关闭连接后无新连接，当接收到被动方重传或延迟的FIN包后，会给被动方回一个RST包，可能会影响被动方其它的服务连接。

网络抖动问题比较好排查，直接使用ping命令可以观察到。

在CoreDNS有及部分可以配置。

首先，确定哪些插件被编译进CoreDNS。我们提供的编译后的二进制可执行包 （binaries）已经包含了所有的插件，列在 plugincfg 。增加和删除都很 easy ，但是需要对CoreDNS重新编译。

大多数用户使用文件 Corefile 来配置 CoreDNS。当 CoreDNS 启动的时候，如果 -conf flag 没有被配置，就会在当前目录查找 Corefile 文件。

文件包含了一个或者多个服务器块 (Server Blocks)。每个服务器块列出了一个或多个插件。那些插件也可以在后面使用指令配置。

在Corefile 文件中，插件的顺序不决定插件链的顺序。 插件执行的顺序，配置在文件 plugincfg 中。

Corefile 文件的备注以 # 开头。行的其他部分会被识别为备注。

CoreDNS 在配置中支持环境变量。

环境变量可以被使用在任何地方。语法是 {$ENV_VAR} ( Windows-类型的语法 {%ENV_VAR%} 也是支持的)。CoreDNS 会在解析Corefile的时候替换这些变量内容。

参考 import plugin。

这个插件有些特殊，可以被用在Corefile的任何地方。

一个很特殊的可导入文件是 snippet 。一个 snippet 通过命名一个块（block）的特殊语法来定义。名字需要被放到圆括号内: (name) 。然后，它就可以随着导入插件放置到配置文件的任何地方了。

每个服务器块（Server Block）以server应该伺候的zones开头。在zone名字或者zone列表名（以空格分隔）之后，一个服务器块以大括号作为开头和结束。

如下的服务器块定义了一个 server，负责root zone: 下所有的zones； 基本上，这个 server 应该处理所有的查询：

服务器块（Server blocks）还可以指定监听端口。默认端口是 53 (DNS 服务标准端口)。指定端口，以冒号作为分隔符在zone后列出端口号。

如下的 Corefile 指示 CoreDNS 创建一个 Server ， 监控端口 1053：

给服务器块定义一个zone，但是这个zone已经被配置到一台服务器上，并且已经运行了，运行在同一个端口。Corefile 会在启动的时候报错：

变更第二个端口为 1055 可以让这两个服务器块变成两个不同的服务器。

当前 CoreDNS 接受4种协议: DNS, DNS over TLS (DoT), DNS over HTTP/2 (DoH)

and DNS over gRPC。可以通过在服务器配置文件，在zone 前加个前缀来指定服务器接收哪种协议。

每个服务器块都定义了一系列插件。最简单的方式，就是在服务器块内添加插件的名字：

插件 chaos 让 CoreDNS 以 CH class 应答查询 - 在确认服务器的时候很有用。通过如上配置，CoreDNS 会在收到请求后，应答它的版本：

大多数插件允许以指令提供更多配置。比如 chaos 插件，我们可以在语法内定义 VERSION 和 AUTHORS ：

这样，这就给 chaos 插件增加了指令，让 CoreDNS 以 CoreDNS-001 的格式答复版本：

其他插件有更多配置，使用插件块（Plugin Block），跟服务器块一样，以大括号作为开头和结束：

我们将其全部融合起来，就生成下面的 Corefile，设置 4 zones 运行与2个不同的端口：

当CoreDNS解析配置文件的时候，就会是如下的 Setups：

扩展插件就是CoreDNS默认没有包含的插件。你可以开启扩展插件，但是你得自己编译CoreDNS。

插件 health 的文档声明 "This plugin only needs to be enabled once"，这可能导致你认为如下是一个符合规定的Corefile：

但是，这不能工作，并且导致一些 简短的报错：

为什么呢？ health 被看作一个 zone (and the start of a Server Block)。解析希望看到插件名字 ( cache , etcd , etc)，但是下一个标识是 ，这不是插件。

正确的 Corefile 如下：

插件 health 文档里面的那段话，意思是一旦 health 被定义，它对整个CoreDNS 进程来说就是全局的，哪怕你是在一个server中定义它。

一 安装 protocol/buf 编译器

如果 protoc --version ; 则说明安装成功

二 在 Golang 和 Node 服务器中同时配置相同的 proto 文件

三 golang server 安装依赖

四 创建 Node 客户端 koa + ts

五, proto3 语法

使用grpc的时候，线上php客户端调用go服务端，出现2/5/14等状态码，没有做日志输出，导致问题查了很长时间，最终问题是因为连接没有close掉，php连接数不够了。

grpc的状态码在googlegolangorg/grpc/codes：code码跟http的状态码是一个道理，整理下状态码的含义：

0：Ok：请求成功

1：Canceled：操作已取消

2：Unknown：未知错误。如果从另一个地址空间接收到的状态值属 于在该地址空间中未知的错误空间，则可以返回此错误的示例。 没有返回足够的错误信息的API引发的错误也可能会转换为此错误

3：InvalidArgument：表示客户端指定了无效的参数。 请注意，这与FailedPrecondition不同。 它表示无论系统状态如何（例如格式错误的文件名）都有问题的参数

4：DeadlineExceeded：意味着操作在完成之前过期。 对于更改系统状态的操作，即使操作成功完成，也可能会返回此错误。 例如，服务器的成功响应可能会延迟足够的时间以使截止日期到期

5：NotFound：表示找不到某个请求的实体（例如文件或目录）

6：AlreadyExists：表示尝试创建实体失败，因为已经存在

7：PermissionDenied：表示调用者没有执行指定操作的权限。它不能用于因耗尽某些资源而引起的拒绝（使用ResourceExhausted代替这些错误）。如果调用者无法识别，则不能使用它（使用Unauthenticated代替这些错误）

8：ResourceExhausted：表示某些资源已耗尽，可能是每个用户的配额，或者整个文件系统空间不足

9：FailedPrecondition：表示操作被拒绝，因为系统不处于操作执行所需的状态。例如，要删除的目录可能不是空的，rmdir操作应用于非目录等。可能帮助服务实现者判断FailedPrecondition，Aborted和Unavailable之间的试金石测试：使用不可用如果客户端只能重试失败的呼叫。如果客户端应该在更高级别重试（例如，重新启动读取 - 修改 - 写入序列），则使用中止。如果客户端不应该重试直到系统状态被明确修复，则使用FailedPrecondition。例如，如果“rmdir”由于目录非空而失败，应该返回FailedPrecondition，因为客户端不应该重试，除非他们首先通过从目录中删除文件来修复该目录。如果客户端在资源上执行条件REST获取/更新/删除并且服务器上的资源与条件不匹配，则使用FailedPrecondition。例如，在相同的资源上发生冲突的读取 - 修改 - 写入

10：Aborted：表示操作被中止，通常是由于并发问题（如序列器检查失败，事务异常终止等）造成的。请参阅上面的试金石测试以确定FailedPrecondition，Aborted和Unavailable之间的差异

11：OutOfRange：表示操作尝试超过有效范围。 例如，寻找或阅读文件末尾。 与InvalidArgument不同，此错误表示如果系统状态更改可能会解决的问题。 例如，如果要求读取的偏移量不在[0,2 ^ 32-1]范围内，则32位文件系统将生成InvalidArgument，但如果要求从偏移量读取当前值，则它将生成OutOfRange 文件大小。 FailedPrecondition和OutOfRange之间有相当多的重叠。 我们建议在应用时使用OutOfRange（更具体的错误），以便遍历空间的调用者可以轻松查找OutOfRange错误以检测何时完成

12：Unimplemented：表示此服务中未执行或未支持/启用操作

13：Internal： 意味着底层系统预期的一些不变量已被打破。 如果你看到其中的一个错误，那么事情就会非常糟糕

14：Unavailable：表示服务当前不可用。这很可能是一种暂时性情况，可能会通过退避重试来纠正。请参阅上面的试金石测试以确定FailedPrecondition，Aborted和Unavailable之间的差异

15：DataLoss：指示不可恢复的数据丢失或损坏

16：Unauthenticated：表示请求没有有效的操作认证凭证

17：_maxCode：这个是最大的状态码