docs: update doc/guide (cloudwego#35)

* doc: update README

* doc: add guide cn/en

* ci: remove check branch

* doc: mv multisyscall to future

.github/workflows/pr-check.yml

@@ -8,9 +8,6 @@ jobs:
     steps:
       - uses: actions/checkout@v2
 
-      - name: Check Branch
-        run: ./check_branch_name.sh ${{ github.head_ref }}
-
       - name: Set up Go
         uses: actions/setup-go@v2
         with:

README.md

@@ -2,50 +2,50 @@
 
 # Introduction
 
-[Netpoll](https://github.com/cloudwego/netpoll) is a high-performance non-blocking I/O networking framework, which
-focused on RPC scenarios, developed by [ByteDance](https://www.bytedance.com).
+[Netpoll][Netpoll] is a high-performance non-blocking I/O networking framework, which
+focused on RPC scenarios, developed by [ByteDance][ByteDance].
 
 RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard
-library [net](https://github.com/golang/go/tree/master/src/net) designed blocking I/O API, so that the RPC framework can
+library [net][net] is designed for blocking I/O APIs, so that the RPC framework can
 only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching, due to a large number
-of goroutines under high concurrency. Besides, [net.Conn](https://github.com/golang/go/blob/master/src/net/net.go) has
+of goroutines under high concurrency. Besides, [net.Conn][net.Conn] has
 no API to check Alive, so it is difficult to make an efficient connection pool for RPC framework, because there may be a
 large number of failed connections in the pool.
 
 On the other hand, the open source community currently lacks Go network libraries that focus on RPC scenarios. Similar
-repositories such as: [evio](https://github.com/tidwall/evio), [gnet](https://github.com/panjf2000/gnet), etc., are all
-focus on scenarios like [Redis](https://redis.io), [Haproxy](http://www.haproxy.org).
+repositories such as: [evio][evio], [gnet][gnet], etc., are all
+focus on scenarios like [Redis][Redis], [Haproxy][Haproxy].
 
-But now, [Netpoll](https://github.com/cloudwego/netpoll) was born and solved the above problems. It draws inspiration
-from the design of [evio](https://github.com/tidwall/evio) and [netty](https://github.com/netty/netty), has
+But now, [Netpoll][Netpoll] was born and solved the above problems. It draws inspiration
+from the design of [evio][evio] and [netty][netty], has
 excellent [Performance](#performance), and is more suitable for microservice architecture.
-Also [Netpoll](https://github.com/cloudwego/netpoll) provides a number of [Features](#features), and it is recommended
-to replace [net](https://github.com/golang/go/tree/master/src/net) in some RPC scenarios.
+Also [Netpoll][Netpoll] provides a number of [Features](#features), and it is recommended
+to replace [net][net] in some RPC scenarios.
 
-We developed the RPC framework [KiteX](https://github.com/cloudwego/kitex) and HTTP
-framework [Hertz](https://github.com/cloudwego/hertz) (to be open sourced) based
-on [Netpoll](https://github.com/cloudwego/netpoll), both with industry-leading performance.
+We developed the RPC framework [KiteX][KiteX] and HTTP
+framework [Hertz][Hertz] (to be open sourced) based
+on [Netpoll][Netpoll], both with industry-leading performance.
 
-[Examples](https://github.com/cloudwego/netpoll-benchmark) show how to build RPC client and server
-using [Netpoll](https://github.com/cloudwego/netpoll).
+[Examples][Netpoll-Benchmark] show how to build RPC client and server
+using [Netpoll][Netpoll].
 
 For more information, please refer to [Document](#document).
 
 # Features
 
 * **Already**
-    - [LinkBuffer](nocopy_linkbuffer.go) provides nocopy API for streaming reading and writing
-    - [gopool](https://github.com/bytedance/gopkg/util/gopool) provides high-performance goroutine pool
-    - [mcache](https://github.com/bytedance/gopkg/lang/mcache) provides efficient memory reuse
-    - [multisyscall](https://github.com/cloudwego/multisyscall) supports batch system calls
+    - [LinkBuffer][LinkBuffer] provides nocopy API for streaming reading and writing
+    - [gopool][gopool] provides high-performance goroutine pool
+    - [mcache][mcache] provides efficient memory reuse
     - `IsActive` supports checking whether the connection is alive
     - `Dialer` supports building clients
     - `EventLoop` supports building a server
     - TCP, Unix Domain Socket
     - Linux, Mac OS (operating system)
 
 * **Future**
-    - [io_uring](https://github.com/axboe/liburing)
+    - [multisyscall][multisyscall] supports batch system calls
+    - [io_uring][io_uring]
     - Shared Memory IPC
     - Serial scheduling I/O, suitable for pure computing
     - TLS
@@ -64,12 +64,12 @@ Therefore, we set that the benchmark should meet the following conditions:
 1. Support concurrent calls, support timeout(1s)
 2. Use protocol: header(4 bytes) indicates the total length of payload
 
-Similar repositories such as [net](https://github.com/golang/go/tree/master/src/net)
-, [evio](https://github.com/tidwall/evio), [gnet](https://github.com/panjf2000/gnet). We compared their performance
-through [Benchmarks](https://github.com/cloudwego/netpoll-benchmark), as shown below.
+Similar repositories such as [net][net]
+, [evio][evio], [gnet][gnet]. We compared their performance
+through [Benchmarks][Benchmarks], as shown below.
 
-For more benchmark reference [Netpoll-Benchmark](https://github.com/cloudwego/netpoll-benchmark)
-, [KiteX-Benchmark](https://github.com/cloudwego/kitex) and [Hertz-Benchmark](https://github.com/cloudwego/hertz) .
+For more benchmark reference [Netpoll-Benchmark][Netpoll-Benchmark]
+, [KiteX-Benchmark][KiteX-Benchmark] and [Hertz-Benchmark][Hertz-Benchmark] .
 
 ### Environment
 
@@ -90,13 +90,37 @@ For more benchmark reference [Netpoll-Benchmark](https://github.com/cloudwego/ne
 
 ### Benchmark Conclusion
 
-Compared with [net](https://github.com/golang/go/tree/master/src/net)
-, [Netpoll](https://github.com/cloudwego/netpoll) latency about 34% and qps about 110%
+Compared with [net][net]
+, [Netpoll][Netpoll] latency about 34% and qps about 110%
 (continue to pressurize, net latency is too high to reference)
 
 # Document
 
-* [Usage](docs/guide/usage.md)
-* [Design](docs/reference/design.md)
+* [Getting Started](docs/guide/guide_en.md)
+* [Design](docs/reference/design_en.md)
 * [Change Log](docs/reference/change_log.md)
-* [Why DATA RACE](docs/reference/explain.md)
+* [Why DATA RACE](docs/reference/explain.md)
+
+[Netpoll]: https://github.com/cloudwego/netpoll
+[net]: https://github.com/golang/go/tree/master/src/net
+[net.Conn]: https://github.com/golang/go/blob/master/src/net/net.go
+[evio]: https://github.com/tidwall/evio
+[gnet]: https://github.com/panjf2000/gnet
+[netty]: https://github.com/netty/netty
+[KiteX]: https://github.com/cloudwego/kitex
+[Hertz]: https://github.com/cloudwego/hertz
+
+[Benchmarks]: https://github.com/cloudwego/netpoll-benchmark
+[Netpoll-Benchmark]: https://github.com/cloudwego/netpoll-benchmark
+[KiteX-Benchmark]: https://github.com/cloudwego/kitex
+[Hertz-Benchmark]: https://github.com/cloudwego/hertz 
+
+[ByteDance]: https://www.bytedance.com
+[Redis]: https://redis.io
+[Haproxy]: http://www.haproxy.org
+
+[LinkBuffer]: nocopy_linkbuffer.go
+[gopool]: https://github.com/bytedance/gopkg/tree/develop/util/gopool
+[mcache]: https://github.com/bytedance/gopkg/tree/develop/lang/mcache
+[multisyscall]: https://github.com/cloudwego/multisyscall
+[io_uring]: https://github.com/axboe/liburing

README_CN.md

@@ -2,45 +2,45 @@
 
 # 简介
 
-[Netpoll](https://github.com/cloudwego/netpoll) 是由 [字节跳动](https://www.bytedance.com) 开发的高性能 NIO(Non-blocking I/O)
+[Netpoll][Netpoll] 是由 [字节跳动][ByteDance] 开发的高性能 NIO(Non-blocking I/O)
 网络库，专注于 RPC 场景。
 
-RPC 通常有较重的处理逻辑，因此无法串行处理 I/O。而 Go 的标准库 [net](https://github.com/golang/go/tree/master/src/net) 设计了 BIO(Blocking I/O) 模式的
+RPC 通常有较重的处理逻辑，因此无法串行处理 I/O。而 Go 的标准库 [net][net] 设计了 BIO(Blocking I/O) 模式的
 API，使得 RPC 框架设计上只能为每个连接都分配一个 goroutine。 这在高并发下，会产生大量的
-goroutine，大幅增加调度开销。此外，[net.Conn](https://github.com/golang/go/blob/master/src/net/net.go) 没有提供检查连接活性的 API，因此 RPC
+goroutine，大幅增加调度开销。此外，[net.Conn][net.Conn] 没有提供检查连接活性的 API，因此 RPC
 框架很难设计出高效的连接池，池中的失效连接无法及时清理。
 
-另一方面，开源社区目前缺少专注于 RPC 方案的 Go 网络库。类似的项目如：[evio](https://github.com/tidwall/evio)
-, [gnet](https://github.com/panjf2000/gnet) 等，均面向 [Redis](https://redis.io), [Haproxy](http://www.haproxy.org) 这样的场景。
+另一方面，开源社区目前缺少专注于 RPC 方案的 Go 网络库。类似的项目如：[evio][evio]
+, [gnet][gnet] 等，均面向 [Redis][Redis], [Haproxy][Haproxy] 这样的场景。
 
-因此 [Netpoll](https://github.com/cloudwego/netpoll) 应运而生，它借鉴了 [evio](https://github.com/tidwall/evio)
-和 [netty](https://github.com/netty/netty) 的优秀设计，具有出色的 [性能](#性能)，更适用于微服务架构。
-同时，[Netpoll](https://github.com/cloudwego/netpoll) 还提供了一些 [特性](#特性)，推荐在 RPC 设计中替代
-[net](https://github.com/golang/go/tree/master/src/net) 。
+因此 [Netpoll][Netpoll] 应运而生，它借鉴了 [evio][evio]
+和 [netty][netty] 的优秀设计，具有出色的 [性能](#性能)，更适用于微服务架构。
+同时，[Netpoll][Netpoll] 还提供了一些 [特性](#特性)，推荐在 RPC 设计中替代
+[net][net] 。
 
-基于 [Netpoll](https://github.com/cloudwego/netpoll) 开发的 RPC 框架 [KiteX](https://github.com/cloudwego/kitex) 和 HTTP
-框架 [Hertz](https://github.com/cloudwego/hertz) (即将开源)，性能均业界领先。
+基于 [Netpoll][Netpoll] 开发的 RPC 框架 [KiteX][KiteX] 和 HTTP
+框架 [Hertz][Hertz] (即将开源)，性能均业界领先。
 
-[范例](https://github.com/cloudwego/netpoll-benchmark) 展示了如何使用 [Netpoll](https://github.com/cloudwego/netpoll)
+[范例][Netpoll-Benchmark] 展示了如何使用 [Netpoll][Netpoll]
 构建 RPC Client 和 Server。
 
 更多信息请参阅 [文档](#文档)。
 
 # 特性
 
 * **已经支持**
-    - [LinkBuffer](nocopy_linkbuffer.go) 提供可以流式读写的 nocopy API
-    - [gopool](https://github.com/bytedance/gopkg/util/gopool) 提供高性能的 goroutine 池
-    - [mcache](https://github.com/bytedance/gopkg/lang/mcache) 提供高效的内存复用
-    - [multisyscall](https://github.com/cloudwego/multisyscall) 支持批量系统调用
+    - [LinkBuffer][LinkBuffer] 提供可以流式读写的 nocopy API
+    - [gopool][gopool] 提供高性能的 goroutine 池
+    - [mcache][mcache] 提供高效的内存复用
     - `IsActive` 支持检查连接是否存活
     - `Dialer` 支持构建 client
     - `EventLoop` 支持构建 server
     - 支持 TCP，Unix Domain Socket
     - 支持 Linux，Mac OS（操作系统）
 
 * **即将开源**
-    - [io_uring](https://github.com/axboe/liburing)
+    - [multisyscall][multisyscall] 支持批量系统调用
+    - [io_uring][io_uring]
     - Shared Memory IPC
     - 串行调度 I/O，适用于纯计算
     - 支持 TLS
@@ -58,11 +58,11 @@ goroutine，大幅增加调度开销。此外，[net.Conn](https://github.com/go
 1. 支持并发请求, 支持超时(1s)
 2. 使用协议: header(4 byte) 表明总长
 
-对比项目为 [net](https://github.com/golang/go/tree/master/src/net), [evio](https://github.com/tidwall/evio)
-, [gnet](https://github.com/panjf2000/gnet) ，我们通过 [测试代码](https://github.com/cloudwego/netpoll-benchmark) 比较了它们的性能。
+对比项目为 [net][net], [evio][evio]
+, [gnet][gnet] ，我们通过 [测试代码][Benchmarks] 比较了它们的性能。
 
-更多测试参考 [Netpoll-Benchmark](https://github.com/cloudwego/netpoll-benchmark)
-, [KiteX-Benchmark](https://github.com/cloudwego/kitex) 和 [Hertz-Benchmark](https://github.com/cloudwego/hertz)
+更多测试参考 [Netpoll-Benchmark][Netpoll-Benchmark]
+, [KiteX-Benchmark][KiteX-Benchmark] 和 [Hertz-Benchmark][Hertz-Benchmark]
 
 ### 测试环境
 
@@ -83,12 +83,36 @@ goroutine，大幅增加调度开销。此外，[net.Conn](https://github.com/go
 
 ### 测试结论
 
-相比 [net](https://github.com/golang/go/tree/master/src/net) ，[Netpoll](https://github.com/cloudwego/netpoll) 延迟约 34%，qps
+相比 [net][net] ，[Netpoll][Netpoll] 延迟约 34%，qps
 约 110%（继续加压 net 延迟过高，数据失真）
 
 # 文档
 
-* [使用文档](docs/guide/usage.md)
-* [设计文档](docs/reference/design.md)
+* [使用文档](docs/guide/guide_cn.md)
+* [设计文档](docs/reference/design_cn.md)
 * [Change Log](docs/reference/change_log.md)
-* [DATA RACE 说明](docs/reference/explain.md)
+* [DATA RACE 说明](docs/reference/explain.md)
+
+[Netpoll]: https://github.com/cloudwego/netpoll
+[net]: https://github.com/golang/go/tree/master/src/net
+[net.Conn]: https://github.com/golang/go/blob/master/src/net/net.go
+[evio]: https://github.com/tidwall/evio
+[gnet]: https://github.com/panjf2000/gnet
+[netty]: https://github.com/netty/netty
+[KiteX]: https://github.com/cloudwego/kitex
+[Hertz]: https://github.com/cloudwego/hertz
+
+[Benchmarks]: https://github.com/cloudwego/netpoll-benchmark
+[Netpoll-Benchmark]: https://github.com/cloudwego/netpoll-benchmark
+[KiteX-Benchmark]: https://github.com/cloudwego/kitex
+[Hertz-Benchmark]: https://github.com/cloudwego/hertz 
+
+[ByteDance]: https://www.bytedance.com
+[Redis]: https://redis.io
+[Haproxy]: http://www.haproxy.org
+
+[LinkBuffer]: nocopy_linkbuffer.go
+[gopool]: https://github.com/bytedance/gopkg/tree/develop/util/gopool
+[mcache]: https://github.com/bytedance/gopkg/tree/develop/lang/mcache
+[multisyscall]: https://github.com/cloudwego/multisyscall
+[io_uring]: https://github.com/axboe/liburing