Go技术栈的微服务构建.docxVIP

PAGE 1 PAGE 1 Go技术栈的微服务构建  在大型系统的微服务化构建中，一个系统会被拆分成很多模块。这些模块负责不同的功能，组合成系统，最终可以供应丰富的功能。在这种构建形式中，开发者一般会聚焦于最大程度解耦模块的功能以削减模块间耦合带来的额外开发成本。同时，微服务面临着如何部署这些大量的服务系统、如何运维这些系统等新问题。  在大型系统的微服务化构建中，一个系统会被拆分成很多模块。这些模块负责不同的功能，组合成系统，最终可以供应丰富的功能。在这种构建形式中，开发者一般会聚焦于最大程度解耦模块的功能以削减模块间耦合带来的额外开发成本。同时，微服务面临着如何部署这些大量的服务系统、如何运维这些系统等新问题。  本文的素材来源于我们在开发中的一些最佳实践案例，从开发、监控、日志等角度介绍了一些我们基于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系统为我们记录下恳求的统计信息，比如恳求数目、根据不同恳求时间统计的分布等。  需要说明的是，这套系统暴露了一个http服务，我们可以通过debug开关在运行时按需打开或者关