介绍

Golang 中的微服务系列总计十部分，预计每周更新。本系列的解决方案采用了 protobuf 和 gRPC 作为底层传输协议。为什么采用这两个技术呢？我花了相当长的时间，才想出并决定采用这个方案。这个方案对开发者来说，非常清晰而简明。我也很乐意把自己在搭建、测试和部署端到端的微服务过程中的心得，分享给想接触这块的朋友们。

在这个教程中，我们将先接触几个基础的概念和术语，然后开始搭建第一个简单的微服务模型。

本系列中，我们将会创建以下服务：

  • 委托
  • 存货清单
  • 用户
  • 认证
  • 角色
  • 容器

整个技术栈从底至顶主要可划分为：golang、mongodb、grpc、docker、Google Cloud、Kubernetes、NATS、CircleCI、Terraform 和 go-micro。

接下来，你可以根据我的 （每篇文章都有自己的分支）中的指导逐步操作，不过必须注意把根据你的开发环境调整 GOPATH 。

$(GOPATH)$GOPATH

先决条件

  • 掌握 golang 语言和其开发环境
  • 安装 gRPC / protobuf
  • 安装 golang
  • 按照下列指令，安装 go 的第三方库

我们要搭建的是？

我们将搭建的是一个非常通用的微服务 —— 船运集装箱的管理平台。当然，我也可以用微服务搭建一个博客作为例子，但这实在是太简单了，我更希望能够展示分离复杂性的功能。最终我选择了这个管理平台为例，作为一个挑战！

那么，接下来我们先了解几个知识点：

什么是微服务？

在传统的单体应用中，所有系统的特性都被写入单个应用程序中。有时候我们用类型来区分这些特性，例如控制器、单元模块、工厂等等；其它情况下，例如在更大型的应用中，用互相间的关系或者各自的特征来区分应用特性，所以你可能会有授权程序包、好友关系处理包以及文章管理包，这些包可能都有各自的工厂、服务、数据库、数据模型等。不过，最终它们都被塞入了一个代码库中。

微服务就是把第二种解决方案做得更彻底：将原先的关系分离出来，每个程序包都保存到独立的、可运行的代码库中。

为什么选用微服务？

复杂性 —— 依照特性把程序分割成多个微服务，有助于把大块代码分割成更小的模块。正如一句 Unix 中的老格言所说：把一件事做好（doing one thing well）。在单体应用的系统中，各模块倾向于紧密结合，模块间的关系很模糊。这个会导致系统的升级更为危险和复杂、存在更多的潜在 bug、集成的难度更高。

扩展性 —— 在单体应用的系统中，总有特定模块的代码会比其余模块用得更为频繁，而你只能扩大整个库的规模来解决。例如你的鉴权模块被高频率地调用，对系统造成了高负荷的压力。于是你扩大了库规模，而原因仅仅是一个小小鉴权模块。

如果换成了微服务，那么你可以独立地扩大任何一个服务模块，这意味着我们可以更有效地进行横向扩展。这种分离性对多核、多区域的云计算带来了极大的帮助。

Nginx 有个极好的微服务系列，讲述了各种概念，请点击链接访问。

为什么选择 Golang？

几乎所有的语言都支持微服务。微服务不是一个具体的框架或工具，而是一个概念。这就意味着，在选择构建微服务的语言中，总有一些更为合适、或者说支持性更好。Golang 就是其中的佼佼者。

Golang 是一个轻量级、运行速度快、对高并发支持极好的语言，很有力地支持了多核、多设备运行的场景。

Golang 在网络服务上，也具有强大的标准库。

目前，已有一个强大的微服务框架 —— go-micro，我们在这个系列中会用到它。

protobuf/gRPC 简介

微服务被分割成多个独立的代码库，这就带来了一个重要的问题 —— 通信。在单体应用的系统中，你可以在代码库的任何地方调用想要的代码，所以不存在通信的问题。而微服务分布在不同的代码库中，不具备直接调用的能力。所以，你需要找到一个途径，使得不同服务之间可以尽可能低延迟地进行数据交互。

这里，我们可以采用传统的 REST 架构，例如通过 http 传输 JSON 或者 XML 。但这种方案会带来了一个问题：服务 A 把原始数据编码成 JSON/XML 格式，发送一长串字符给服务 B，B 通过解码还原成原始数据。不过，当原始数据量很大时，这可能对通信造成严重影响。当我们和网络浏览器的通信时，只要约定了服务间的通信方式、固定了编码和解码方法，那么格式可以任意。

就应运而生。gRPC 是一个由 Google 开发、基于 RPC 通信、轻量级的二进制传输协议。这个定义有点复杂，下面请由我细细道来。gRPC 核心数据格式采用的是二进制，而在上面 RESTful 的例子中，我们用的是 JSON 格式，也就是通过 http 发送一串字符串。字符串包括了它的编码格式、长度和其它占用字节的信息，所以总体数据量很大。基于客户端的字符串数据，服务器可以通知传统的浏览器，解析得到预期的数据。但在两个微服务的通信间，我们不需要字符串中的所有数据，所以我们采用难理解但更加轻量的二进制数据进行交互。gRPC 采用的是支持二进制数据的 HTTP 2.0 规范，这个规范还能支持双向的通信流，相当炫酷！HTTP 2 是 gRPC 工作的基础。如果你想进一步了解 HTTP 2，可以点击这个。

接下来的问题是，二进制数据该如何处理呢？不用担心，gRPC 有一个内部的数字模拟语言，叫 protobuf。Protobuf 支持自定义接口格式，对开发者很友好。

consignment-service/proto/consignment/consignment.proto
consignment.proto
Container
service

protobuf 定义的结构，可以通过客户端接口，自动生成相应语言的二进制数据和功能。

$ touch consignment-service/Makefile

这个 Makefile 会调用 protoc 库，将你的 protobuf 编译成对应的代码。同时，我们也指定了 gRPC 插件、编译目录和输出目录。

$ make buildproto/consignment/consignment.pb.go
$ touch consignment-service/main.go
$ go run main.go

下面，我们来写一个命令行交互的程序，用来读取一个包含委托信息的 JSON 文件，和我们已创建的 gRPC 服务器交互。

$ mkdir consignment-clicli.go
consignment-cli/consignment.json
consignment-service$ go run main.go$ go run cli.goCreated: trueGetConsignments

首先需要更新我们的 proto 定义（我在修改部分添加了备注）

GetConsignmentsGetRequestconsignmentsrepeated
$ make build*service does not implement go_micro_srv_consignment.ShippingServiceServer (missing GetConsignments method)

protobuf 库产生的接口在通信两端必须完全匹配，这是实现 gRPC 的基础。所以，我们需要确认 proto 的定义是否一致。

consignment-service/main.go
GetConsignmentsgo run main.go
GetConsignments
Created: success$ go run cli.goGetConsignments
...

到这里，我们通过 protobuf 和 gRPC，完整地创建了一个微服务，以及一个与之交互的客户端。

本系列的下一章节将围绕着集成 展开。go-micro 是一个基于微服务的、创建 gRPC 的强大框架。我们也会在下章创建第二个微服务 —— 容器服务。光说“容器”二字也许会令你困惑，这里具体指的是 Docker 中的“容器”概念。我们会在下一章探索微服务在 Docker 容器中的运行情况。

如果对此文有任何 bug、错误或者反馈，请直接邮箱。

gittutorial-1

编写本文花了我很长的时间以及大量的精力。如果你觉得这个系列有帮助，请考虑顺手打赏我(完全取决于你的意愿)。十分感谢！

鸣谢：Microservices Newsletter (22nd November 2017)

译者：

校对：

本文由 原创编译， 荣誉推出