golang 字符串加数组怎么传值给接受可变参数的函数

在 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文件如下所示：

我们开发的不是MMORPG, 但是规模不小, 纯Golang开发 从处理客户端连接, MySQL处理到跨服, 平台SDK对接都是使用Golang开发的之前我的C++服务器框架也是完善的, 但和Golang比起来, 总是有一些问题, 比如说:1 总是感觉C++写出来的服务器要结实一些, 因为有强大的IDE(我们是在Windows开发Linux下运行), 强大的调试器(VS) Golang虽然没有这些, 但LiteIDE本身已经足够强大,没有之一2 Golang性能调优很是方便, 性能, 内存和阻塞, 3个pdf生成节点图, 几下就能找出问题所在 C++在这点上必须用专业第三方收费工具以及自己多年的经验来分析, 很是麻烦3 Golang任何错误都可以捕捉, 跨平台运行, 尤其是Linux, 比C++稳定的多 不用担心哪天挂掉4 Golang的Socket, 让你能想起当年用C语言的阻塞Socket时代 可惜 *** 作系统的线程不能跟goroutine同日而语5 Golang语言简单, 任何语言招来, 2~3天开始生产代码, 很简单, 用的人也舒心6 Golang的语言特性很好, 没有OO的冗余, 只有复合+接口的简洁 用习惯后, 都不敢去用C#的OO, 怕继承变化需要重构7 Golang 14比前面版本好很多, gc基本没啥大问题了 只是自举的编译器编译速度下降了不少 但问题不大8 Golang写服务器, 因为阻塞+同步逻辑, 所以还是得考虑各种线程同步问题 该加锁还是要加锁, 而不是一味都用channel+goroutine来实现 逼近channel本身是由多个锁来实现的9 Golang写tcp短连接不知道比C++简单上百倍吧, 比boostasio这些封装库也简单个10来倍>

为什么需要context
在go服务器中，对于每个请求的request都是在单独的goroutine中进行的，处理一个request也可能设计多个goroutine之间的交互， 使用context可以使开发者方便的在这些goroutine里传递request相关的数据、取消goroutine的signal或截止日期
在并发程序中，由于超时、取消 *** 作或者一些异常情况，往往需要进行抢占 *** 作或者中断后续 *** 作。熟悉channel的朋友应该都见过使用done channel来处理此类问题。比如以下这个例子：

上述例子中定义了一个buffer为0的channel done, 子协程运行着定时任务。如果主协程需要在某个时刻发送消息通知子协程中断任务退出，那么就可以让子协程监听这个done channel，一旦主协程关闭done channel，那么子协程就可以推出了，这样就实现了主协程通知子协程的需求。这很好，但是这也是有限的。
如果我们可以在简单的通知上附加传递额外的信息来控制取消：为什么取消，或者有一个它必须要完成的最终期限，更或者有多个取消选项，我们需要根据额外的信息来判断选择执行哪个取消选项。
考虑下面这种情况：假如主协程中有多个任务1, 2, …m，主协程对这些任务有超时控制；而其中任务1又有多个子任务1, 2, …n，任务1对这些子任务也有自己的超时控制，那么这些子任务既要感知主协程的取消信号，也需要感知任务1的取消信号。
如果还是使用done channel的用法，我们需要定义两个done channel，子任务们需要同时监听这两个done channel。嗯，这样其实好像也还行哈。但是如果层级更深，如果这些子任务还有子任务，那么使用done channel的方式将会变得非常繁琐且混乱。
我们需要一种优雅的方案来实现这样一种机制：
上层任务取消后，所有的下层任务都会被取消；中间某一层的任务取消后，只会将当前任务的下层任务取消，而不会影响上层的任务以及同级任务。
这个时候context就派上用场了。我们首先看看context的结构设计和实现原理。
context接口
先看Context接口结构，看起来非常简单。

}
Context接口包含四个方法：
Deadline返回绑定当前context的任务被取消的截止时间；如果没有设定期限，将返回ok == false。
Done 当绑定当前context的任务被取消时，将返回一个关闭的channel；如果当前context不会被取消，将返回nil。
Err 如果Done返回的channel没有关闭，将返回nil;如果Done返回的channel已经关闭，将返回非空的值表示任务结束的原因。如果是context被取消，Err将返回Canceled；如果是context超时，Err将返回DeadlineExceeded。
Value 返回context存储的键值对中当前key对应的值，如果没有对应的key,则返回nil。
可以看到Done方法返回的channel正是用来传递结束信号以抢占并中断当前任务；Deadline方法指示一段时间后当前goroutine是否会被取消；以及一个Err方法，来解释goroutine被取消的原因；而Value则用于获取特定于当前任务树的额外信息。而context所包含的额外信息键值对是如何存储的呢？其实可以想象一颗树，树的每个节点可能携带一组键值对,如果当前节点上无法找到key所对应的值，就会向上去父节点里找，直到根节点。
emptyCtx
emptyCtx是一个int类型的变量，但实现了context的接口。emptyCtx没有超时时间，不能取消，也不能存储任何额外信息，所以emptyCtx用来作为context树的根节点。

Background和TODO只是用于不同场景下： Background通常被用于主函数、初始化以及测试中，作为一个顶层的context，也就是说一般我们创建的context都是基于Background；而TODO是在不确定使用什么context的时候才会使用。
用法 ：

---