@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 哈哈哈，欢迎品尝 ^_^

@kevinwan 我选择把世界上最好的语言供奉起来，干业务这种还是交给 go 好些 😂