微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。
go-micro
比如有 user 和 order 两个服务，这 2 个服务不在一台服务器上，user 怎么调用 order 服务中订单查询功能呢？这就涉及到服务间的通信。
在 RESTful 架构中，我们可以通过 GET /api/user/:id/orders 进行获取数据，然后对数据进行解码（json、xml）等处理再返回给用户，如果是 POST 请求，传递的数据同样也是 json 或 xml 编码协议。
在微服务中，同样也可以通过 RESTful api 进行数据调用，但是服务间走 http 开销太大了，原因是 http 要传递的无用的元数据太多（header 等），再一个就是 http 协议本身比较慢。另外还有一个原因就是 xml 和 json 的编码解码速度效率不算高，编码后的字节较大。
这时候就要走 tcp/udp 协议了，那不能自己对数据进行编码解码这些麻烦的工作吧，所以有了 RPC 框架，比如dubbo、 grpc，rpc 框架可以让你在 A 服务器调用 B 服务器上的函数接口，这中间因为走了网络，所以是没有单体应用中本地函数调用效率高的，但是当业务上规模后，这点损耗是可以忽略的，比如订单查询需求非常大，那么可以部署 50个 order 服务来提供查询，可以进行负载均衡，可以弹性扩展等，这个时候微服务的效果就出来了。
这 50 个 order 服务怎么管理、怎么监控，怎么确定其中某一个是不是挂了？这里面涉及的概念就很多了，服务监控、服务发现、熔断机制等各类名词可能会让人头疼，但是因为服务进行了拆分，服务又分布在不同的位置，所以如果你自己解决这些问题会花费大量的时间和精力，这时候你就需要 go-micro ，它提供了各类组件，解决微服务架构中的不同问题。
Cloud Native （国内译为“云原生”），最早是 Matt Stine 提出的一个概念。与微服务一样，Cloud Native 并不是一种具体的技术，而是一类思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native 既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。所以，Cloud Native 也可以说是一系列Cloud技术、企业管理方法的集合。
RPC
远程过程调用（Remote Procedure Call，RPC）是一个计算机通信协议。
gRPC (gRPC Remote Procedure Calls) 是 Google 发起的一个开源远程过程调用系统，该系统基于 HTTP/2 协议传输。默认采用Protocol Buffers数据序列化协议，支持多种开发语言。
Protocol Buffers是一种更加灵活、高效的数据格式，与XML、JSON类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。
gRPC可以实现微服务，将大的项目拆分为多个小且独立的业务模块，也就是服务，各服务间使用高效的protobuf协议进行RPC调用，gRPC默认使用protocol buffers，这是google开源的一套成熟的结构数据序列化机制。
广义上来讲，所有本应用程序外的调用都可以归类为RPC，不管是分布式服务，第三方服务的HTTP接口，还是读写Redis的一次请求。从抽象的角度来讲，它们都一样是RPC，由于不在本地执行，都有三个特点：
- 需要事先约定调用的语义(接口语法)
- 需要网络传输
- 需要约定网络传输中的内容格式
RESTfull HTTP JSON
RESTfull是一种资源状态转换的架构风格，也可以用来实现RPC， 互联网对HTTP超广泛的支持，使得这相当简单，也是大多数情况下的首选。
通过HTTP协议来进行内容传输，Header用来约定编码、body大小等，彼此以\r\n来分割，Header和body之间通过两个连续的\r\n来间隔，能很容易地区分不同的请求。
通过Url和对应参数来标示要调用的方法和参数。在body中用JSON对内容进行编码，极易跨语言，不需要约定特定的复杂编码格式和Stub文件。在版本兼容性上非常友好，扩展也很容易。
其缺点：
- HTTP的header和Json的数据冗余和低压缩率使得传输性能差
- JSON难以表达复杂的参数类型，如结构体等
gRPC是一款RPC框架，在性能和版本兼容上做了提升和让步：
- Protobuf进行数据编码，提高数据压缩率
- 使用HTTP2.0弥补了HTTP1.1的不足
- 同样在调用方和服务方使用协议约定文件，提供参数可选，为版本兼容留下缓冲空间
protobuf 是一款用C++开发的跨语言、二进制编码的数据序列化协议，以超高的压缩率著称。它和早期的RPC方案一样，需要双方维护一个协议约束文件，以.proto结尾，使用proto命令对文件进行解析，会生成对应的Stub程序，客户端和服务端都需要保存这份Stub程序用来进行编解码。对于这种协议文件导致的升级困难问题，protobuf 3 中定义的字段默认都是可选的(可以不传)，在接口升级时，部分客户端不需要升级自己的Stub程序。
对于JSON等文本形式的序列化协议来说，protobuf能有几十倍空间和性能提升， 比如传输123，文本类的需要3个字节(ascii 31 32 33)来传输，而二进制类只需要一个字节(01111011)就可以表示。
同时protobuf会维护.proto文件，这样在解析文件生成Stub程序时，可以对方法名等进行编号，传输时只传编号，而不用传方法的名字，这又可以节省大量字节，还有其他更多的精巧压缩方法。
解决了数据体积的问题后，gRPC使用HTTP2来改善传输性能。
HTTP2解决了HTTP1.1的一些问题，并引入了新的机制：
- 在两端建立Header索引表，每次只发送索引，减小header体积
- 建立虚拟通道，将数据拆分成多个流，每个流有自己的ID和优先级，并且流可以双向传输，每个流可以进一步拆成多个帧。可以将多个请求切成不同的流发送，每个流可以独立返回，避开1.1的串行或队首阻塞问题。
同时，基于HTTP2的数据流机制，gRPC客户端和服务端可以实现批量操作优化，客户端可以攒一些请求，一口气发给服务端，服务端也可以批量返回结果，借此实现流式rpc。
DevOps
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
JWT(JSON Web Token)
JWT 的原理是，服务器认证以后，生成一个 JSON格式的 对象，发回给客户端，如
{
"用户名": "admin",
"角色": "超级管理员",
"到期时间": "2019-07-13 00:00:00"
}
- 为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。
- 服务器不再保存任何 session 数据，也就是服务器变成无状态了，从而比较容易实现扩展。
- 客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。
此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。
Authorization: Bearer