@shunia 我不知道我理解的路由是否正确，如果说的不准确，多多指正。
我上面说的是传统方案的路由（不是 react 、vue 的路由）——传统 web 前端方案主流应该是 window.location 吧，然后是 reload，性能差。说的是传统方案这样性能差，好像没说对标 react 、vue 的路由导致性能差。

如果你理解成对标 react 、vue，那么对标的部分我是指它们的虚拟 dom，因为最终都是操作 native，所以如果 native 实现方案合理，react 、vue 并不会比 native 性能更高。

“go 多好啊” —— 严重同意，所以我也不是折腾 js 后端，只是捎带一点前端思路

@Kasumi20 如果业务层觉得有必要，完全可以自己使用路由。只是使用 pm.js 的方案不需要使用路由，并且通常没有必要，这在 GUI/H5 GAME 领域很常见。
需求仍然可以按照多个 html 进行工程管理。传统路由方案是为了切换页面，pm.js 的一样能达到而且简单方便、可以得到最佳性能保障，而传统 native 路由切换页面的方案正是常规项目性能的最大瓶颈所在。

看来大家都去搞 react 、vue 了，没人关心 native 了 😂

周一搬砖日，up up ~

@lesismal 参考自：

https://github.com/opentracing/basictracer-go/blob/8e39e894ba59569ffb0b13167ebbe64b0b142e94/examples/dapperish.go

@kevinwan @DoctorCat ARPC 也实现了个编码中间件的扩展示例，把 opentracing 的支持加上了，例子：

https://github.com/lesismal/arpc/tree/master/examples/middleware/coder/tracing

@lesismal 描述清楚了就好回答了，文字沟通不方便，如果是面对面沟通可能早就讲清楚了 😁😁

"不过我一般考虑到资源隔离，以及协程的资源占用不高，3 都是开个协程来处理"
—— 嗯嗯，这种用于 RPC 的场景，请求和依赖的下游模块做好限流之类的，系统就不会爆

ARPC 主要是考虑通用场景比如包括游戏领域的业务，请求方的频率可能会非常高，热点时段协程数量可能会爆，所以留给了业务层根据实际场景做更灵活的同步异步定制

周末愉快 ^_^

@lesismal 或者分成"异步请求处理" 和 "异步回包"来描述更清楚些，但是这个处理流程比较简单，就几行代码，就不做太强的概念辨识度相关的解释了 😂

v 站玩的少，markdown 和代码段的格式不知道怎么搞，编辑好的缩进发出来都给我整没了 😂😂

@so1n

一次完整的调用过程指 client 端 Call 调用的返回，其中大致包括了几个主要流程：
1. client 发送请求数据
2. server 接收到请求数据
3. server 处理请求
4. server 发送响应数据
5. client 收到请求数据，调用结束

因为传统 RPC server 端的流程，以 go 的 "net/rpc" 为例，对于每个连接的流程大概是
go func() {
for {
2. server 接收到请求数据
go func() {
3. server 处理请求 // 这里是回调业务层注册进来的 handler
4. server 发送响应数据 // 业务层处理完之后，框架层把 3 中的 handler 返回值打包成响应数据，发送给 client
}()
}
}()

3 中 handler 是默认 go 一个新的协程进行处理，这种在连接数非常多、并发请求量大的时候协程数量多、各项资源消耗比较浪费
但是业务层处理 3 的流程，又不能自主选择是否每次 go 一个新的协程


我在主帖中说的是："异步响应"和"异步回包"。ARPC 提供了更灵活的机制，大概如下：
处理请求的 handler = 3+4 （ server 处理请求+server 发送响应数据）
go func() {
for {
2. server 接收到请求数据
if 注册时设置为异步处理 {
// 此处是指 "异步响应"
go handler() // 3+4
} else {
handler() // 3+4
}
}
}()
而 handler 的实现中也可以自主选择同步或者异步回包，比如：
func handler(ctx *arpc.Context) {
// do something
if condition {
go ctx.Write(...) // 此处指"异步回包"
或者
// 此处是指 "异步响应"
go func() {
// do something
go ctx.Write(...) // 此处是指 "异步回包"
}
} else {
// do something
ctx.Write(...)
}
}

晚上状态有点懵逼，不知道有没有写错的地方，先大概看下吧 😁😁

@so1n 兄弟，先读点好书，或者搜知识点，阻塞、非阻塞、同步、异步，还有其他的很多基础知识补上再交流，否则问出来的问题容易把我问死，不是不想回答，但基础知识的科普，我没那么多时间啊，而且零碎的知识不如你自己系统性学习的效果好 😂😂
或者可以直接来读源码，标准库的源码很赞、很值得学习，或者比如你想问的 ARPC 的问题，ARPC 源码也相对简单，你按照 server 的启动流程看进去，很快就能找到答案了

@robot9 这两点对于非 rpc 的领域好像也同样重要，所以，反倒不是 rpc 的重点了，而是通用场景的重点 😅😅

@so1n
单个连接上的消息是顺序读取的，你说的这种是 one-by-one 的方式进行处理，处理完一个再处理下一个，http 是这样子的，一个处理完之前下一个要排队等待，如果一个处理慢了会导致其他消息也被阻塞、这个问题通常叫线头阻塞
io 多路复用是指 select 、poll 、epoll 、iocp 、kqueue 等，通过事件机制、异步 io 对多个文件描述符（网络连接也是文件描述符的一种）进行高效的异步 io 操作
兄弟概念有点迷茫，可以多看些好书比如 CSAPP 、APUE 、UNP 之类的，啃下来消化消化应该会有很大帮助😁😁

@kevinwan 嗯嗯了解😆😁

@iyangyuan 上一条 url 跟文字连一起了无法跳转，而且我还没有编辑权限，重新贴下 url：

https://www.jianshu.com/p/ed3f8f983764

@iyangyuan 我不用 java 😂，随便搜了下 Spring Cloud HTTP2 相关，https://www.jianshu.com/p/ed3f8f983764，好像 Spring Cloud 还是有很大提升空间。
并且，"能罩得住" 和 "能罩得住得更好" 也不是同一件事 😁

@IamYourDad 兄弟，我也没太看懂，能详细描述下不？比如

“样例里面 server->client 是不是多次一举啊“，这里的多此一举是不是指 ctx.Write()？比如，return xxx 然后框架层自己 Write 给 client 就行了、不需要让用户自己去 Write ？如果是这个意思，请看主贴的这个部分： "2. Server 端函数调用的写法，函数返回即是调用结束，不够灵活" 。而且，这里是可以异步回包的，方便业务层灵活定制业务模块的任务池、流控等，比如：

func onEcho(ctx *arpc.Context) {
str := ""
err := ctx.Bind(&str)
if err != nil {
log.Printf("/echo error: %v", err)
return
}

// 这里也可能不直接用 go 、而是使用其他业务模块的协程池异步回包
go func() {
// do something.
ctx.Write(str)
}()
}

另外，兄弟，建议改个 ID，你这个 ID 别人读出来或者看文字心里默读的时候其实是你自己吃亏啊。。。😅😂

@no1xsyzy 嗯嗯，文字交流、一些场景没有既定的“黑话”，大家可能会理解出一些歧义 😅

其实需要确认对方执行了的场景，使用 Call 的方式等应答结果就行了.MQTT 既然是基于 tcp，业务层再去设计重传相关的我始终感觉有点别扭😅
我个人对 tcp 的设计也不太满意，有了 BBR 之后传输效率更合理些了，但是 三次握手四次断开 依旧很浪费，2 次握手就足够了，毕竟后面每次都会带 ack ；断开也是 2 次就够了——两边各断开一次、一次断双工，因为工作十几年了，我自己业务还从没遇到过需要半双工分别断开的场景，或者说没遇到过半双工分别断开优于双工同时断开的场景，并且，由于仍然可能存在掉电、线路故障等情况导致任何数据的无法送达，所以关闭一半反倒是作茧自缚 😅。
所以，超脱到 4 层之上，再看送达相关的问题可能会简单些：非事务性的业务，送不送大无所谓；事务 /弱事务性的，业务层的自行保障措施省略不掉。所以对于网络交互层的关注，放在保障线路、设备稳定性等工程属性上就好了

游戏、VOIP 电话之类的丢帧就丢帧吧，后面的状态同步过来正确就好，这种场景我也会选择使用 udp，这些特殊场景还是得自家定制才对性能最友好，否则就 pb 咱都觉得性能不够

@xeaglex 哈哈哈，欢迎品尝 ^_^