Go语言构建微服务一站式解决方案(附全套go语言学习资料)
1. 开发单体式应用
假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件,经过初步会议和需求分析,你可能使用传统的程序框架来生成你的项目,最终的程序架构如下图所示:
尽管也是模块化逻辑,但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。最终程序发布的时候也会被打包成单一的程序发布出来。
单体式应用的不足
不幸的是,这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码。几年后,这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子,我最近和一个开发者讨论,他正在写一个工具,用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是很多开发者经过多年努力开发出来的一个怪物。
一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦。敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它。因此,修正bug和正确的添加新功能变的非常困难,并且很耗时。另外,团队士气也会走下坡路。如果代码难于理解,就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。
另外,复杂而巨大的单体式应用也不利于持续性开发。今天,SaaS应用常态就是每天会改变很多次,而这对于单体式应用模式非常困难。另外,这种变化带来的影响并没有很好的被理解,所以不得不做很多手工测试。那么接下来,持续部署也会很艰难。
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。除此之外,因为所有应用实例都是唯一的,这个bug将会影响到整个应用的可靠性。
最后,单体式应用使得采用新架构和语言非常困难。比如,设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架,无论是时间还是成本都是非常昂贵的,即使ABC框架更好。因此,这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。
那么如何应对呢?
2. 微处理架构——处理复杂事物
许多公司,比如Amazon、eBay和NetFlix,通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用,而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能,比如下单管理、客户管理等等。每一个微服务都是微型六角形应用,都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI,运行时,每一个实例可能是一个云VM或者是Docker容器。
比如,一个前面描述系统可能的分解如下:
每一个应用功能区都使用微服务完成,另外,Web应用会被拆分成一系列简单的Web应用(比如一个对乘客,一个对出租车驾驶员)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。 每一个后台服务开放一个REST API,许多服务本身也采用了其它服务提供的API。比如,驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的,基于消息的通讯。
2.1微服务架构的好处
微服务架构模式有很多好处。
首先,通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。
第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务。当然,许多公司试图避免混乱,只提供某些技术选择。然后,这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。
第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。
2.2.微服务架构的特性
1.单一职责
微服务架构中的每个服务,都是具有业务逻辑的,符合高内聚、低耦合原则以及单一职责原则的单元,不同的服务通过“管道”的方式灵活组合,从而构建出庞大的系统。
2.轻量级通信
服务之间通过轻量级的通信机制实现互通互联,而所谓的轻量级,通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言,我们熟悉的 XML 和 JSON,它们是语言无关、平台无关的;对于通信的协议而言,通常基于 HTTP,能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST(Representational State Transfer)是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制,可以让团队选择更适合的语言、工具或者平台来开发服务本身。
- 独立性
- 每个服务在应用交付过程中,独立地开发、测试和部署。
- 在单块架构中所有功能都在同一个代码库,功能的开发不具有独立性;当不同小组完成多个功能后,需要经过集成和回归测试,测试过程也不具有独立性;当测试完成后,应用被构建成一个包,如果某个功能存在 bug,将导致整个部署失败或者回滚。
在微服务架构中,每个服务都是独立的业务单元,与其他服务高度解耦,只需要改变当前服务本身,就可以完成独立的开发、测试和部署。
- 进程隔离
- 在微服务架构中,每个服务都是独立的业务单元,与其他服务高度解耦,只需要改变当前服务本身,就可以完成独立的开发、测试和部署。有时候我们会将重复的代码抽取出来封装成组件,在单块架构中,组件通常的形态叫做共享库(如 jar 包或者 DLL),但是当程序运行时,所有组件最终也会被加载到同一进程中运行。
在微服务架构中,应用程序由多个服务组成,每个服务都是高度自治的独立业务实体,可以运行在独立的进程中,不同的服务能非常容易地部署到不同的主机上。
既然要介绍微服务,就不得不介绍一下与微服务相关的技术。那么,接下来,我们一一做一下详细讲解。
3. protoBuf(Google旗下平台语言无关序列化数据协议)
protobuf是google旗下的一款平台无关,语言无关,可扩展的序列化结构数据格式。所以很适合用做数据存储和作为不同应用,不同语言之间相互通信的数据交换格式,只要实现相同的协议格式即同一 proto文件被编译成不同的语言版本,加入到各自的工程中去。这样不同语言就可以解析其他语言通过 protobuf序列化的数据。目前官网提供了 C++,Python,JAVA,GO等语言的支持。
3.1 protobuf语法定义
要想使用 protobuf必须得先定义 proto文件。所以得先熟悉 protobuf的消息定义的相关语法。下面就来介绍。
首先我们先定义一个 proto文件,结构如下:
message Article {
required int32 article_id=1;
optional string article_excerpt=2;
repeated string article_picture=3;
}
上面我们主要定义了一个消息,这个消息包括文章 ID,文章摘要,文章图片。下面给出消息定义的相关说明 :
message是消息定义的关键字。a) required表示是一个必须字段,必须相对于发送方,在发送消息之前必须设置该字段的值,对于接收方,必须能够识别该字段的意思。发送之前没有设置required字段或者无法识别required字段都会引发编解码异常,导致消息被丢弃。b) Optional:表示是一个可选字段,可选对于发送方,在发送消息时,可以有选择性的设置或者不设置该字段的值。对于接收方,如果能够识别可选字段就进行相应的处理,如果无法识别,则忽略该字段,消息中的其它字段正常处理。---因为optional字段的特性,很多接口在升级版本中都把后来添加的字段都统一的设置为optional字段,这样老的版本无需升级程序也可以正常的与新的软件进行通信,只不过新的字段无法识别而已,因为并不是每个节点都需要新的功能,因此可以做到按需升级和平滑过渡。c)Repeated :表示该字段可以包含0~N个元素。其特性和optional一样,但是每一次可以包含多个值。可以看作是在传递一个数组的值d)int32和string是字段的类型。后面是我们定义的字段名。最后的 1,2,3则是代表每个字段的一个唯一的编号标签,在同一个消息里不可以重复。这些编号标签用与在消息二进制格式中标识你的字段,并且消息一旦定义就不能更改。需要说明的是标签在 1到15范围的采用一个字节进行编码。所以通常将标签 1到15用于频繁发生的消息字段。编号标签大小的范围是1到229 – 1。此外不能使用protobuf系统预留的编号标签(19000 -19999)当然 protobuf支持更多的类型,比如 bool,double,float,枚举,也可以是其他定义过的消息类型譬如前面的消息 Article。支持的基本类型如下:
一般在我们的项目中肯定会有很多消息类型。我们总不能都定义在一个文件中。当一个 proto文件需要另一个 proto文件的时候,我们可以通过 import导入,就像下面这样:
import "article.proto";
message Book {
//定义消息体
}
3.2 protoBuf使用(Go语言版本)
protobuf的使用方法是将数据结构写入到 .proto文件中,使用 protoc编译器编译(间接使用了插件)得到一个新的 go包,里面包含 go中可以使用的数据结构和一些辅助方法。
1.$GOPATH/src/创建 myproto文件夹
2.myproto文件夹中创建 test.proto文件 (protobuf协议文件 )
syntax = “proto2”;
package myproto;
enum FOO {X = 17;};
message Test {
required string label = 1;
optional int32 type = 2 [default=77];
repeated int64 reps = 3;
optional group OptionalGroup = 4 {
required string RequiredFiled = 5;
}
}
- 编译 :执行
protoc --go_out=. *.proto
生成 test.pb.go文件
- 使用 protobuf做数据格式转换
package main
import (
"fmt"
"github.com/golang/protobuf/proto"
"myproto"
)
func main() {
test := &myproto.Test{
Label: proto.String("hello"),
Type: proto.Int32(17),
Reps: []int64{1, 2, 3},
Optionalgroup: &myproto.Test_OptionalGroup{
RequiredFiled: proto.String("good bye"),
},
}
//将Struct test 转换成 protobuf
data, err := proto.Marshal(test)
if err != nil {
fmt.Println("marshaling error: ", err)
}
//得到一个新的Test结构体 newTest
newTest := &myproto.Test{}
//将 data 转换成 Test结构体
err = proto.Unmarshal(data, newTest)
if err != nil {
fmt.Println("unmarshaling error: ", err)
}
//将newTest的字符串序列化打出
fmt.Println(newTest.String())
//得到type字段
if test.GetType() != newTest.GetType() {
fmt.Println("type is not equal")
}
//...
}
4. gRPC(Google定义的PRC协议标准)
4.1 gRPC是什么?
在 gRPC里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法,使得您能够更容易地创建分布式应用和服务。与许多 RPC系统类似, gRPC也是基于以下理念:定义一个服务,指定其能够被远程调用的方法(包含参数和返回类型)。在服务端实现这个接口,并运行一个 gRPC服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。 gRPC客户端和服务端可以在多种环境中运行和交互 -从 google内部的服务器到你自己的笔记本,并且可以用任何 gRPC支持的语言 来编写。所以,你可以很容易地用 Java创建一个 gRPC服务端,用 Go、 Python、Ruby来创建客户端。此外, Google最新 API将有 gRPC版本的接口,使你很容易地将 Google的功能集成到你的应用里。
4.2 使用 protocol buffers
gRPC默认使用protoBuf,这是 Google开源的一套成熟的结构数据序列化机制(当然也可以使用其他数据格式如 JSON)。正如你将在下方例子里所看到的,你用 proto files创建 gRPC服务,用 protoBuf消息类型来定义方法参数和返回类型。你可以在 Protocol Buffers文档找到更多关于 protoBuf的资料。
虽然你可以使用 proto2 (当前默认的 protocol buffers版本 ),我们通常建议你在 gRPC里使用 proto3,因为这样你可以使用 gRPC支持全部范围的的语言,并且能避免 proto2客户端与 proto3服务端交互时出现的兼容性问题,反之亦然。
4.3 你好 gRPC
现在你已经对 gRPC有所了解,了解其工作机制最简单的方法是看一个简单的例子。 Hello World将带领你创建一个简单的客户端 —— 服务端应用,向你展示:
- 通过一个protoBuf模式,定义一个简单的带有 Hello World方法的 RPC服务。
- 用你最喜欢的语言 (如果可用的话 )来创建一个实现了这个接口的服务端。
- 用你最喜欢的 (或者其他你愿意的 )语言来访问你的服务端。
4.4 go语言实现 gRPC远程调用
4.4.1 创建protobuf文件
创建一个 protobuf package,如: my_rpc_proto; 在$GOPATH/src/下创建 go_lession/gRPC_test/my_rpc_proto/文件夹里面创建 protobuf协议文件 helloServer.proto
syntax = "proto3";
package my_rpc_proto;
// The HelloServer service definition.
service HelloServer {
// 第一个远程调用接口
rpc SayHello (HelloRequest) returns (HelloReply) {}
// 第二个远程调用接口
rpc GetHelloMsg (HelloRequest) returns (HelloMessage) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
message HelloMessage {
string msg = 1;
}
在当前文件下,编译 helloServer.proto文件
protoc –go_out=plugins=grpc:./ *.proto
得到 helloServer.pb.go文件
4.4.2 gRPC-Server编写
package main
import (
"fmt"
pb "go_lession/gRPC_test/my_rpc_proto"
"golang.org/x/net/context"
"google.golang.org/grpc"
"net"
)
const (
port = ":18881"
)
type server struct{}
//实现RPC SayHello 接口
func (this *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
return &pb.HelloReply{Message: "hello" + in.Name}, nil
}
//实现RPC GetHelloMsg 接口
func (this *server) GetHelloMsg(ctx context.Context, in *pb.HelloRequest) (*pb.HelloMessage, error) {
return &pb.HelloMessage{Msg: "this is from server HAHA!"}, nil
}
func main() {
listen, err := net.Listen("tcp", port)
if err != nil {
fmt.Println("failed to listen : ", err)
return
}
//得到一个gRPC 服务句柄
srv := grpc.NewServer()
//将 server 结构体注册到 gRPC 服务
pb.RegisterHelloServerServer(srv, &server{})
//启动监听gRPC服务
if err := srv.Serve(listen); err != nil {
fmt.Println("failed to serve, ", err)
return
}
}
4.4.3 gRPC-Client编写
package main
import (
"fmt"
pb "go_lession/gRPC_test/my_rpc_proto"
"golang.org/x/net/context"
"google.golang.org/grpc"
)
const (
address = "localhost:18881"
clientName = "GreenHat"
)
func main() {
//了客户端连接服务器
conn, err := grpc.Dial(address, grpc.WithInsecure())
if err != nil {
fmt.Println("did not connetc : ", err)
return
}
defer conn.Close()
//获取一个 gRPC 句柄
c := pb.NewHelloServerClient(conn)
//远程调用 SayHello接口
r1, err := c.SayHello(context.Background(), &pb.HelloRequest{Name: clientName})
if err != nil {
fmt.Println("cloud not get Hello server ..", err)
return
}
fmt.Println("HelloServer resp: ", r1.Message)
//远程调用 GetHelloMsg接口
r2, err := c.GetHelloMsg(context.Background(), &pb.HelloRequest{Name: clientName})
if err != nil {
fmt.Println("cloud not get hello msg ..", err)
return
}
fmt.Println("HelloServer resp: ", r2.Msg)
}
运行 server,在运行 client
得到以下输出结果:
HelloServer resp: helloGreenHat
HelloServer resp: this is from server HAHA!