基于Go技术栈的微服务构建Word文档格式.docx

基于Go技术栈的微服务构建Word文档格式.docx

《基于Go技术栈的微服务构建Word文档格式.docx》由会员分享，可在线阅读，更多相关《基于Go技术栈的微服务构建Word文档格式.docx（4页珍藏版）》请在冰豆网上搜索。

这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。

在这种构建形式中，开发者一般会聚焦于最大程度解耦模块的功能以减少模块间耦合带来的额外开发成本。

同时，微服务面临着如何部署这些大量的服务系统、如何运维这些系统等新问题。

本文的素材来源于我们在开发中的一些最佳实践案例，从开发、监控、日志等角度介绍了一些我们基于Go技术栈的微服务构建经验。

开发

微服务的开发过程中，不同模块由不同的开发者负责，明确定义的接口有助于确定开发者的工作任务。

最终的系统中，一个业务请求可能会涉及到多次接口调用，如何准确清晰的调用远端接口，这也是一大挑战。

对于这些问题，我们使用了gRPC来负责协议的制订和调用。

传统的微服务通常基于http协议来进行模块间的调用，而在我们的微服务构建中，选用了Google推出的gRPC框架来进行调用。

下面这张简表比较了httprpc框架与gRPC的特性：

gRPC的接口需要使用Protobuf3定义，通过静态编译后才能成功调用。

这一特性减少了由于接口改变带来的沟通成本。

如果使用httprpc，接口改变就需要先改接口文档，然后周知到调用者，如果调用者没有及时修改，很可能会到服务运行时才能发现错误。

而gRPC的这种模式，接口变动引起的错误保证在编译时期就能消除。

在性能方面，gRPC相比传统的httprpc协议有非常大的改善（根据这个评测，gRPC要快10倍）。

gRPC使用http2协议进行传输，相比较http1.1,http2复用tcp连接，减少了每次请求建立tcp连接的开销。

需要指出的是，如果单纯追求性能，之前业界一般会选用构建在tcp协议上的rpc协议（thrift等），但四层协议无法方便的做一些传输控制。

相比而言，gRPC可以在httpheader中放入控制字段，配合nginx等代理服务器，可以很方便的实现转发/灰度等功能。

接下来着重谈谈我们在实践中如何使用gRPC的一些特性来简化相关开发流程。

1.使用context来控制请求的生命周期

在gRPC的go语言实现中，每个rpc请求的第一个参数都是context。

http2协议会将context放在HEADER中，随着链路传递下去，因此可以为每个请求设置过期时间，一旦遇到超时的情况，发起方就会结束等待，返回错误。

ctx:

=context.Background（）//blankcontext

ctx,cancel=context.WithTimeout（ctx,5*time.Second）

defercancel（）

grpc.CallServiveX（ctx,arg1）

上述这段代码，发起方设置了大约5s的等待时间，只要远端的调用在５s内没有返回，发起方就会报错。

除了能加入超时时间，context还能加入其他内容，下文我们还会见到context的另一个妙用。

2.使用TLS实现访问权限控制

gRPC集成了TLS证书功能，为我们提供了很完善的权限控制方案。

在实践中，假设我们的系统中存在服务Ａ，由于它负责操作用户的敏感内容，因此需要保证Ａ不被系统内的其他服务滥用。

为了避免滥用，我们设计了一套自签名的二级证书系统，服务Ａ掌握了自签名的根证书，同时为每个调用Ａ的服务颁发一个二级证书。

这样，所有调用Ａ的服务必须经过Ａ的授权，Ａ也可以鉴别每个请求的调用方，这样可以很方便的做一些记录日志、流量控制等操作。

3.使用trace在线追踪请求

gRPC内置了一套追踪请求的trace系统，既可以追踪最近10个请求的详细日志信息，也可以记录所有请求的统计信息。

当我们为请求加入了trace日志后，trace系统会为我们记录下最近１０个请求的日志,下图中所示的例子就是在trace日志中加入了对业务数据的追踪。

在宏观上，trace系统为我们记录下请求的统计信息，比如请求数目、按照不同请求时间统计的分布等。