Go在微服务框架中有其独特的优势，至于优势在哪，自行google。
1、GoKit框架
这是一个工具包的集合，可以帮助攻城狮构建强大、可靠和可维护的微服务。提供了用于实现系统监控和弹性模式组件的库，例如日志、跟踪、限流、熔断等。
基于这个框架的应用程序架构由三个主要的部分组成：
传输层：用于网络通信，服务通常使用HTTP或者gRPC等网络传输协议，或者使用NATS等发布订阅系统相互通信。
接口层：是服务器和客户端的基本构建块。每个对外提供的接口方法都会定义为一个Endpoint，一遍在服务器和客户端之间进行网络通信，每个端点使用传输层通过HTTP或gRPC等具体通信模式对外提供服务
服务成：具体的业务逻辑实现
2、GoMicro框架
这是一个基于Go语言实现的插件化RPC微服务框架。提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制，尝试简化分布式系统之间的通信，让开发者更专注于自身业务逻辑的开发。
GoMicro的设计哲学是可插拔的架构理念，提供了可快速构建系统的组件，并且可以根据自身的需求对GoMicro提供的默认实现进行定制。所有插件都可在仓库github.com/micro/go-plugins 中找到。
在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端 应用的方法，使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。
gRPC 客户端和服务端可以在多种环境中运行和交互 - 从 google 内部的服务器到你自己的笔记本，并且可以用任何 gRPC 支持的语言来编写。所以，你可以很容易地用 Java 创建一个 gRPC 服务端，用 Go、Python、Ruby 来创建客户端。此外，Google 最新 API 将有 gRPC 版本的接口，使你很容易地将 Google 的功能集成到你的应用里。
gRPC 默认使用 protocol buffers，这是 Google 开源的一套成熟的结构数据序列化机制（当然也可以使用其他数据格式如 JSON）。名叫 proto3 的新风格的 protocol buffers，它拥有轻量简化的语法、一些有用的新功能，并且支持更多新语言。当前针对 Java 和 C++ 发布了 beta 版本，针对 JavaNano（即 Android Java）发布 alpha 版本，在protocol buffers Github 源码库里有 Ruby 支持， 在golang/protobuf Github 源码库里还有针对 Go 语言的生成器， 对更多语言的支持正在开发中。
有了 gRPC， 我们可以一次性的在一个 .proto 文件中定义服务并使用任何支持它的语言去实现客户端和服务器，反过来，它们可以在各种环境中，从Google的服务器到你自己的平板电脑—— gRPC 帮你解决了不同语言及环境间通信的复杂性.使用 protocol buffers 还能获得其他好处，包括高效的序列号，简单的 IDL 以及容易进行接口更新。
现在让我们来仔细了解一下当 gRPC 客户端调用 gRPC 服务端的方法时到底发生了什么。我们不究其实现细节，关于实现细节的部分，你可以在我们的特定语言页面里找到更为详尽的内容。
首先我们来了解一下最简单的 RPC 形式：客户端发出单个请求，获得单个响应。
服务端流式 RPC 除了在得到客户端请求信息后发送回一个应答流之外，与我们的简单例子一样。在发送完所有应答后，服务端的状态详情(状态码和可选的状态信息)和可选的跟踪元数据被发送回客户端，以此来完成服务端的工作。客户端在接收到所有服务端的应答后也完成了工作。
客户端流式 RPC 也基本与我们的简单例子一样，区别在于客户端通过发送一个请求流给服务端，取代了原先发送的单个请求。服务端通常（但并不必须）会在接收到客户端所有的请求后发送回一个应答，其中附带有它的状态详情和可选的跟踪数据。
双向流式 RPC ，调用由客户端调用方法来初始化，而服务端则接收到客户端的元数据，方法名和截止时间。服务端可以选择发送回它的初始元数据或等待客户端发送请求。 下一步怎样发展取决于应用，因为客户端和服务端能在任意顺序上读写 - 这些流的操作是完全独立的。例如服务端可以一直等直到它接收到所有客户端的消息才写应答，或者服务端和客户端可以像"乒乓球"一样：服务端后得到一个请求就回送一个应答，接着客户端根据应答来发送另一个请求，以此类推。
通过运行下面的命令克隆并安装grpc-go代码库：
下载protobuf源码包
安装golang-protobuf
第一步使用 protocol buffers去定义 gRPC service 和方法 request 以及 response 的类型。
要定义一个服务，必须在.proto 文件中指定 service：
然后在服务中定义 rpc 方法，指定请求的和响应类型，gRPC 允许定义4种类型的 service 方法。
服务.proto文件如下所示：
当分别处于大小端模式下的内容存放如下
(1)大端模式存储（存储地址为16位）
地址 数据
0x0004(高地址) 0x44
0x0003 0x33
0x0002 0x22
0x0001(低地址) 0x11
(2)小端模式存储（存储地址为16位）
地址 数据
0x0004(高地址) 0x11
0x0003 0x22
0x0002 0x33
0x0001(低地址) 0x44
在前面也简单阐述了大小端序的定义并结合简单实例来说明，接下来会给出详细实例来说明：
1、大端序(Big-Endian):或称大尾序
一个类型: int32 的数 0X0A0B0C0D的内存存放情况
数据是以8bits为单位
2、小端序(little-endian):或称小尾序
比如0x00000001
大端序：内存低比特位 00000000 00000000 00000000 00000001 内存高比特位
小端序：内存低比特位 10000000 00000000 00000000 00000000 内存高比特位
其实在前面罗列出那么东西，最终是为了接下来讲述的在golang中涉及到网络传输、文件存储时的选择。一般来说网络传输的字节序，可能是大端序或者小端序，取决于软件开始时通讯双方的协议规定。TCP/IP协议RFC1700规定使用“大端”字节序为网络字节序，开发的时候需要遵守这一规则。默认golang是使用大端序。详情见golang中包encoding/binary已提供了大、小端序的使用
输出结果：
16909060 use big endian:
int32 to bytes: [1 2 3 4]### [0001 0002 0003 0004]
bytes to int32: 16909060
16909060 use little endian:
int32 to bytes: [4 3 2 1] ### [0004 0003 0002 0001]
bytes to int32: 16909060
在RPCX框架中关于RPC调用过程涉及的传递消息进行编码的，采用的就是大端序模式
