You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by il...@apache.org on 2021/01/11 10:48:26 UTC
[dubbo-website] branch master updated: add dubbo-go blogs
This is an automated email from the ASF dual-hosted git repository.
iluo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new c9ea8f4 add dubbo-go blogs
c9ea8f4 is described below
commit c9ea8f412df376c7d0c60d6ba9968a4abc9d8bbd
Author: Ian Luo <ia...@gmail.com>
AuthorDate: Mon Jan 11 18:47:58 2021 +0800
add dubbo-go blogs
---
content/zh/blog/news/dubbo-go-first-glance.md | 204 ++++++++++++++++++
content/zh/blog/news/dubbo-go-getty.md | 233 +++++++++++++++++++++
content/zh/blog/news/dubbo-go-grpc.md | 130 ++++++++++++
content/zh/blog/news/dubbo-go-history.md | 134 ++++++++++++
content/zh/blog/news/dubbo-go-intro.md | 159 ++++++++++++++
content/zh/blog/news/dubbo-go-metrics.md | 155 ++++++++++++++
content/zh/blog/news/dubbo-go-tps.md | 219 +++++++++++++++++++
content/zh/blog/news/dubbo-history-gochina.md | 215 +++++++++++++++++++
.../imgs/blog/dubbo-go/busy-idle-time-window.png | Bin 0 -> 32701 bytes
static/imgs/blog/dubbo-go/connected_udp_socket.gif | Bin 0 -> 13891 bytes
static/imgs/blog/dubbo-go/dns_udp.gif | Bin 0 -> 12163 bytes
static/imgs/blog/dubbo-go/dubbo-go-arch.png | Bin 0 -> 382889 bytes
.../blog/dubbo-go/dubbo-go-curcuit-breaker.png | Bin 0 -> 211776 bytes
.../imgs/blog/dubbo-go/dubbo-go-generic-invoke.png | Bin 0 -> 125011 bytes
static/imgs/blog/dubbo-go/dubbo-go-getty.png | Bin 0 -> 215275 bytes
static/imgs/blog/dubbo-go/dubbo-go-hessian2.png | Bin 0 -> 254016 bytes
static/imgs/blog/dubbo-go/dubbo-go-history.png | Bin 0 -> 164989 bytes
static/imgs/blog/dubbo-go/dubbo-go-logo.jpg | Bin 0 -> 142510 bytes
.../imgs/blog/dubbo-go/dubbo-go-roadmap-2019.png | Bin 0 -> 118244 bytes
static/imgs/blog/dubbo-go/dubbo-roadmap-2019.jpg | Bin 0 -> 192191 bytes
static/imgs/blog/dubbo-go/dubbo-tlp-twitter.jpg | Bin 0 -> 299090 bytes
static/imgs/blog/dubbo-go/fixed-window.png | Bin 0 -> 4427 bytes
static/imgs/blog/dubbo-go/go-consumer.png | Bin 0 -> 256195 bytes
static/imgs/blog/dubbo-go/go-provider.png | Bin 0 -> 191597 bytes
static/imgs/blog/dubbo-go/gochina/p1.jpeg | Bin 0 -> 71685 bytes
static/imgs/blog/dubbo-go/gochina/p10.jpeg | Bin 0 -> 35856 bytes
static/imgs/blog/dubbo-go/gochina/p11.jpeg | Bin 0 -> 38227 bytes
static/imgs/blog/dubbo-go/gochina/p12.jpeg | Bin 0 -> 106324 bytes
static/imgs/blog/dubbo-go/gochina/p13.jpeg | Bin 0 -> 65722 bytes
static/imgs/blog/dubbo-go/gochina/p14.jpeg | Bin 0 -> 32546 bytes
static/imgs/blog/dubbo-go/gochina/p15.png | Bin 0 -> 44705 bytes
static/imgs/blog/dubbo-go/gochina/p16.png | Bin 0 -> 56672 bytes
static/imgs/blog/dubbo-go/gochina/p17.jpeg | Bin 0 -> 62079 bytes
static/imgs/blog/dubbo-go/gochina/p18.jpeg | Bin 0 -> 56417 bytes
static/imgs/blog/dubbo-go/gochina/p19.jpeg | Bin 0 -> 56519 bytes
static/imgs/blog/dubbo-go/gochina/p2.jpeg | Bin 0 -> 96715 bytes
static/imgs/blog/dubbo-go/gochina/p20.png | Bin 0 -> 10486 bytes
static/imgs/blog/dubbo-go/gochina/p21.png | Bin 0 -> 42361 bytes
static/imgs/blog/dubbo-go/gochina/p22.jpeg | Bin 0 -> 65540 bytes
static/imgs/blog/dubbo-go/gochina/p23.jpeg | Bin 0 -> 43403 bytes
static/imgs/blog/dubbo-go/gochina/p24.png | Bin 0 -> 26224 bytes
static/imgs/blog/dubbo-go/gochina/p25.jpeg | Bin 0 -> 42221 bytes
static/imgs/blog/dubbo-go/gochina/p26.jpeg | Bin 0 -> 73354 bytes
static/imgs/blog/dubbo-go/gochina/p3.jpeg | Bin 0 -> 37017 bytes
static/imgs/blog/dubbo-go/gochina/p4.jpeg | Bin 0 -> 40387 bytes
static/imgs/blog/dubbo-go/gochina/p5.jpeg | Bin 0 -> 46654 bytes
static/imgs/blog/dubbo-go/gochina/p6.jpeg | Bin 0 -> 34476 bytes
static/imgs/blog/dubbo-go/gochina/p7.jpeg | Bin 0 -> 36259 bytes
static/imgs/blog/dubbo-go/gochina/p8.jpeg | Bin 0 -> 76746 bytes
static/imgs/blog/dubbo-go/gochina/p9.jpeg | Bin 0 -> 69688 bytes
static/imgs/blog/dubbo-go/grpc/p1.webp | Bin 0 -> 19842 bytes
static/imgs/blog/dubbo-go/grpc/p10.webp | Bin 0 -> 20884 bytes
static/imgs/blog/dubbo-go/grpc/p11.webp | Bin 0 -> 19354 bytes
static/imgs/blog/dubbo-go/grpc/p12.webp | Bin 0 -> 2830 bytes
static/imgs/blog/dubbo-go/grpc/p13.webp | Bin 0 -> 8902 bytes
static/imgs/blog/dubbo-go/grpc/p14.webp | Bin 0 -> 22198 bytes
static/imgs/blog/dubbo-go/grpc/p2.webp | Bin 0 -> 14630 bytes
static/imgs/blog/dubbo-go/grpc/p3.webp | Bin 0 -> 22224 bytes
static/imgs/blog/dubbo-go/grpc/p4.webp | Bin 0 -> 13066 bytes
static/imgs/blog/dubbo-go/grpc/p5.webp | Bin 0 -> 25834 bytes
static/imgs/blog/dubbo-go/grpc/p6.webp | Bin 0 -> 12158 bytes
static/imgs/blog/dubbo-go/grpc/p7.webp | Bin 0 -> 11720 bytes
static/imgs/blog/dubbo-go/grpc/p8.webp | Bin 0 -> 27484 bytes
static/imgs/blog/dubbo-go/grpc/p9.webp | Bin 0 -> 6666 bytes
static/imgs/blog/dubbo-go/java-go-interop.png | Bin 0 -> 164979 bytes
static/imgs/blog/dubbo-go/java-provider.png | Bin 0 -> 164952 bytes
static/imgs/blog/dubbo-go/metrics/p1.png | Bin 0 -> 15034 bytes
static/imgs/blog/dubbo-go/metrics/p10.webp | Bin 0 -> 33662 bytes
static/imgs/blog/dubbo-go/metrics/p11.webp | Bin 0 -> 10544 bytes
static/imgs/blog/dubbo-go/metrics/p12.webp | Bin 0 -> 18466 bytes
static/imgs/blog/dubbo-go/metrics/p2.webp | Bin 0 -> 7708 bytes
static/imgs/blog/dubbo-go/metrics/p3.webp | Bin 0 -> 35842 bytes
static/imgs/blog/dubbo-go/metrics/p4.webp | Bin 0 -> 8384 bytes
static/imgs/blog/dubbo-go/metrics/p5.webp | Bin 0 -> 10720 bytes
static/imgs/blog/dubbo-go/metrics/p6.webp | Bin 0 -> 6138 bytes
static/imgs/blog/dubbo-go/metrics/p7.webp | Bin 0 -> 16428 bytes
static/imgs/blog/dubbo-go/metrics/p8.webp | Bin 0 -> 6248 bytes
static/imgs/blog/dubbo-go/metrics/p9.webp | Bin 0 -> 12390 bytes
static/imgs/blog/dubbo-go/sliding-window.png | Bin 0 -> 5433 bytes
static/imgs/blog/dubbo-go/tps-limit-filter.png | Bin 0 -> 64912 bytes
static/imgs/blog/dubbo-go/tps-limiter.png | Bin 0 -> 30601 bytes
81 files changed, 1449 insertions(+)
diff --git a/content/zh/blog/news/dubbo-go-first-glance.md b/content/zh/blog/news/dubbo-go-first-glance.md
new file mode 100644
index 0000000..62e3f6c
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-first-glance.md
@@ -0,0 +1,204 @@
+---
+title: "Dubbo Go 踩坑记"
+linkTitle: "Dubbo Go 踩坑记"
+date: 2021-01-11
+description: 本文记录了一个用户第一次接入 Dubbo Go 的体验
+---
+
+## 扯淡
+
+### 前尘
+
+由于我的一个项目需要做公司用户鉴权，而组内其他小伙伴刚好有一个 *dubbo* 的鉴权 *rpc* ，一开始我是打算直接的读 *redis* 数据然后自己做解密。工作进行到一半，由于考虑到如果以后这个服务有任何变动，我这边要有联动行为，所以改用 *go* 来调用 *dubbo* 的 *rpc* ，于是我在 *github* 上找到了 [雨神](https://github.com/AlexStocks) 的 [dubbogo](https://github.com/AlexStocks/dubbogo) (PS: 这个是 *dubbo-go* 前身)。不得不说，雨神是热心的人儿啊，当时还帮着我调试代码。最后也是接入了一个阉割版的吧，主要是当时 *hessian2* 对泛型支持的不怎么好。
+
+### 现在
+
+目前 [dubbo-go](https://github.com/apache/dubbo-go)隶属于 *apache* 社区，相比以前做了部分重构，并且维护也很活跃了。
+
+## 接入
+
+### 问题
+
+目前整个项目在快速的迭代中，很多功能还没有完善，维护人员还没有时间来完善文档，所以在接入的时候要自己看源码或调试。
+
+### 说明
+
+目前我司在使用 *dubbo* 的过程使用的 *zookeeper* 作为注册中心，序列化是 *hessian2* ，所以我们要做如下初始化：
+
+```golang
+ import (
+ _ "github.com/apache/dubbo-go/common/proxy/proxy_factory"
+ _ "github.com/apache/dubbo-go/registry/protocol"
+
+ _ "github.com/apache/dubbo-go/filter/impl"
+
+ _ "github.com/apache/dubbo-go/cluster/cluster_impl"
+ _ "github.com/apache/dubbo-go/cluster/loadbalance"
+ _ "github.com/apache/dubbo-go/registry/zookeeper"
+ )
+```
+
+### 配置
+
+由于我是接入客户端，所以我这边只配置了 *ConsumerConfig* 。
+
+```yaml
+dubbo:
+ # client
+ request_timeout: "3s"
+ # connect timeout
+ connect_timeout: "3s"
+ check: true
+ application:
+ organization: "dfire.com"
+ name: "soa.sso.ITokenService"
+ module: "dubbogo token service client"
+ version: "1.0.0"
+ owner: "congbai"
+ registries:
+ "hangzhouzk":
+ protocol: "zookeeper"
+ timeout: "3s"
+ address: "zk1.2dfire-daily.com:2181"
+ username: ""
+ password: ""
+ references:
+ "ITokenService":
+ registry: "hangzhouzk"
+ protocol: "dubbo"
+ interface: "com.dfire.soa.sso.ITokenService"
+ version: "1.0.0"
+ methods:
+ - name: "validate"
+ retries: "3"
+```
+
+我这里是把 *dubbo-go* 作为第三方库来用，所以我没使用官方 [dubbo-samples](https://github.com/dubbogo/dubbo-samples/golang) 那样在 *init* 函数中读入配置。
+
+配置代码如下：
+
+```golang
+ import (
+ "github.com/apache/dubbo-go/config"
+ "github.com/apache/dubbo-go/protocol/dubbo"
+ )
+
+ type DubboCli struct {
+ }
+
+ func NewCli(cconf config.ConsumerConfig) *DubboCli {
+ config.SetConsumerConfig(cconf)
+
+ dubbo.SetClientConf(dubbo.GetDefaultClientConfig())
+
+ config.Load()
+
+ return &DubboCli{}
+ }
+```
+
+### 接入
+
+好了，配置加载完就说明我们的准备工作已经做好了，接下来就要接入 *rpc* 接口了。
+
+#### 返回值
+
+一般 *rpc* 调用的返回值都是自定义的，所以我们也要告诉 *dubbo-go* 长什么样子。这个结构体要跟 *java* 的类对应起来，这里我们是要实现 *hessian2* 的 *interface* :
+
+```golang
+// POJO interface
+// !!! Pls attention that Every field name should be upper case.
+// Otherwise the app may panic.
+type POJO interface {
+ JavaClassName() string // got a go struct's Java Class package name which should be a POJO class.
+}
+```
+
+我的实现如下：
+
+```golang
+type Result struct {
+ Model interface{} `json:"model,omitempty"`
+ Models []interface{} `json:"models,omitempty"`
+ ResultCode string `json:"resultCode"`
+ Success bool `json:"success"`
+ Message string `json:"message"`
+ TotalRecord int `json:"totalRecord"`
+}
+
+func (r Result) JavaClassName() string {
+ return "com.twodfire.share.result.ResultSupport"
+}
+```
+
+这里的 *JavaClassName* 接口的意义就如函数签名一样，返回的就是 *java* 的类名。
+
+#### 接口
+
+要想调用 *dubbo* 的接口就必须实现下面这个 *interface*
+
+```golang
+// rpc service interface
+type RPCService interface {
+ Reference() string // rpc service id or reference id
+}
+```
+
+所以我需要构造一个 *struct* 来做这个事情，比如：
+
+```golang
+type ITokenService struct {
+ Validate func(ctx context.Context, req []interface{}, resp *Result) error `dubbo:"validate"`
+}
+
+func (i *ITokenService) Reference() string {
+ return "ITokenService"
+}
+```
+
+这个结构体一般是不会有什么数据成员。
+
+这里我们注意到 *Validate* 函数声明后面跟的 *dubbo tag* ，这个是为如果 *rpc* 名称的首字母是小写（比如我要调用的 *dubbo* 接口就是 *validate* )准备的 *MethodMapper* ，类似于 *json* 的映射 *tag* 功效。一开始我就是遇到这个坑，我按官方的例子实现，日志一直说找不到接口，后来我也在官方群里询问大佬才知道有这个功能。
+
+#### 注册
+
+好了，上面的准备全部完成后，我们要做最后一步，那就是告诉 *dubbo-go* 我们想要的是什么。代码如下：
+
+```golang
+ import (
+ hessian "github.com/apache/dubbo-go-hessian2"
+ "github.com/apache/dubbo-go/config"
+ )
+
+ var tokenProvider = new(ITokenService)
+
+ func init() {
+ config.SetConsumerService(tokenProvider)
+ hessian.RegisterPOJO(&Result{})
+ }
+```
+
+#### 调用
+
+接下来我们就可以完成我们的 *DubboCli* 接口了，代码如下：
+
+```golang
+func (d *DubboCli) CheckUser(token, app string) (bool, error) {
+ args := []interface{}{token, app}
+ resp := &Result{}
+
+ if err := tokenProvider.Validate(context.Background(), args, resp); err != nil {
+ return false, err
+ }
+ if resp.Success {
+ return resp.Success, nil
+ }
+ return resp.Success, errors.New(resp.Message)
+}
+```
+
+好了，至此我们就完成了 *dubbo-go* 的全部接入工作。 Happy Coding...
+
+## 写在最后
+
+其实代码格式这个问题，我在接入的时候跟官方群里的维护者大佬提过，使用 *go* 官方的代码格式工具 [goimports](https://github.com/golang/tools/tree/master/cmd/goimports) 来统一代码格式，这 样对于维护者以外的人提 *PR* 也是有利。我在接入的过程中遇到一个 *bug* ，我反馈给雨神，他就让我提了个 *PR* ，在整个过程就是这个 代码格式的问题，导致我反复的修改代码。
\ No newline at end of file
diff --git a/content/zh/blog/news/dubbo-go-getty.md b/content/zh/blog/news/dubbo-go-getty.md
new file mode 100644
index 0000000..3b87e77
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-getty.md
@@ -0,0 +1,233 @@
+---
+title: "Dubbo Go Getty 开发日志"
+linkTitle: "getty 开发日志"
+date: 2021-01-11
+description: 本文记录了于雨开发 dubbo-go 网络库 getty 的历程
+---
+
+### 0 说明
+
+[getty][3]是一个go语言实现的网络层引擎，可以处理TCP/UDP/websocket三种网络协议。
+
+2016年6月我在上海做一个即时通讯项目时，接口层的底层网络驱动是当时的同事[sanbit](https://github.com/sanbit)写的，原始网络层实现了TCP
+Server，其命名规范学习了著名的netty。当时这个引擎比较简洁，随着我对这个项目的改进这个网络层引擎也就随之进化了（添加了TCP Client、抽象出了 TCP connection 和 TCP
+session），至2016年8月份（又添加了websocket）其与原始实现已经大异其趣了，征得原作者和相关领导同意后就放到了github上。
+
+将近两年的时间我不间断地对其进行改进，年齿渐增但记忆速衰，觉得有必要记录下一些开发过程中遇到的问题以及解决方法，以备将来回忆之参考。
+
+### 1 UDP connection
+
+2018年3月5日 起给 getty 添加了UDP支持。
+
+#### 1.1 UDP connect
+
+UDP自身分为unconnected UDP和connected UDP两种，connected UDP的底层原理见下图。
+
+
+
+当一端的UDP endpoint调用connect之后，os就会在内部的routing table上把udp socket和另一个endpoint的地址关联起来，在发起connect的udp
+endpoint端建立起一个单向的连接四元组：发出的datagram packet只能发往这个endpoint（不管sendto的时候是否指定了地址）且只能接收这个endpoint发来的udp datagram
+packet（如图???发来的包会被OS丢弃）。
+
+UDP endpoint发起connect后，OS并不会进行TCP式的三次握手，操作系统共仅仅记录下UDP socket的peer udp endpoint 地址后就理解返回，仅仅会核查对端地址是否存在网络中。
+
+至于另一个udp endpoint是否为connected udp则无关紧要，所以称udp connection是单向的连接。如果connect的对端不存在或者对端端口没有进程监听，则发包后对端会返回ICMP “port
+unreachable” 错误。
+
+如果一个POSIX系统的进程发起UDP write时没有指定peer UDP address，则会收到ENOTCONN错误，而非EDESTADDRREQ。
+
+
+
+一般发起connect的为 UDP client，典型的场景是DNS系统，DNS client根据/etc/resolv.conf里面指定的DNS server进行connect动作。
+
+至于 UDP server 发起connect的情形有 TFTP，UDP client 和 UDP server 需要进行长时间的通信， client 和 server 都需要调用 connect 成为 connected UDP。
+
+如果一个 connected UDP 需要更换 peer endpoint address，只需要重新 connect 即可。
+
+#### 1.2 connected UDP 的性能
+
+connected UDP 的优势详见参考文档1。假设有两个 datagram 需要发送，unconnected UDP 的进行 write 时发送过程如下：
+
+* Connect the socket
+* Output the first datagram
+* Unconnect the socket
+* Connect the socket
+* Output the second datagram
+* Unconnect the socket
+
+每发送一个包都需要进行 connect，操作系统到 routine table cache 中判断本次目的地地址是否与上次一致，如果不一致还需要修改 routine table。
+
+connected UDP 的两次发送过程如下：
+
+* Connect the socket
+* Output first datagram
+* Output second datagram
+
+这个 case 下，内核只在第一次设定下虚拟链接的 peer address，后面进行连续发送即可。所以 connected UDP 的发送过程减少了 1/3 的等待时间。
+
+2017年5月7日 我曾用 [python 程序](https://github.com/alexStocks/python-practice/blob/master/tcp_udp_http_ws/udp/client.py)
+对二者之间的性能做过测试，如果 client 和 server 都部署在本机，测试结果显示发送 100 000 量的 UDP datagram packet 时，connected UDP 比 unconnected UDP 少用了 2
+/ 13 的时间。
+
+这个测试的另一个结论是：不管是 connected UDP 还是 unconnected UDP，如果启用了 SetTimeout，则会增大发送延迟。
+
+#### 1.3 Go UDP
+
+Go 语言 UDP 编程也对 connected UDP 和 unconnected UDP 进行了明确区分，参考文档2 详细地列明了如何使用相关
+API，根据这篇文档个人也写一个 [程序](https://github.com/alexstocks/go-practice/blob/master/udp-tcp-http/udp/connected-udp.go) 测试这些
+API，测试结论如下：
+
+* connected UDP 读写方法是 Read 和 Write；
+* unconnected UDP 读写方法是 ReadFromUDP 和 WriteToUDP（以及 ReadFrom 和 WriteTo)；
+* unconnected UDP 可以调用 Read，只是无法获取 peer addr；
+* connected UDP 可以调用 ReadFromUDP（填写的地址会被忽略）
+* connected UDP 不能调用 WriteToUDP，”即使是相同的目标地址也不可以”，否则会得到错误 “use of WriteTo with pre-connected connection”；
+* unconnected UDP 不能调用 Write, “因为不知道目标地址”, error:”write: destination address requiredsmallnestMBP:udp smallnest”；
+* connected UDP 可以调用 WriteMsgUDP，但是地址必须为 nil；
+* unconnected UDP 可以调用 WriteMsgUDP，但是必须填写 peer endpoint address。
+
+综上结论，读统一使用 ReadFromUDP，写则统一使用 WriteMsgUDP。
+
+#### 1.4 Getty UDP
+
+版本 v0.8.1 Getty 中添加 connected UDP 支持时，其连接函数 [dialUDP](https://github.com/alexstocks/getty/blob/master/client.go#L141)
+这是简单调用了 net.DialUDP 函数，导致昨日（20180318 22:19 pm）测试的时候遇到一个怪现象：把 peer UDP endpoint 关闭，local udp endpoint 进行 connect 时
+net.DialUDP 函数返回成功，然后 lsof 命令查验结果时看到确实存在这个单链接：
+
+ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
+ echo_clie 31729 alex 9u IPv4 0xa5d288135c97569d 0t0 UDP localhost:63410->localhost:10000
+
+然后当 net.UDPConn 进行 read 动作的时候，会得到错误 “read: connection refused”。
+
+于是模仿C语言中对 TCP client connect 成功与否判断方法，对 [dialUDP](https://github.com/alexstocks/getty/blob/master/client.go#L141) 改进如下：
+
+* net.DialUDP 成功之后，判断其是否是自连接，是则退出；
+* connected UDP 向对端发送一个无用的 datagram packet【”ping”字符串，对端会因其非正确 datagram 而丢弃】，失败则退出；
+* connected UDP 发起读操作，如果对端返回 “read: connection refused” 则退出，否则就判断为 connect 成功。
+
+### 2 Compression
+
+去年给 getty 添加了 TCP/Websocket compression 支持，Websocket
+库使用的是 [gorilla/websocket](https://github.com/gorilla/websocket/)，[Go
+官网](https://godoc.org/golang.org/x/net/websocket)也推荐这个库，因为自 `This package("golang.org/x/net/websocket") currently lacks some features`
+。
+
+#### 2.1 TCP compression
+
+最近在对 Websocket compression 进行测试的时候，发现 CPU 很容易就跑到 100%，且程序启动后很快就 panic 退出了。
+
+根据 panic 信息提示查到 [gorilla/websocket/conn.go:ReadMsg](https://github.com/gorilla/websocket/blob/master/conn.go#L1018)
+函数调用 [gorilla/websocket/conn.go:NextReader](https://github.com/gorilla/websocket/blob/master/conn.go#L928) 后就立即 panic
+退出了。panic 的 `表层原因` 到是很容易查明：
+
+* [gorrilla/websocket:Conn::advanceFrame](https://github.com/gorilla/websocket/blob/master/conn.go#L768) 遇到读超时错误（io
+ timeout）;
+* [gorrilla/websocket:ConnConn.readErr](https://github.com/gorilla/websocket/blob/master/conn.go#L941)记录这个error；
+* [gorilla/websocket/conn.go:Conn::NextReader](https://github.com/gorilla/websocket/blob/master/conn.go#L959)开始读取之前则[检查这个错误](https://github.com/gorilla/websocket/blob/master/conn.go#L938)，如以前发生过错误则不再读取
+ websocket
+ frame，并对[gorrilla/websocket:ConnConn.readErr累积计数](https://github.com/gorilla/websocket/blob/master/conn.go#L957)；
+* [当gorrilla/websocket:ConnConn.readErr数值大于 1000](https://github.com/gorilla/websocket/blob/master/conn.go#L958)
+ 的时候，程序就会panic 退出。
+
+但是为何发生读超时错误则毫无头绪。
+
+2018/03/07 日测试 TCP compression 的时候发现启动 compression 后，程序 CPU 也会很快跑到
+100%，进一步追查后发现函数 [getty/conn.go:gettyTCPConn::read](https://github.com/alexstocks/getty/blob/master/conn.go#L228) 里面的 log
+有很多 “io timeout” error。当时查到这个错误很疑惑，因为我已经在 TCP read 之前进行了超时设置【SetReadDeadline】，难道启动 compression
+会导致超时设置失效使得socket成了非阻塞的socket？
+
+于是在 [getty/conn.go:gettyTCPConn::read](https://github.com/alexstocks/getty/blob/master/conn.go#L228) 中添加了一个逻辑：启用 TCP
+compression 的时不再设置超时时间【默认情况下tcp connection是永久阻塞的】，CPU 100% 的问题很快就得到了解决。
+
+至于为何 `启用 TCP compression 会导致 SetDeadline 失效使得socket成了非阻塞的socket`，囿于个人能力和精力，待将来追查出结果后再在此补充之。
+
+#### 2.2 Websocket compression
+
+TCP compression 的问题解决后，个人猜想 Websocket compression
+程序遇到的问题或许也跟 `启用 TCP compression 会导致 SetDeadline 失效使得socket成了非阻塞的socket` 有关。
+
+于是借鉴 TCP 的解决方法，在 [getty/conn.go:gettyWSConn::read](https://github.com/alexstocks/getty/blob/master/conn.go#L527)
+直接把超时设置关闭，然后 CPU 100% 被解决，且程序运转正常。
+
+### <a name="3">3 unix socket</a>
+
+本节与 getty 无关，仅仅是在使用 unix socket 过程中遇到一些 keypoint 的记录。
+
+#### 3.1 reliable
+
+unix socket datagram 形式的包也是可靠的，每次写必然要求对应一次读，否则写方会被阻塞。如果是 stream 形式，则 buffer 没有满之前，写者是不会被阻塞的。datagram 的优势在于 api 简单。
+
+> Unix sockets are reliable. If the reader doesn't read, the writer blocks. If the socket is a datagram socket, each write is paired with a read. If the socket is a stream socket, the kernel may buffer some bytes between the writer and the reader, but when the buffer is full, the writer will block. Data is never discarded, except for buffered data if the reader closes the connection before reading the buffer. ---[Do UNIX Domain Sockets Overflow?](https://unix.stackexchange.com/questions/ [...]
+
+> On most UNIX implementations, UNIX domain datagram sockets are always reliable and don't reorder datagrams. ---[man 7 socketpair](http://www.man7.org/linux/man-pages/man7/unix.7.html)
+
+
+#### 3.2 buffer size
+
+datagram 形式的 unix socket 的单个 datagram 包最大长度是 130688 B。
+
+> AF_UNIX SOCK_DATAGRAM/SOCK_SEQPACKET datagrams need contiguous memory. Contiguous physical memory is hard to find, and the allocation fails. The max size actually is 130688 B. --- [the max size of AF_UNIX datagram message that can be sent in linux](https://stackoverflow.com/questions/4729315/what-is-the-max-size-of-af-unix-datagram-message-that-can-be-sent-in-linux)
+
+
+> It looks like AF_UNIX sockets don't support scatter/gather on current Linux. it is a fixed size 130688 B. --- [Difference between UNIX domain STREAM and DATAGRAM sockets?](https://stackoverflow.com/questions/13953912/difference-between-unix-domain-stream-and-datagram-sockets)
+
+
+### <a name="4">4 Goroutine Pool</a>
+
+随着 [dubbogo/getty][1] 被 [apache/dubbo-go][2] 用作底层 tcp 的 transport 引擎，处于提高系统吞吐的需要，[dubbogo/getty][1] 面临着下一步的进化要求：[**针对
+dubbo-go 和 Getty 的网络 I/O 与线程派发这一部分进行进一步优化**][4]。其中的关键就是添加 Goroutine Pool【下文简称 gr pool】，以分离网络 I/O 和 逻辑处理。
+
+Gr Pool 成员有任务队列【其数目为 M】和 Gr 数组【其数目为 N】以及任务【或者称之为消息】，根据 N 的数目变化其类型分为可伸缩与固定大小，可伸缩 Gr Pool 好处是可以随着任务数目变化增减 N 以节约 CPU
+和内存资源，但一般不甚常用，比人以前撸过一个后就躺在我的 [github repo][5] 里面了。
+
+[dubbogo/getty][1] 只关注 N 值固定大小的 gr pool，且不考虑收到包后的处理顺序。譬如，[dubbogo/getty][1] 服务端收到了客户端发来的 A 和 B 两个网络包，不考虑处理顺序的 gr pool
+模型可能造成客户端先收到 B 包的 response，后才收到 A 包的 response。
+
+如果客户端的每次请求都是独立的，没有前后顺序关系，则带有 gr pool 特性的 [dubbogo/getty][1] 不考虑顺序关系是没有问题的。如果上层用户关注 A 和 B 请求处理的前后顺序，则可以把 A 和 B
+两个请求合并为一个请求，或者把 gr pool 特性关闭。
+
+### <a name="4.1">4.1 固定大小 Gr Pool</a>
+
+按照 M 与 N 的比例，固定大小 Gr Pool 又区分为 1:1、1:N、M:N 三类。
+
+1:N 类型的 Gr Pool 最易实现，个人 2017 年在项目 [kafka-connect-elasticsearch][6] 中实现过此类型的 [Gr Pool][7]：作为消费者从 kafka 读取数据然后放入消息队列，然后各个
+worker gr 从此队列中取出任务进行消费处理。
+
+向 [dubbogo/getty][1] 中添加 gr pool 时也曾实现过这个版本的 [gr pool][8]。这种模型的 gr pool 整个 pool 只创建一个 chan， 所有 gr 去读取这一个
+chan，其缺点是：队列读写模型是 一写多读，因为 go channel 的低效率【整体使用一个 mutex lock】造成竞争激烈，当然其网络包处理顺序更无从保证。
+
+[dubbogo/getty][1] 初始版本的 [gr pool][9] 模型为 1:1，每个 gr 多有自己的 chan，其读写模型是一写一读，其优点是可保证网络包处理顺序性， 如读取 kafka 消息时候，按照 kafka
+message 的 key 的 hash 值以取余方式【hash(message key) % N】将其投递到某个 task queue，则同一 key 的消息都可以保证处理有序。但 [望哥](10)
+指出了这种模型的缺陷：每个task处理要有时间，此方案会造成某个 gr 的 chan 里面有 task 堵塞，就算其他 gr 闲着，也没办法处理之【任务处理“饥饿”】。
+
+[wenwei86][12] 给出了更进一步的 1:1 模型的改进方案：每个 gr 一个 chan，如果 gr 发现自己的 chan 没有请求，就去找别的 chan，发送方也尽量发往消费快的协程。这个方案类似于 go runtime 内部的
+MPG 调度算法，但是对我个人来说算法和实现均太复杂，故而没有采用。
+
+[dubbogo/getty][1] 目前采用了 M:N 模型版本的 [gr pool][11]，每个 task queue 被 N/M 个 gr 消费，这种模型的优点是兼顾处理效率和锁压力平衡，可以做到总体层面的任务处理均衡。此版本下
+Task 派发采用 RoundRobin 方式。
+
+## 总结
+
+本文总结了 [getty][3] 近期开发过程中遇到的一些问题，囿于个人水平只能给出目前自认为最好的解决方法【如何你有更好的实现，请留言】。
+
+随着 [getty][3] 若有新的 improvement 或者新 feature，我会及时补加此文。
+
+此记。
+
+## 参考文档
+
+1. [connect Function with UDP](http://www.masterraghu.com/subjects/np/introduction/unix_network_programming_v1.3/ch08lev1sec11.html)
+2. [深入Go UDP编程](http://colobu.com/2016/10/19/Go-UDP-Programming/)
+
+[1]:https://github.com/dubbogo/getty
+[2]:https://github.com/apache/dubbo-go/
+[3]:https://github.com/alexstocks/getty
+[4]:https://www.oschina.net/question/3820517_2306822
+[5]:https://github.com/alexstocks/goext/blob/master/sync/pool/worker_pool.go
+[6]:https://github.com/AlexStocks/kafka-connect-elasticsearch
+[7]:https://github.com/AlexStocks/kafka-connect-elasticsearch/blob/master/app/worker.go
+[8]:https://github.com/dubbogo/getty/pull/6/commits/4b32c61e65858b3eea9d88d8f1c154ab730c32f1
+[9]:https://github.com/dubbogo/getty/pull/6/files/c4d06e2a329758a6c65c46abe464a90a3002e428#diff-9922b38d89e2ff9f820f2ce62f254162
+[10]:https://github.com/wongoo
+[11]:https://github.com/dubbogo/getty/pull/6/commits/1991056b300ba9804de0554dbb49b5eb04560c4b
+[12]:https://github.com/wenweihu86
diff --git a/content/zh/blog/news/dubbo-go-grpc.md b/content/zh/blog/news/dubbo-go-grpc.md
new file mode 100644
index 0000000..195f522
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-grpc.md
@@ -0,0 +1,130 @@
+---
+title: "无缝衔接 gRPC 与 dubbo-go"
+linkTitle: "无缝衔接 gRPC 与 dubbo-go"
+date: 2021-01-11
+description: 本文介绍了如何在 dubbo go 中如何支持 gRPC
+---
+
+最近我们 dubbo-go 社区里面，呼声很大的一个 feature 就是对 gRPC 的支持。在某位大佬的不懈努力之下，终于弄出来了。
+
+今天我就给大家分析一下大佬是怎么连接 dubbo-go 和 gRPC 。
+
+## gRPC
+
+先来简单介绍一下 gRPC 。它是 Google 推出来的一个 RPC 框架。gRPC是通过 IDL ( Interface Definition Language )——接口定义语言——编译成不同语言的客户端来实现的。可以说是RPC理论的一个非常非常标准的实现。
+
+因而 gRPC 天然就支持多语言。这几年，它几乎成为了跨语言 RPC 框架的标准实现方式了，很多优秀的rpc框架，如 Spring Cloud 和 dubbo ，都支持 gRPC 。
+
+server 端
+
+在 Go 里面，server 端的用法是：
+
+
+
+它的关键部分是：s := grpc.NewServer()和pb.RegisterGreeterServer(s, &server{})两个步骤。第一个步骤很容易，唯独第二个步骤RegisterGreeterServer有点麻烦。为什么呢？
+
+因为pb.RegisterGreeterServer(s, &server{})这个方法是通过用户定义的protobuf编译出来的。
+
+好在，这个编译出来的方法，本质上是：
+
+
+
+也就是说，如果我们在 dubbo-go 里面拿到这个 _Greeter_serviceDesc ，就可以实现这个 server 的注册。因此，可以看到，在 dubbo-go 里面，要解决的一个关键问题就是如何拿到这个 serviceDesc 。
+
+## Client 端
+
+Client 端的用法是：
+
+
+
+这个东西要复杂一点：1、创建连接：conn, err := grpc.Dial(address)2、创建client：c := pb.NewGreeterClient(conn)3、调用方法：r, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})
+
+第一个问题其实挺好解决的，毕竟我们可以从用户的配置里面读出 address ；
+
+第二个问题就是最难的地方了。如同 RegisterGreeterServer 是被编译出来的那样，这个 NewGreeterClient 也是被编译出来的。
+
+而第三个问题，乍一看是用反射就能解决，但是我们打开 SayHello 就能看到：
+
+
+
+结合 greetClient 的定义，很容易看到，我们的关键就在于 err := c.cc.Invoke ( ctx, "/helloworld.Greeter/SayHello", in, out, opts... )。换言之，我们只需要创建出来连接，并且拿到方法、参数就能通过类似的调用来模拟出 c.SayHello 。
+
+通过对 gRPC 的简单分析，我们大概知道要怎么弄了。还剩下一个问题，就是我们的解决方案怎么和 dubbo-go 结合起来呢？
+
+## 设计
+
+我们先来看一下 dubbo-go 的整体设计，思考一下，如果我们要做 gRPC 的适配，应该是在哪个层次上做适配。
+
+
+
+我们根据前面介绍的 gRPC 的相关特性可以看出来，gRPC 已经解决了 codec 和 transport 两层的问题。
+
+而从 cluster 往上，显然 gRPC 没有涉及。于是，从这个图里面我们就可以看出来，要做这种适配，那么 protocol 这一层是最合适的。即，我们可以如同 dubbo protocol 那般，扩展出来一个 grpc protocol 。
+
+这个 gRPC protocol 大体上相当于一个适配器，将底层的 gRPC 的实现和我们自身的 dubbo-go 连接在一起。
+
+
+
+## 实现
+
+在 dubbo-go 里面，和 gRPC 相关的主要是：
+
+
+
+我们直接进去看看在 gRPC 小节里面提到的要点是如何实现的。
+
+### server端
+
+
+
+这样看起来，还是很清晰的。如同 dubbo- go 其它的 protocol 一样，先拿到 service ，而后通过 service 来拿到 serviceDesc ，完成服务的注册。
+
+注意一下上图我红线标准的 ds, ok := service.(DubboGrpcService) 这一句。
+
+为什么我说这个地方有点奇怪呢？是因为理论上来说，我们这里注册的这个 service 实际上就是 protobuf 编译之后生成的 gRPC 服务端的那个 service ——很显然，单纯的编译一个 protobuf 接口，它肯定不会实现 DubboGrpcService 接口：
+
+
+
+那么 ds, ok := service.(DubboGrpcService) 这一句，究竟怎么才能让它能够执行成功呢？
+
+我会在后面给大家揭晓这个谜底。
+
+## Client端
+
+dubbo-go 设计了自身的 Client ，作为对 gRPC 里面 Client 的一种模拟与封装：
+
+
+
+注意看，这个 Client 的定义与前面 greetClient 的定义及其相似。再看下面的 NewClient 方法，里面也无非就是创建了连接 conn ，而后利用 conn 里创建了一个 Client 实例。
+
+注意的是，这里面维护的 invoker 实际上是一个 stub 。
+
+当真正发起调用的时候：
+
+
+
+红色框框框住的就是关键步骤。利用反射从 invoker ——也就是 stub ——里面拿到调用的方法，而后通过反射调用。
+
+### 代码生成
+
+前面提到过 ds, ok := service.(DubboGrpcService) 这一句，面临的问题是如何让 protobuf 编译生成的代码能够实现 DubboGrpcService 接口呢？
+
+有些小伙伴可能也注意到，在我贴出来的一些代码里面，反射操作会根据名字来获取method实例，比如NewClient方法里面的method := reflect.ValueOf(impl).MethodByName("GetDubboStub")这一句。这一句的impl，即指服务的实现，也是 protobuf 里面编译出来的，怎么让 protobuf 编译出来的代码里面含有这个 GetDubboStub 方法呢？
+
+到这里，答案已经呼之欲出了：修改 protobuf 编译生成代码的逻辑！
+
+庆幸的是，在 protobuf 里面允许我们通过插件的形式扩展我们自己的代码生成的逻辑。
+
+所以我们只需要注册一个我们自己的插件：
+
+
+
+然后这个插件会把我们所需要的代码给嵌入进去。比如说嵌入GetDubboStub方法：
+
+
+
+还有DubboGrpcService接口：
+
+
+
+这个东西，属于难者不会会者不难。就是如果你不知道可以通过plugin的形式来修改生成的代码，那就是真难；但是如果知道了，这个东西就很简单了——无非就是水磨工夫罢了。
\ No newline at end of file
diff --git a/content/zh/blog/news/dubbo-go-history.md b/content/zh/blog/news/dubbo-go-history.md
new file mode 100644
index 0000000..f05e644
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-history.md
@@ -0,0 +1,134 @@
+---
+title: "Dubbo Go 的前世今生"
+linkTitle: "Dubbo Go 的前世今生"
+date: 2021-01-11
+description: 本文记录了 Dubbo Go 的发展历程
+---
+
+
+
+dubbo-go 是目前 Dubbo 多语言生态最火热的项目。dubbo-go 最早的版本应该要追溯到 2016 年，由社区于雨同学编写 dubbo-go 的初版。当时很多东西没有现成的轮子，如 Go 语言没有像 netty 一样的基于事件的网络处理引擎、 hessian2 协议没有 Go 语言版本实现，加上当时 Dubbo 也没有开始重新维护。所以从协议库到网络引擎，再到上层 dubbo-go ，其实都是从零开始写的。
+
+在 2018 年，携程开始做 Go 语言的一些中间件以搭建内部的 Go 语言生态，需要有一个 Go 的服务框架可以与携程的现有 dubbo soa 生态互通。所以由我负责重构了 dubbo－go 并开源出这个版本。当时调研了很多开源的 Go 语言服务框架，当时能够支持 hessian2 协议的并跟 Dubbo 可以打通的仅找到了当时于雨写的 dubbo-go 早期版本。由于携程对社区版本的 Dubbo 做了挺多的扩展，源于对扩展性的需求我们 Go 语言版本需要一个更易于扩展的版本，加上当时这个版本本身的功能也比较简单，所以我们找到了作者合作重构了一个更好的版本。经过了大半年时间，在上图第三阶段 19 年 6 月的时候，基本上已经把 dubbo-go 重构了一遍，总体的思路是参考的 Dubbo 整体的代码架构，用Go语言完全重写了一个完整的具备服务端跟消费端的 Golang rpc/ 微服务框架。
+
+后来我们将重构后的版本 dubbo-go 1.0 贡献给 Apache 基金会，到现在已经过去了两个多月的时间，近期社区发布了1.1版本。目前为止，已经有包括携程在内的公司已经在生产环境开始了试用和推广。
+
+### Start dubbo-go
+
+现在的 dubbo-go 已经能够跟 Java 版本做比较好的融合互通，同时 dubbo-go 自身也是一个完成的 Go 语言 rpc/ 微服务框架，它也可以脱离 java dubbo 来独立使用。
+
+这边简单介绍一下用法，写一个 hello world 的例子。
+
+
+
+上图是一个简单的 java service ，注册为一个 Dubbo 服务，是一个简单的获取用户信息的例子。
+
+
+
+上图是 dubbo-go 的客户端，来订阅和调用这个 Java 的 Dubbo 服务。Go 语言客户端需要显式调用 SetConsumerService 来注册需要订阅的服务，然后通过调用 dubbo-go-hessian2 库的 registerPOJO 方法来注册 user 对象，做 Java 和 Go 语言之间的自定义 pojo 类型转换。具体的服务调用方法就是声明一个的 GetUser 闭包，便可直接调用。
+
+
+
+上图，同样的可以基于 dubbo-go 发布一个 GetUser 的服务端，使用方式类似，发布完后可以被 dubbo java 的客户端调用。
+
+
+
+如上图所示，现在已经做到了这样一个程度，同样一份 dubbo-go 客户端代码，可以去调用 dubbo-go 的服务端，也可以去调用 Dubbo Java 的服务端；同样一份 dubbo-go 的服务端代码，可以被 dubbo-go 客户端和 Java 客户端调用，所以基本上使用 Dubbo 作为 PPC 框架的 Go 语言应用跟 Java 应用是没有什么阻碍的，是完全的跨语言 RPC 调用。更重要的是 dubbo-go 继承了 Dubbo 的许多优点，如易于扩展、服务治理功能强大，大家在用 Go 语言开发应用的过程中，如果也遇到类似需要与 Dubbo Java 打通的需求，或者需要找一个服务治理功能完备的 Go 微服务框架，可以看下我们 dubbo-go 项目。
+
+### dubbo-go 的组成项目
+
+下面介绍一下 dubbo-go 的组成项目，为了方便可以被其他项目直接复用， dubbo-go 拆分成了多个项目，并全部以 Apache 协议开源。
+
+##### apache/dubbo-go
+
+dubbo-go 主项目， Dubbo 服务端、客户端完整 Go 语言实现。
+
+##### apache/dubbo-go-hession2
+
+目前应用最广泛，与 Java 版本兼容程度最高的 hessian2 协议 Go 语言实现，已经被多个 GolangRPC & Service Mesh 项目使用。
+
+##### dubbo-go/getty
+
+dubbo-go 异步网络 I/O 库，将网络处理层解耦。
+
+##### dubbo-go/gost
+
+基本类库，定义了 timeWheel、hashSet、taskPool 等。
+
+##### dubbo-go/dubbo-go-benchmark
+
+用于对 dubbo-go 进行简单的压力测试，性能测试。
+
+##### apache/dubbo-go-hessian2
+
+
+
+先简单介绍一下 dubbo-go-hessian2 项目。该项目就是 hessian2 协议的 Go 语言实现，最基本的可以将 Java 的基本数据类型和复杂数据类型（如一些包装类和list接口实现类）与 golang 这边对应。
+
+详情可以参考：
+
+*https://github.com/hessian-group/hessian-type-mapping*
+
+另外 Dubbo Java 服务端可以不捕获异常，将异常类通过 hession2 协议序列化通过网络传输给消费端，消费端进行反序列化对该异常对象并进行捕获。我们经过一段时间的整理，目前已经支持在 Go 消费端定义对应 Java 的超过 40 种 exception 类，来实现对 Java 异常的捕获，即使用 dubbo-go 也可以做到直接捕获 Java 服务端抛出的异常。
+
+另外对于 Java 端 BigDecimal 高精度计算类的支持。涉及到一些金融相关的计算会有类似的需求，所以也对这个类进行了支持。
+
+其他的，还有映射 java 端的方法别名，主要的原因是 Go 这边语言的规约，需要被序列化的方法名必须是首字母大写。而 Java 这边没有这种规范，所以我们加了一个 hessian 标签的支持，可以允许用户手动映射 Java 端的方法名称。
+
+基本上现在的 dubbo-go 已经满足绝大多数与 Java 的类型互通需求，我们近期也在实现对 Java 泛型的支持。
+
+##### dubbo-go/getty
+
+
+
+Go 语言天生就是一个异步网络 I/O 模型，在 linux 上 Go 语言写的网络服务器也是采用的 epoll 作为最底层的数据收发驱动,这跟 java 在 linux 的 nio 实现是一样的。所以 Go 语言的网络处理天生就是异步的。我们需要封装的其实是基于 Go 的异步网络读写以及之后的处理中间层。getty 将网络数据处理分为三层，入向方向分别经过对网络 i/o 封装的 streaming 层、根据不同协议对数据进行序列化反序列化的 codec 层，以及最后数据上升到需要上层消费的 handler 层。出向方向基本与入向经过的相反。每个链接的 IO 协程是成对出现的，比如读协程负责读取、 codec 逻辑然后数据到 listener 层，然后最后的事件由业务协程池来处理。
+
+该项目目前是与 dubbo-go 解耦出来的，所以大家如果有类似需求可以直接拿来用，目前已经有对于 tcp/udp/websocket 的支持。
+
+##### apache/dubbo-go
+
+
+
+dubbo-go 主项目，我们重构的这一版主要是基于 Dubbo 的分层代码设计，上图是 dubbo-go 的代码分层。基本上与 Java 版本 Dubbo 现有的分层一致，所以 dubbo－go 也继承了 Dubbo 的一些优良特性，比如整洁的代码架构、易于扩展、完善的服务治理功能。
+
+我们携程这边，使用的是自己的注册中心，可以在 dubbo-go 扩展机制的基础上灵活扩展而无需去改动 dubbo-go 的源代码。
+
+### dubbo-go 的功能介绍
+
+##### dubbo-go 已实现功能
+
+目前 dubbo-go 已经实现了 Dubbo 的常用功能（如负责均衡、集群策略、服务多版本多实现、服务多注册中心多协议发布、泛化调用、服务降级熔断等），其中服务注册发现已经支持 zookeeper/etcd/consul/nacos 主流注册中心。这里不展开详细介绍，目前 dubbo-go 支持的功能可以查看项目 readme 中的 feature list ，详情参考：*https://github.com/apache/dubbo-go#feature-list*
+
+目前社区正在开发中的功能，主要是早期用户使用过程中提出的一些需求，也是生产落地一些必需的需求，如监控、调用链跟踪以及服务路由、动态配置中心等更高级的服务治理需求。
+
+##### dubbo-go 功能介绍之泛化调用
+
+
+
+这里详细做几个重点功能的介绍。首先是泛化调用，如上图，这个也是社区同学提的需求。该同学公司内部有很多 Dubbo 服务，他们用 Go 做了一个 api gateway 网关，想要把 Dubbo 服务暴露成外网 http 接口。因为内部的 Dubbo 服务比较多，不可能每一个 Dubbo 服务都去做一个消费端接口去做适配，这样的话一旦服务端改动，客户端也要改。所以他这边的思路是做基于 dubbo-go 做泛化调用， api-gateway 解析出外网请求的地址，解析出想要调用的 Dubbo 服务的目标。基于dubbo-go consumer 泛化调用指定 service、method ，以及调用参数。
+
+具体的原理是， dubbo-go 这边作为消费端，实际会通过本地 genericService.invoke 方法做代理，参数里面包含了 service name，method name ，还包含被调用目标 service 需要的参数类型、值等数据，这些数据后面会通过 dubbo-go-hession2 做转换，会将内容转化成 map 类型，经过网络发送到对应的 Java 服务端，然后 Java 那边是接收的 map 类型的参数，会自动反序列化成自己的 pojo 类型。这样就实现了 dubbo-go 作为客户端，泛化调用 Dubbo 服务端的目的。
+
+##### dubbo-go 功能介绍之降级熔断
+
+
+
+降级熔断这边是基于的是大家比较熟悉的 hystrix 的 Go 语言版本，基于 hystrix ，用户可以定义熔断规则和降级触发的代码段。降级熔断支持是作为一个独立的 dubbo-go filter ，可以灵活选择是否启用，如果不启用就可以在打包的时候不将依赖引入。Filter 层是 dubbo-go 中对于请求链路的一个责任链模式抽象，目前有许多功能都是基于动态扩展 filter 链来实现的，包括 trace、leastactive load balacne、log 等。降级熔断设计成一个服务调用端独立的filter可以灵活满足调用端视角对于微服务架构中“防雪崩“的服务治理需求。
+
+##### dubbo-go 功能介绍之动态配置
+
+关于动态配置中心， Dubbo 的 2.6 到 2.7 版本做了一个比较大的变化，从之前的 url 配置形式过渡到了支持配置中心 yaml 格式配置的形式，治理粒度也从单服务级别的配置支持到了应用级别的配置，不过在2.7版本中还是兼容 2.6 版本 url 形式进行服务配置的。dubbo-go 这边考虑到跟 Dubbo2.6 和 2.7 的互通性，同样支持 url 和配置文件方式的服务配置，同时兼容应用级别和服务级别的配置，跟 dubbo 保持一致，目前已经实现了zookeeper和apollo作为配置中心的支持。
+
+### dubbo-go roadmap 2019-2020
+
+
+
+最后是大家比较关注的，社区关于 dubbo-go 2019 年下半年的计划，目前来看主要还是现有功能的补齐和一些问题的修复，我们的目标就是首先做到 Java 和 Go 在运行时的兼容互通和功能的一致，其次是查漏补缺 dubbo-go 作为一个完整 Go 语言微服务框架在功能上的可以改进之处。
+
+另外值得关注的一点是，预计今年年底， dubbo-go 会发布一个支持 kubernetes 作为注册中心的扩展，积极拥抱云原生生态。关于云原生的支持，社区前期做了积极的工作，包括讨论关于 dubbo-go 与 Service Mesh 的关系以及在其中的定位，可以肯定的是， dubbo-go 将会配合 Dubbo 社区在 Service Mesh 方向的规划并扮演重要角色，我们初步预计会在明年给出与 Service Mesh开源社区项目集成的方案，请大家期待。
+
+dubbo-go 社区目前属于快速健康成长状态，从捐赠给 Apache 后的不到3个月的时间里，吸引了大批量的活跃开发者和感兴趣的用户，欢迎各位同道在使用或者学习中遇到问题能够来社区讨论或者给予指正，也欢迎对 dubbo-go 有潜在需求或者对 dubbo-go 感兴趣的同道能加入到社区中。
+
+### 关于作者
+
+何鑫铭，目前就职于携程，基础中台研发部技术专家，dubbo-go 共同发起人、主要作者，Apache Dubbo committer，关注互联网中台以及中间件领域。
\ No newline at end of file
diff --git a/content/zh/blog/news/dubbo-go-intro.md b/content/zh/blog/news/dubbo-go-intro.md
new file mode 100644
index 0000000..7d99c62
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-intro.md
@@ -0,0 +1,159 @@
+---
+title: "冲上云原生，Dubbo 发布 Go 版本"
+linkTitle: "Dubbo Go 发布"
+date: 2021-01-11
+description: 本文记录了 OSCHINA 对何鑫铭的采访，原文出处：https://www.oschina.net/question/3820517_2306822
+---
+
+5 月 21 日，经过一年多的孵化，Apache Dubbo 从 Apache 软件基金会毕业，成为 Apache 顶级项目。
+
+
+
+
+Dubbo 是阿里于 2011 年开源的一款高性能 RPC 框架，在 Java 生态中具有不小的影响力。当初经历过一段被外界诟病的“停止维护”灰暗时光，后来在 2017 年 Dubbo 浪子回头，官方宣布重新重点维护。
+
+重新启航的 Dubbo 将首要目标定位于重新激活社区，赢回开发者的信任，并且逐渐将 Dubbo 打造成一个国际化与现代化的项目，目前距离宣布重启已经过了一年半的时间。
+
+在这个过程中，Dubbo 发布了多个版本，并逐渐从一个 RPC 框架向微服务生态系统转变，18 年年初 Dubbo 入驻 Apache 软件基金会孵化器，开始以 Apache 之道发展社区。
+
+一年之后，Dubbo 在 Apache 孵化器中发布了重启维护以来的首个里程碑版本 2.7.0，添加了社区呼声很高的异步化支持，以及注册中心与配置中心分离等特性。
+
+这期间 Dubbo 3.0 的开发工作也被提上了日程，今年 4 月中旬，官方正式公布了 Dubbo 3.0 的进度，此版本新特性包括支持 Filter 链的异步化、响应式编程、云原生/Service Mesh 方向的探索，以及与阿里内外融合。
+
+然后，Dubbo 毕业了。毕业后的 Dubbo 近期有什么消息呢？生态还在发展，Dubbo 社区在前几日公开了 [Dubbo Roadmap 2019](https://github.com/dubbo/awesome-dubbo/blob/master/slides/meetup/201905@beijing/DUBBO%20ROADMAP%202019.pdf)，计划在 2020 年 2 月份发布 Dubbo 3.0 正式版，感兴趣的同学可以详细查阅。
+
+
+
+而最近官方又**宣布 Go 语言加入 Dubbo 生态**，发布了 [dubbo-go](https://github.com/dubbo/go-for-apache-dubbo) 项目。
+
+
+
+在此之前 Dubbo 的跨语言可扩展性已经有一些实现，支持的语言包括 PHP、Node.js 与 Python，同时也基于标准 Java REST API - JAX-RS 2.0 实现了 REST 的调用支持，具体情况如下：
+
+* **PHP**：php-for-apache-dubbo，by 乐信，提供客户端和服务端
+* **Node.js**：dubbo2.js，by 千米网，提供客户端
+* **Node.js**：egg-dubbo-rpc，by 蚂蚁金服 egg 团队，提供客户端和服务端
+* **Python**：py-client-for-apache-dubbo，by 千米网，提供客户端
+
+现在加入了 dubbo-go，Go 开发者也终于可以尝到 Dubbo 的滋味了。据悉，dubbo-go 项目将于**本周完成往 Apache 软件基金会的迁移**，作为 Apache Dubbo 顶级项目的子项目，届时 dubbo-go 项目的新地址也将变为：https://github.com/apache/dubbo-go。
+
+关于项目的研发背景与具体技术细节等相关内容，我们第一时间采访了项目共同发起人，目前在携程基础中台研发部的何鑫铭。
+
+*OSCHINA*：dubbo-go 是什么，定位是什么，为什么做这个项目？
+
+*dubbo-go 何鑫铭*：
+
+**dubbo-go 是 Dubbo 的完整 Go 语言实现**。
+
+我们知道 Dubbo 本身基于 Java，很多公司也都以 Java 开发为主，并且使用 Dubbo 作 RPC 或微服务开发框架。
+
+而最近 Go 语言生态发展比较迅速，因其语言优势，我们已经有部门开始尝试使用 Go 开发一些新的项目，就会存在亟需解决的问题：
+
+* 如何实现 Go 项目和 Java & Dubbo 项目的互通？
+* 另外，Go 项目本身也有对 RPC 与微服务开发框架的诉求，如何解决？
+
+基于这两个问题，我们携程团队基于 dubbo-go 的早期项目，重构开发了更易于扩展且功能更加完善的 dubbo-go v1.0.0 版本，并贡献回了社区，它**首要目的就是解决 Go 项目与 Java & Dubbo 项目的互通问题，同时也为 Go 项目提供了一种 RPC 与微服务开发框架的选择**。
+
+dubbo-go 提供客户端与服务器端，目前 dubbo-go 社区作为 Dubbo 生态最活跃的社区之一，后面的定位需要配合 Dubbo 官方的要求与社区用户的需求。
+
+*OSCHINA*：我们知道 Dubbo 在 Java 生态上是有非常高的成就的，而目前 Go 生态本身也有一些知名的微服务框架，那 dubbo-go 之于 Go 生态，是否有与其它框架比拼的能力？
+
+*dubbo-go 何鑫铭*：
+
+我们最大的能力就是作为 Dubbo 的 Go 语言版本，打通了两种语言之间的 gap，**让 Dubbo 更加贴近云原生**，为开发者也提供了最大的灵活性，显著降低企业现有服务上云的成本，让企业在云原生时代多了一种选择。
+
+*OSCHINA*：Go 的特性有没有在 dubbo-go 中得到相应的体现？（比如 Go 的高并发是怎么从基于 Java 的 Dubbo 中改造到 dubbo-go 中的？）
+
+*dubbo-go 何鑫铭*：
+
+我对于 Go 语言的认知是，首先学习成本比较小，相比于 Java 的学习成本，Go 语言更容易学习和上手。
+
+其次 Go 在语言层面上，比如其 CSP 编程模型在高并发处理上的简单高效、轻量级协程的优势，相比较基于 JVM 的 Java 程序来说，基于 runtime 的 Go 程序瞬时启动能力等特性都吸引着很多开发者，这里就不详细阐述了。
+
+最后就是作为云原生语言的优势，随着 Docker、k8s 与 Istio 等优秀项目的出现，云原生底层基本被 Go 语言统一了，相信企业在云原生模式下开发的日子已经不远了。我觉得 Go 语言的生态应该会越来越好，也会有越来越多的人使用它。
+
+将基于 Java 的 Dubbo 引入到 Go 中，像前边讲的，dubbo-go 带来的优势就是可以快速融入云原生的领域。要说 Go 语言特性体现的话，可以参考一下 **dubbo-go 中异步网络 I/O 模型的设计，这部分将 Go 语言轻量级协程的优势体现了出来**。
+
+这里也说一下 Go 语言不足的地方：
+
+* Go 相对 Java 来说还是很年轻的语言，没有模板库可用，所以社区在编写并维护Hessian 2 协议库上付出了很高的开发成本；
+* 比起 Java 的 try/catch 错误处理方式，Go 的 error 处理能力偏弱；
+* 总体生态还是不如 Java，如没有像 Netty 一样的强有力网络 I/O 库。
+
+为什么提到这一点呢，因为 Dubbo 自身使用了 Netty 和 Hessian 2 协议官方 Java 库，而 dubbo-go 在开始做的时候这些都是没有的，这使得 **dubbo-go 一路走来非常艰辛，但是社区最终都克服了，并且额外贡献了开源的 Getty 和 Hessian2 项目**。
+
+这里特别感谢 dubbo-go 社区早期的组织者于雨，项目的早期版本是 **2016 年**在其领导胡长城和同事刘畏三支持下开发的，他贡献的 Hessian2 和 Getty 项目，也为最新版本的 dubbo-go 打好了坚实的基础。
+
+*OSCHINA*：前不久 Dubbo 才宣布之后会在 3.0 中强调 Service Mesh ，这就是语言无关的了，那 dubbo-go 还有必要在这时候加入生态吗？
+
+*dubbo-go 何鑫铭*：
+
+Service Mesh 确实是微服务未来发展的的一个大方向，但是现阶段在国内大公司还没有看到非常成功的案例，很多中小公司自身微服务还未拆分完毕甚至于还未开始，目前 dubbo-go 社区优先解决这种类型企业微服务技术落地环节中遇到的问题，专注于补齐相关功能、优化整体性能和解决 bug。至于未来，我相信随着 Dubbo Mesh 在 Service Mesh 领域的探索，dubbo-go 肯定会跟进并扮演重要角色。
+
+*OSCHINA*：dubbo-go 与 Dubbo 的更新关系是怎么样的？是同步更新特性还是有自己的一些创新？
+
+*dubbo-go 何鑫铭*：
+
+我们现在发布的最新版本是 v1.0.0，我们在每一次 release 新的版本后，都会明确说明可以兼容的 Dubbo 版本。所以，dubbo-go 需要兼容对应 Dubbo 版本号的功能，会同步更新一些 Dubbo 特性。
+
+*OSCHINA*：新发布版本带来什么值得关注的特性？
+
+*dubbo-go 何鑫铭*：
+
+当前发布的 v1.0.0 版本支持的功能如下：
+
+* 角色：Consumer(√)、Provider(√)
+* 传输协议：HTTP(√)、TCP(√)
+* 序列化协议：JsonRPC v2(√)、Hessian v2(√)
+* 注册中心：ZooKeeper(√)
+* 集群策略：Failover(√)
+* 负载均衡：Random(√)
+* 过滤器：Echo Health Check(√)
+* extension 扩展机制
+
+dubbo-go v1.0.0 版本，主要由我和同在携程的同事[方银城](https://github.com/fangyincheng)维护，社区成员[周子庆](https://github.com/u0x01)与[高辛格](https://github.com/gaoxinge)参与贡献，该版本沿用了 Dubbo 的代码分层解耦设计。Dubbo 2.6.x 的主要功能都会逐渐在 dubbo-go 中实现，包括 Dubbo 基于 SPI 的代码拓展机制，dubbo-go 也有对应的 extension 扩展机制与之对应。
+
+我们在未来将逐渐推出目前可扩展模块的更多实现，如补齐更多的 Loadbalance 负载均衡、Cluster Strategy 集群策略实现（目前这些任务由社区伙伴主动认领，希望更多的 Go 语言爱好者朋友可以加入社区贡献）；又如云原生领域非常流行的 k8s，我们也将同步 Dubbo 的 roadmap，跟进 k8s 作为注册中心的支持，目前由社区成员[张海彬](https://github.com/NameHaibinZhang)负责跟进。
+
+当然广大开发者们也可以对这些模块接口进行新的实现，通过 extension 拓展，以完成自己的特殊需求而无需修改源代码。同时，我们非常欢迎开发者为社区贡献有用的拓展实现。
+
+此版本解决了一大重点问题：与 **Dubbo Java 版本互通的解决方案**。我们将这部分提取出了 [Hessian2](https://github.com/dubbogo/hessian2) 项目，该项目源自社区[于雨](https://github.com/AlexStocks)的早期贡献，现在由社区成员[望哥](https://github.com/wongoo)负责维护，[周子庆](https://github.com/u0x01)与[高辛格](https://github.com/gaoxinge)参与贡献。目前该项目已经完成了对 Java 大部分类型的兼容支持。大家也可以单独将该项目集成到自己的项目中，它的开源协议是 Apache-2.0。
+
+另外一个比较重要的就是 **dubbo-go 现在使用的 TCP 异步网络 I/O 库**，该库也是基于于雨早期写的 Getty 项目，目前由社区的[望哥](https://github.com/wongoo)与[方银城](https://github.com/fangyincheng)负责维护，它同样也是 Apache-2.0 的开源协议。下一版本我们**会针对 dubbo-go 和 Getty 的网络 I/O 与线程派发这一部分进行进一步优化**。
+
+除此之外，我们计划下一步支持 Dubbo 的另外几大重要功能，如：
+
+* routing rule 路由规则(dubbo v2.6.x)
+* dynamic configuration 动态配置中心(dubbo v2.* 7.x)
+* metrics 指标与监控(dubbo v2.7.x)
+* trace 链路监控(dubbo ecos)
+
+*OSCHINA*：目前项目的应用情况如何？
+
+*dubbo-go 何鑫铭*：
+
+dubbo-go 现在已经开始被一些企业尝试应用于 Go 语言应用融入企业已有 Java & Dubbo 技术栈，以及搭建全新 Go 语言分布式应用等场景。比如中通快递内部 Go 调用 Java Dubbo 服务；作为携程 Go 语言应用的服务框架以及 Go、Java 应用互通。
+
+具体的应用情况可以查看： https://github.com/dubbo/go-for-apache-dubbo/issues/2
+
+*OSCHINA*：接下来的演进方向是怎么样的？
+
+*dubbo-go 何鑫铭*：
+
+在 dubbo-go 迁往 Apache 软件基金会作为 Apache Dubbo 的子项目后，首先最重要的是**性能的进一步优化**，目前性能上虽然能够达到应用的生产级别要求，但我们觉得还没有发挥出 Go 语言的优势，还有比较大的优化空间。比如前边提到的 Getty，下一版本会针对 dubbo-go 应用 Getty 的网络 I/O 模型与线程派发做一些优化。
+
+另外包含上面提到的我们近期需要补全一些重要功能，最大限度地在**功能完整性**上能够跟 Dubbo 兼容。关于未来 dubbo-go 的发展，也会向 Dubbo 2.7.x 版本这条线上的路线图演进。
+
+*OSCHINA*：说到性能，当前性能情况具体如何？
+
+*dubbo-go 何鑫铭*：
+
+我们有做一个 [dubbo-go-benchmark](https://github.com/dubbogo/go-for-apache-dubbo-benchmark) 项目，在 CPU 型号为 Intel(R) Xeon(R) CPU E5-2609 0 @2.40GHz，CPU 核心数为 4*8 的硬件水平下，发送 1k 并返回 1k 的数据，100 并发数，100w 总请求数，qps 可以达到 1.2 万左右。
+
+CPU 性能换成比较高的配置如 Intel Core i9 2.9GHz，qps 可以到达 2 万左右。
+
+我们后面会对 Hessian2 库和 Getty 库进行持续性能优化，以给广大使用者节约资源。
+
+#### 采访嘉宾介绍
+
+**何鑫铭**，携程基础中台研发部技术专家，dubbo-go 主要作者。目前专注于 Golang & Java、中台架构、中间件与区块链等技术。
\ No newline at end of file
diff --git a/content/zh/blog/news/dubbo-go-metrics.md b/content/zh/blog/news/dubbo-go-metrics.md
new file mode 100644
index 0000000..e7d43a3
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-metrics.md
@@ -0,0 +1,155 @@
+---
+title: "Dubbo Go 中 metrics 的设计"
+linkTitle: "Dubbo Go 中 metrics 的设计"
+date: 2021-01-11
+description: eBay 邓明：dubbo-go 中 metrics 的设计
+---
+
+最近因为要在 Apache/dubbo-go（以下简称 dubbo-go ）里面实现类似的这个 metrics 功能，于是花了很多时间去了解现在 Dubbo 里面的 metrics 是怎么实现的。该部分，实际上是被放在一个独立的项目里面，即
+metrics ，见 https://github.com/flycash/dubbo-go/tree/feature/MetricsFilter 下 metrics 子目录。
+
+总体上来说，Dubbo 的 metrics 是一个从设计到实现都非常优秀的模块，理论上来说，大部分的 Java 项目是可以直接使用 metrics 的。但也因为兼顾性能、扩展性等各种非功能特性，所以初看代码会有种无从下手的感觉。
+
+今天这篇文章将会从比较大的概念和抽象上讨论一下 dubbo-go 中的 metrics 模块的设计——实际上也就是 Dubbo 中的 metrics 的设计。因为我仅仅是将 Dubbo 里面的相关内容在 dubbo-go 中复制一份。
+
+目前 dubbo-go 的 metrics 刚刚开始起步，第一个 PR 是： https://github.com/apache/dubbo-go/pull/278
+
+## 总体设计
+
+### Metrics
+
+要想理解 metrics 的设计，首先要理解，我们需要收集一些什么数据。我们可以轻易列举出来在 RPC 领域里面我们所关心的各种指标，诸如每个服务的调用次数，响应时间；如果更加细致一点，还有各种响应时间的分布，平均响应时间，999线……
+
+但是上面列举的是从数据的内容上划分的。 metrics 在抽象上，则是摒弃了这种划分方式，而是结合了数据的特性和表现形式综合划分的。
+
+从源码里面很容易找到这种划分的抽象。
+
+
+
+metrics 设计了 Metric 接口作为所有数据的顶级抽象：
+
+在 Dubbo 里面，其比较关键的子接口是：
+
+
+
+为了大家理解，这里我抄一下这些接口的用途：
+
+- Gauge: 一种实时数据的度量，反映的是瞬态的数据，不具有累加性，例如当前 JVM 的线程数；
+- Counter: 计数器型指标，适用于记录调用总量等类型的数据；
+- Histogram : 直方分布指标，例如，可以用于统计某个接口的响应时间，可以展示 50%, 70%, 90% 的请求响应时间落在哪个区间内；
+- Meter: 一种用于度量一段时间内吞吐率的计量器。例如，一分钟内，五分钟内，十五分钟内的qps指标；
+- Timer: Timer相当于Meter+Histogram的组合，同时统计一段代码，一个方法的qps，以及执行时间的分布情况；
+
+目前 dubbo-go 只实现了 FastCompass ，它也是 Metric 的子类：
+
+
+
+这个接口功能很简单，就是用于收集一段时间之内的 subCategory 执行的次数和响应时间。 subCategory 是一个比较宽泛的概念，无论是在 Dubbo 还是在 dubbo-go 里面，一个典型的 subCategory
+就会是某个服务。
+
+这里的设计要点在于，它是从什么角度上去做这些数据的抽象的。
+
+很多人在开发这种采集数据的相关系统或者功能的时候，最容易陷入的就是从数据内容上做抽象，例如抽象一个接口，里面的方法就是获得服务的调用次数或者平均响应时间等。
+
+这种抽象并非不可以，尤其是在简单系统里面，还非常好用。唯独在通用性和扩展性上要差很多。
+
+### MetricManager
+
+在我们定义了 Metric 之后，很容易就想到，我要有一个东西来管理这些 Metric 。这就是 MetricManager ——对应到 Dubbo 里面的 IMetricManager 接口。
+
+MetricManager 接口目前在 dubbo-go 里面还很简单：
+
+
+
+本质上来说，我在前面提到的那些 Metric 的子类，都可以从这个 MetricManager 里面拿到。它是对外的唯一入口。
+
+因此无论是上报采集的数据，还是某些功能要用这些采集的数据，最重要的就是获得一个 MetricManager 的实例。例如我们最近正在开发的接入 Prometheus 就是拿到这个 MetriManger 实例，而后从里面拿到
+FastCompass 的实例，而后采集这些数据：
+
+
+
+### MetricRegistry
+
+MetricRegistry 是一个对 Metric 集合的抽象。 MetricManager 的默认实现里面，就是使用 MetricRegistry 来管理 Metric 的:
+
+
+
+所以，本质上它就是提供了一些注册 Metric 然后再从里面捞出来的方法。
+
+于是，这就有一个问题了：为什么我在有了 MetricManager 之后，还有有一个MetricRegistry？似乎这两个功能有些重叠？
+
+答案大概是两个方面：
+
+1、除了管理所有的 Metric 之外，还承担着额外的功能，这些功能典型的就是 IsEnabled 。而实际上，在未来我们会赋予它管理生命周期的责任，比如说在 Dubbo 里面，该接口就还有一个 clear 方法；
+
+2、 metrics 里面还有一个 group 的概念，而这只能由 MetricManager 来进行管理，至少交给 MetricRegistry 是不合适的。
+
+metrics 的 group 说起来也很简单。比如在 Dubbo 框架里面采集的数据，都会归属于 Dubbo 这个 group 。也就是说，如果我想将非框架层面采集的数据——比如纯粹的业务数据——分隔出来，就可以借用一个 business
+group 。又或者我采集到的机器自身的数据，可以将其归类到 system 这个 group 下。
+
+所以 MetricManger 和 MetricRegistry 的关系是：
+
+
+
+### Clock
+
+Clock 抽象是一个初看没什么用，再看会觉得其抽象的很好。Clock 里面就两个方法：
+
+
+
+一个是获得时间戳，另外一个则是获得时间周期(Tick)。比如通常采集数据可能是每一分钟采集一次，所以你得知道现在处在哪个时间周期里面。Clock 就提供了这种抽象。
+
+很多人在实现自己的这种 metrics 的框架的时候，大多数都是直接使用系统的时钟，也就是系统的时间戳。于是所有的 Metic 在采集数据或者上报数据的时候，不得不自己去处理这种时钟方面的问题。
+
+这样不同的 Metric 之间就很难做到时钟的同步。比如说可能在某个 Metric1 里面，采集周期是当前这一分钟，而 Metric2 是当前这一分钟的第三十秒到下一分钟的第三十秒。虽然它们都是一分钟采集一次，但是这个周期就对不上了。
+
+另外一个有意思的地方在于，Clock 提供的这种抽象，允许我们不必真的按照现实时间的时间戳来处理。比如说，可以考虑按照 CPU 的运行时间来设计 Clock 的实现。
+
+## 例子
+
+就用这一次 PR 的内容来展示一下这个设计。
+
+在 dubbo-go 里面这次实现了 metricsFilter ，它主要就是收集调用次数和响应时间，其核心是：
+
+
+
+report 其实就是把 metrics reports 给 MetricManager ：
+
+
+
+所以，这里面可以看出来，如果我们要收集什么数据，也是要先获得 MetricManager 的实例。
+
+FastCompass 的实现里面会将这一次调用的服务及其响应时间保存下来。而后在需要的时候再取出来。
+
+所谓的需要的时候，通常就是上报给监控系统的时候。比如前面的提到的上报给 Prometheus。
+
+所以这个流程可以抽象表达为：
+
+
+
+这是一个更加宽泛的抽象。也就是意味着，我们除了可以从这个 metricFilter 里面收集数据，也可以从自身的业务里面去收集数据。比如说统计某段代码的执行时间，一样可以使用 FastCompass 。
+
+而除了 Prometheus ，如果用户自己的公司里面有监控框架，那么他们可以自己实现自己的上报逻辑。而上报的数据则只需要拿到 MetricManager 实例就能拿到。
+
+## 总结
+
+本质上来说，整个 metrics 可以看做是一个巨大无比的 provider-consumer 模型。
+
+不同的数据会在不同的地方和不同时间点上被采集。有些人在读这些源码的时候会有点困惑，就是这些数据什么时间点会被采集呢？
+
+它们只会在两类时间点采集：
+
+1、实时采集。如我上面举例的 metricsFilter ，一次调用过来，它的数据就被采集了；
+
+2、另外一个则是如同 Prometheus 。每次 Prometheus 触发了 collect 方法，那么它就会把每种（如 Meter, Gauge ）里面的数据收集过来，然后上报，可以称为是定时采集；
+
+Dubbo 里面采集了非常多的数据：
+
+
+
+这些具体的实现，我就不一一讨论了，大家有兴趣可以去看看源码。这些数据，也是我们 dubbo-go 后面要陆续实现的东西，欢迎大家持续关注，或者来贡献代码。
+
+## 作者信息
+
+邓明，毕业于南京大学，就职于 eBay Payment 部门，负责退款业务开发。
+
diff --git a/content/zh/blog/news/dubbo-go-tps.md b/content/zh/blog/news/dubbo-go-tps.md
new file mode 100644
index 0000000..b225244
--- /dev/null
+++ b/content/zh/blog/news/dubbo-go-tps.md
@@ -0,0 +1,219 @@
+---
+title: "Dubbo Go 中的 TPS Limit 设计与实现"
+linkTitle: "dubbo-go tps limit"
+date: 2021-01-11
+description: 本文记录了 flycash 对 Dubbo Go 中 TPS Limit 的设计与实现，原文出处：https://www.jianshu.com/p/5e4d490f163c
+---
+
+# 前言
+
+[Apache Dubbo](https://links.jianshu.com/go?to=http%3A%2F%2Fdubbo.apache.org%2Fen-us%2F)是由阿里开源的一个RPC框架，除了基本的RPC功能以外，还提供了一整套的服务治理相关功能。目前它已经是Apache基金会下的顶级项目。
+
+而[dubbogo](https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fapache%2Fdubbo-go)则是dubbo的go语言实现。
+
+最近在`dubbogo`的`todo list`上发现，它还没有实现`TPS Limit`的模块，于是就抽空实现了这个部分。
+
+`TPS limit`实际上就是限流，比如说限制一分钟内某个接口只能访问200次，超过这个次数，则会被拒绝服务。在`Dubbo`的Java版本上，只有一个实现，就是`DefaultTPSLimiter`。
+
+`DefaultTPSLimiter`是在服务级别上进行限流。虽然`dubbo`的官方文档里面声称可以在`method`级别上进行限流，但是我看了一下它的源码，实际上这个是做不到的。当然，如果自己通过实现`Filter`接口来实现`method`级别的限流，那么自然是可以的——这样暴露了`dubbo`Java版本实现的另外一个问题，就是`dubbo`的`TpsLimitFilter`实现，是不允许接入自己`TpsLimiter`的实现的。这从它的源码也可以看出来：
+
+
+
+它直接写死了`TpsLimiter`的实现。
+
+这个实现的目前只是合并到了`develop`上，等下次发布正式版本的时候才会发布出来。
+
+Github: [https://github.com/apache/dubbo-go/pull/237](https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fapache%2Fdubbo-go%2Fpull%2F237)
+
+# 设计思路
+
+于是我大概参考了一下`dubbo`已有的实现，做了一点改进。
+
+`dubbo`里面的核心抽象是`TpsLimiter`接口。`TpsLimitFilter`只是简单调用了一下这个接口的方法而已：
+
+
+
+这个抽象是很棒的。但是还欠缺了一些抽象。
+
+实际上，一个TPS Limit就要解决三个问题：
+
+1. 对什么东西进行`limit`。比如说，对服务进行限流，或者对某个方法进行限流，或者对IP进行限流，或者对用户进行限流；
+2. 如何判断已经`over limitation`。这是从算法层面上考虑，即用什么算法来判断某个调用进来的时候，已经超过配置的上限了；
+3. 被拒绝之后该如何处理。如果一个请求被断定为已经`over limititation`了，那么该怎么处理；
+
+所以在`TpsLimiter`接口的基础上，我再加了两个抽象：
+
+```golang
+type TpsLimiter interface {
+ // IsAllowable will check whether this invocation should be enabled for further process
+ IsAllowable(*common.URL, protocol.Invocation) bool
+}
+```
+
+```golang
+type TpsLimitStrategy interface {
+ // IsAllowable will return true if this invocation is not over limitation
+ IsAllowable() bool
+}
+```
+
+```golang
+type RejectedExecutionHandler interface {
+ // RejectedExecution will be called if the invocation was rejected by some component.
+ RejectedExecution(url *common.URL, invocation protocol.Invocation) protocol.Result
+}
+```
+
+`TpsLimiter`对应到Java的`TpsLimiter`，两者是差不多。在我的设想里面，它既是顶级入口，还需要承担解决第一个问题的职责。
+
+而`TpsLimitStrategy`则是第二个问题的抽象的接口定义。它代表的是纯粹的算法。该接口完全没有参数，实际上，所有的实现需要维护自身的状态——对于大部分实现而言，它大概只需要获取一下系统时间戳，所以不需要参数。
+
+最后一个接口`RejectedExecutionHandler`代表的是拒绝策略。在`TpsLimitFilter`里面，如果它调用`TpsLimiter`的实现，发现该请求被拒绝，那么就会使用该接口的实现来获取一个返回值，返回给客户端。
+
+# 实现
+
+其实实现没太多好谈的。不过有一些微妙的地方，我虽然在代码里面注释了，但是我觉得在这里再多说一点也是可以的。
+
+首先提及的就是拒绝策略`RejectedExecutionHandler`，我就是提供了一种实现，就是随便log了一下，什么都没做。因为这个东西是强业务相关的，我也不能提供更加多的通用的实现。
+
+## 方法与服务双重支持的TpsLimiter
+
+`TpsLimiter`我只有一个实现，那就是`MethodServiceTpsLimiterImpl`。它就是根据配置，如果方法级别配置了参数，那么会在方法级别上进行限流。否则，如果在服务级别（ServiceKey）上有配置，那么会在服务级别进行限流。
+
+举个最复杂的例子：服务A限制100，有四个方法，方法M1配置限制40，方法M2和方法M3无配置，方法M4配置限制-1：那么方法M1会单独限流40；M2和M3合并统计，被限制在100；方法M4则会被忽略。
+
+用户可以配置具体的算法。比如说使用我接下来说的，我已经实现的三种实现。
+
+## FixedWindow和ThreadSafeFixedWindow
+
+`FixedWindow`直接对应到Java的`DefaultTpsLimiter`。它采用的是`fixed-window`算法：比如说配置了一分钟内只能调用100次。假如从00:00开始计时，那么00:00-01:00内，只能调用100次。只有到达01:00，才会开启新的窗口01:00-02:00。如图：
+
+
+
+Fixed-Window 实现
+
+```golang
+// IsAllowable determines if the requests over the TPS limit within the interval.
+// It is not thread-safe.
+func (impl *FixedWindowTpsLimitStrategyImpl) IsAllowable() bool {
+
+ current := time.Now().UnixNano()
+ if impl.timestamp+impl.interval < current {
+ // it's a new window
+ // if a lot of threads come here, the count will be set to 0 several times.
+ // so the return statement will be wrong.
+ impl.timestamp = current
+ impl.count = 0
+ }
+ // this operation is thread-safe, but count + 1 may be overflow
+ return atomic.AddInt32(&impl.count, 1) <= impl.rate
+}
+```
+
+这里有一个很有意思的地方。就是这个实现，是一个几乎线程安全但是其实并不是线程安全的实现。
+
+在所有的实现里面，它是最为简单，而且性能最高的。我在衡量了一番之后，还是没把它做成线程安全的。事实上，Java版本的也不是线程安全的。
+
+它只会在多个线程通过第67行的检测之后，才会出现并发问题，这个时候就不是线程安全了。但是在最后的`return`语句中，那一整个是线程安全的。它因为不断计数往上加，所以多个线程同时跑到这里，其实不会有什么问题。
+
+现在我要揭露一个最为奇诡的特性了：**并发越高，那么这个`raise condition`就越严重，也就是说越不安全。**
+
+但是从实际使用角度而言，有极端TPS的还是比较少的。对于那些TPS只有几百每秒的，是没什么问题的。
+
+**为了保持和dubbo一致的特性，我把它作为默认的实现。**
+
+此外，我还为它搞了一个线程安全版本，也就是`ThreadSafeFixedWindowTpsLimitStrategyImpl`，只是简单的用`sync`封装了一下，可以看做是一个`Decorator`模式的应用。
+
+如果强求线程安全，可以考虑使用这个。
+
+## SlidingWindow
+
+这是我比较喜欢的实现。它跟网络协议里面的滑动窗口算法在理念上是比较接近的。
+
+
+
+具体来说，假如我设置的同样是一分钟1000次，它统计的永远是从当前时间点往前回溯一分钟内，已经被调用了多少次。如果这一分钟内，调用次数没超过1000，请求会被处理，如果已经超过，那么就会拒绝。
+
+我再来描述一下，`SldingWindow`和`FixedWindow`两种算法的区别。这两者很多人会搞混。假如当前的时间戳是00:00，两个算法同时收到了第一个请求，开启第一个时间窗口。
+
+那么`FixedWindow`就是00:00-01:00是第一个窗口，接下来依次是01:00-02:00, 02:00-03:00, ...。当然假如说01:00之后的三十秒内都没有请求，在01:31又来了一个请求，那么时间窗口就是01:31-02:31。
+
+而`SildingWindow`则没有这种概念。假如在01:30收到一个请求，那么`SlidingWindow`统计的则是00:30-01:30内有没有达到1000次。**它永远计算的都是接收到请求的那一刻往前回溯一分钟的请求数量。**
+
+如果还是觉得有困难，那么简单来说就是`FixedWindow`往后看一分钟，`SlidingWindow`回溯一分钟。
+
+> 这个说法并不严谨，只是为了方便理解。
+
+在真正写这个实现的时候，我稍微改了一点点：
+
+```golang
+// IsAllowable determins whether the number of requests within the time window overs the threshold
+// It is thread-safe.
+func (impl *SlidingWindowTpsLimitStrategyImpl) IsAllowable() bool {
+ impl.mutex.Lock()
+ defer impl.mutex.Unlock()
+ // quick path
+ size := impl.queue.Len()
+ current := time.Now().UnixNano()
+ if size < impl.rate {
+ impl.queue.PushBack(current)
+ return true
+ }
+
+ // slow path
+ boundary := current - impl.interval
+
+ timestamp := impl.queue.Front()
+ // remove the element that out of the window
+ for timestamp != nil && timestamp.Value.(int64) < boundary {
+ impl.queue.Remove(timestamp)
+ timestamp = impl.queue.Front()
+ }
+ if impl.queue.Len() < impl.rate {
+ impl.queue.PushBack(current)
+ return true
+ }
+ return false
+}
+```
+
+我用了一个队列来保存每次访问的时间戳。一般的写法，都是请求进来，先把已经不在窗口时间内的时间戳删掉，然后统计剩下的数量，也就是后面的`slow path`的那一堆逻辑。
+
+但是我改了的一点是，我进来直接统计队列里面的数量——也就是请求数量，如果都小于上限，那么我可以直接返回`true`。即`quick path`。
+
+这种改进的核心就是：我只有在检测到当前队列里面有超过上限数量的请求数量时候，才会尝试删除已经不在窗口内的时间戳。
+
+这其实就是，是每个请求过来，我都清理一下队列呢？还是只有队列元素超出数量了，我才清理呢？我选择的是后者。
+
+我认为这是一种改进……当然从本质上来说，整体开销是没有减少的——因为`golang`语言里面`List`的实现，一次多删除几个，和每次删除一个，多删几次，并没有多大的区别。
+
+### 算法总结
+
+无论是`FixedWindow`算法还是`SlidingWindow`算法都有一个固有的缺陷，就是这个时间窗口难控制。
+
+我们设想一下，假如说我们把时间窗口设置为一分钟，允许1000次调用。然而，在前十秒的时候就调用了1000次。在后面的五十秒，服务器虽然将所有的请求都处理完了，然是因为窗口还没到新窗口，所以这个时间段过来的请求，全部会被拒绝。
+
+
+
+解决的方案就是调小时间窗口，比如调整到一秒。但是时间窗口的缩小，会导致`FixedWindow`算法的`raise condition`情况加剧。`SlidingWindow`也会受影响，但是影响要小很多。
+
+## 那些没有实现的
+
+### 基于特定业务对象的限流
+
+举例来说，某些特殊业务用的针对用户ID进行限流和针对IP进行限流，我就没有在`dubbogo`里面实现。有需要的可以通过实现`TpsLimiter`接口来完成。
+
+### 全局TPS limit
+
+这篇文章之前讨论的都是单机限流。如果全局限流，比如说针对某个客户，它购买的服务是每分钟调用100次，那么就需要全局限流——虽然这种case都不会用`Filter`方案，而是另外做一个`API`接入控制。
+
+比如说，很常用的使用Redis进行限流的。针对某个客户，一分钟只能访问100次，那我就用客户ID做key，value设置成List，每次调用过来，随便塞一个值进去，设置过期时间一分钟。那么每次统计只需要统计当前key的存活的值的数量就可以了。
+
+这种我也没实现，因为好像没什么需求。国内讨论TPS limit都是讨论单机TPS limit比较多。
+
+这个同样可以通过实现`TpsLimiter`接口来实现。
+
+### Leaky Bucket算法
+
+这个本来可以是`TpsLimitStrategy`的一种实现的。后来我觉得，它其实并没有特别大的优势——虽然号称可以做到均匀，但是其实并做不到真正的均匀。通过调整`SlidingWindow`的窗口大小，是可以接近它宣称的均匀消费的效果的。比如说调整到一秒，那其实就已经很均匀了。而这并不会带来多少额外的开销。
+
diff --git a/content/zh/blog/news/dubbo-history-gochina.md b/content/zh/blog/news/dubbo-history-gochina.md
new file mode 100644
index 0000000..33c1fe4
--- /dev/null
+++ b/content/zh/blog/news/dubbo-history-gochina.md
@@ -0,0 +1,215 @@
+---
+title: "Dubbo Go 回顾与展望"
+linkTitle: "Dubbo Go 回顾与展望"
+date: 2021-01-11
+description: 本文记录了发表在 gochina 上的 Dubbo Go 的回顾与展望
+---
+
+Dubbo 是阿里于 2011 年开源的一款高性能 RPC 框架，在 Java 生态中具有不小的影响力。2019年5月21日，Dubbo 从 Apache 软件基金会毕业，成为 Apache 顶级项目。目前，毕业后的 Dubbo 项目的生态中已经正式官宣引入了 Go 语言，发布了 Dubbogo 项目。本文即是对 Dubbogo 这一项目的完整回顾与真实展望。由蚂蚁金服中间件技术专家于雨和携程基础中台研发部工程师方银城合作完成。
+
+## 一 Dubbogo 整体框架
+
+先介绍一下 dubbogo 的缘起，先看下面这幅图：
+
+
+
+最右边的 service0 和 service1 是 Dubbo 的服务端，左边的 gateway 是网关，HTTP 请求从网关进来，必须转化成 Dubbo 的协议才能到后面的服务，所以中间加了一层proxy 完成相关功能。基本上每个 service 都需要一个 proxy 去转化协议和请求，所以这个时候 dubbogo 的项目需求就出来了。最初的实现就是以 Dubbo 的 Go 版本作为目标，实现与 Java 版本 Dubbo 的互调。
+
+### Dubbogo 目标
+
+
+
+然后这个图是 dubbogo 的现在达到的目标：用一份 Go 客户端的代码能够在没有任何代理和其他中间件的情况下直接调用其他语言端，主要是Java 服务端的服务和 Go 服务端的服务，而 Go 作为服务端的时候，Java 客户端也可以直接调用 Go 服务端的服务。
+
+### Dubbogo 发展历程
+
+
+
+下面介绍 dubbogo 的整个发展历程，在2016年8月份的时候是于雨构建了 dubbogo 项目，那个时候的 dubbogo 只支持通过 jsonrpc 2.0 协议 进行 HTTP 通信，到 2018 年2 月份支持 hessian2 协议进行 TCP 通信，到 2018 年 5 月项目被 dubbo 官方关注后开始从零重构，于雨 2018 年 8 月份初步重构出一个 0.1 版本。由于我们携程这边的一些需求，2019 年初我和我的同事何鑫铭也开始参与了 dubbogo 项目的重构，同时和于雨一起开始组建社区，在 2019 年 6 月份的时候 dubbogo1.0 版本上线，这个版本的重构是参照了 Dubbo 的整体设计，主体功能都在这个版本里面有呈现，同期该项目进入了 Apache 组织。今年 8 月份由社区同学望哥负责的 Dubbo-go-hessian2 的项目也进了 Apache 组织。到目前为止我们社区有些工作已经和 dubbo 齐头并进，例如对 grpc 和 k8s 的支持，相关代码正在 review 中，年底发布
的 v1.3 版本会包含 grpc 支 [...]
+
+### Dubbogo 整体设计
+
+
+
+这个图大家是不是看着很熟悉，是 Dubbo 的整个分层设计图，但是少了 Dubbo 里面的很多东西，因为我们是借鉴了 Dubbo 的分层设计和易拓展性的思想，但是由于 Go 语言和 Java 语言的本质差别决定了我们项目设计不可能完全照搬它，有一些东西就给它简化了，特别是协议层这一块。比如说 Dubbo 里面 SPI 的拓展，在 Go 里面我们是借用了 Go 的非侵入式接口的方式去实现的，由于 Go 禁止 package 循环引用，所以 dubbogo 在代码的分包分层上面也是有严格的规定，这正好跟它的易拓展性的特性结合了起来。
+
+关于代理部分，因为 Java 有动态代理，Go 的反射就没有 Java 的反射那么强大，所以我们这边代理的实现方式也跟它是不一样的。
+
+### Dubbogo 能力大图
+
+
+
+上面的图是我们当前 dubbogo 项目实现的能力大图，最上层是当前实现的一些注册中心有 zk、etcd、nacos、consul，现在与 k8s 关联的功能正在开发中。配置中心目前是支持 Apollo 和 zookeeper。左边是消费端，消费端这边实现的是有 cluster 的，策略上基本上实现了 dubbo 支持的所有策略。然后还有负载均衡策略，fillter 主要是有一个 tps 的限流还有泛化调用，这两个后面会讲到。编码层现在就是 jsonrpc 2.0 和 hessian2，protobuf v3 正在加紧 review 中。目前社区正在开发中的支持，包括 trace、grpc、k8s注册中心，以及对 restful 的支持。
+
+### 关键项目
+
+
+
+目前 dubbogo 项目整体由 4 个组成部分。第一个是 getty，一个异步网络 IO 库，是实现 tcp 通信协议最坚实的基础；第二个是 dubbo-go-hessian2，这个是与当前 java hessian2 高度兼容的项目；第三个是 gost，是 dubbogo 的 基础库；最后是 dubbogo 的示例库，目前已经迁移到 https://github.com/apache/dubbo-samples，和 Java 示例合并了。这些都是当前 dubbogo 主要的组成项目。
+
+## 二 协议实现
+
+
+
+接下来讲一些具体的实现和部分的功能，上图是 dubbo-go-hessian2 实现，列出来是一些主要的功能列表，第一个是 Java 的 JDK Exceptions 的实现，里面实现了 40 多种的 Java JDK 主要的异常，可以与 Java 的 hessian2 版本互相解编码的支持，支持自动扩展自己实现 exceptions，或者是不常见的 Exceptions；第二个是支持字段名的联名，Go 可序列化的字段是大写字母开头，但是 Java 默认是小写开头的，所以有编码的字段名不一致的问题，这就有别名识别和支持自定义命名。
+
+go-hessian2 还支持 Java 的 bigdecimal、Date、Time、基本类型的包装类型、Generic Invocation、Dubbo Attachements，甚至支持 emoji 表情。
+
+go-hessian2 里面如果要解码和编码用户自定义类型，用户需要自己把它注册进去，前提是支持 go-hessian2 的 POJO interface，才能跟 JAVA 对应类互相解编码。
+
+
+
+上面是 go-hessian2 的类型对应表，需要特别点出的是 int，go 这边的 int 类型在不同字长系统下是有不同的大小，可能是 32 位也可能 64位的，而 Java 的 int 是 32 位的，所以我们以 go 语言的 int32 类型对应 Java int 类型。
+
+刚才提到了 Java 的 Class 和 go struct 的对应。上图有一个 go-hessian2 的 POJO 接口定义，每个 Java class 对应到 go struct，则 struct 需要给出 Java ClassName。
+
+
+
+你也可以加 hessian 标签，解析的时候会把这个字段名用别名写进去，实现自定义 fieldName。默认情况下，go-hessian2 中会自动把 struct field 首字母变成小写作为其 fieldName。
+
+
+
+
+泛化引用，是 dubbogo 里面比较重要的功能。社区一位同学需要基于 dubbogo 实现网关，收集外部的请求，然后通过泛化引用的形式调用其他 Dubbo 服务，最后自己动手把它实现了。使用时，首先需要在项目里内置一个 GenericService 服务，调用Load，然后就像正常的调用服务一样直接调用，跟 Java 是类似的，Go 客户端可以不知道 Java 的接口定义和类定义，把方法名、参数类型、参数数组以一个 map 的形式传输到 Java 服务端，Java 服务端收到请求后进行识别，把它转换成 POJO 类。
+
+以上是 go-hessian2 一些细节。上文讲到的泛化引用，是把网关作为整个内网 Dubbo 服务的公共消费端，使用的时候只需要知道请求的方法、参数类别，然后就能够调用 Dubbo 的服务。后面主要分享三部分内容：首先是网络引擎、底层网络库这块；其次是服务治理方面的内容，其中包含以 k8s 作为注册中心的一个初步的解决方案；第三部分是互联互通，主要是和 grpc 打通。最后给出一个展望，包含 dubbogo 社区明年的工作内容。
+
+## 三 网络引擎
+
+dubbogo 的网络引擎里面分为三层， 如下图所示：
+
+
+
+最底层 streaming 处理二进制流，第二层 codec层，进行协议的序列化和反序列化，第三层是 Eventlistener，提供应用使用接口。streaming 层能支持 websocket、TCP、UDP 三种网络通讯协议，这层具有一定的灵活性，今年年初上海有一个同学今年把 KCP 也加进去了，当时说要开源贡献出来，我还在期待中。codec 层可以适用不同协议，用户自定义即可。
+
+
+
+EventListener 对上层暴露了 4 个回调接口。第一个是 OnOpen，网络连接初建成功时被调用，应用层如果判定其为正常连接，则可以把连接 session 存储下来，如果用户判断当前连接过多则返回一个非空的 error，则这个连接会被 dubbogo 关闭。其次是 OnError 事件，当网络连接出错，就会回调到这个接口，在 dubbogo 关闭这个连接之前允许用户做相应处理，如把网络连接 session 从应用层的 session 池中删除。第三个是 OnCron，处理定时任务，如心跳，dubbogo 针对 websocket 协议在底层直接把心跳热任务处理了，针对 tcp 和 udp 协议需要用户在这个回调函数中自己实现。第四个接口是 OnMessage，用作处理一个完整的网络包。可以看到整个回调接口风格跟 websocket 的接口很像。
+
+
+
+### 协程池
+
+dubbogo 的 goroutine pool 里有 worker channel 【数量为 M】和逻辑处理 goroutine 【数量为 N】和网络任务【网络包】三种角色，网络解包后把把包按照某种规则放入某个 worker pool，然后逻辑处理 goroutine 从 channel 中读取数据包并执行逻辑处理，其目的是是为了把网络 I/O 与逻辑处理分开。不同的 goroutine pool 设计中，有的 N 大小会变化，有的不变，分别可称之为可伸缩 goroutine pool 和不可伸缩 goroutine pool，可伸缩 goroutine pool 可以对机器资源的使用不可预计。dubbogo 采用了不可伸缩 goroutine pool，其考量是限定其网络资源使用的上限。
+
+另外，dubbogo 的 goroutine pool 不考虑收包后的处理顺序。譬如，dubbogo 服务端收到了 A 和 B 两个网络包，dubbogo 有可能先处理网络包 B，后处理网络包 A。如果客户端的每次请求都是独立的，没有前后顺序关系，则带有不考虑网络包处理顺序是没有问题的。如果有强顺序要求，譬如上层用户关注 A 和 B 请求处理的前后顺序，则可以把 A 和 B 两个请求合并为一个请求，或者把 dubbogo 的 goroutine pool 特性关闭。
+
+一般情况下，不建议大家自己写 goroutine pool，因为 Go 语言对 goroutine 资源的管理已经非常先进，比如释放一个协程，Go 不会马上销毁掉相关的资源，一旦有创建 goroutine 的需要，马上就可复用这个成本是很低的。什么情况下使用 Goroutine Pool 呢？个人觉得像网络库逻辑处理这类场景下执行同样类型任务场景下确定 goroutine 会被迅速重复使用时可以尝试使用，但是怎么用好还是需要仔细考量，即需要仔细考量 M 与 N 的比例关系。
+
+假设处理某种网络任务请求，有的请求1秒就处理完了，有的可能10毫秒处理完了，设置 M 与 N 比例为 1:1，这样 1 对 1 造成的后果可能是饥饿，就是有一些队列处理的很快，有的处理很慢，整体负载不均衡，这种情况下就不推荐你用协成池了。
+
+还有一个比例模型是是1：N的，一写多读，比如说所有的请求都交给一个队列，所有逻辑处理 goroutine pool 都消费这个队列，造成的结果是什么呢？因为你只有一个生产者，那你就只有一个队列，多个消费者消费这一个队列，造成的结果是什么呢？因为 go channel 的低效率【整体使用一个 mutex lock】造成消费者 goroutine hang 在锁竞争上，当然其网络包处理顺序更无从保证。
+
+比较均衡的效果就是 M 和 N 都大于 1，dubbogo 的的 goroutine pool 模型中 M 和 N 的取值可以自行配置，其效果是每个 channel 被 N/M 个 goroutine 消费，这种模型类似于 kafka 的 consumer group，其优点是兼顾处理效率和锁压力平衡，可以做到总体层面的任务处理均衡。
+
+### 优化改进
+
+优化改进主要从三个方面入手， 如下图所示：
+
+
+
+1. 内存池。goroutine pool 是管理对 CPU 资源的分配，内存池就是管理内存资源的分配。我个人反对纯粹为了炫技没有目的地写内存池，其实 Go 的内存管理这块目前优化的很好了。Go 语言初始版本的内存管理使用了谷歌自家的 tcmalloc 库，这个库把应用释放的内存自己先缓存住，待失效期后才释放，那这样造成的结果是什么呢？就是早期的 Go 程序的内存成本很高。假设程序一个 sidecar 程序的资源限制是内存2G，CPU 核数是 2 核，用这样一个内存管理库，内存用完不释放给操作系统，那么没人敢用这个项目，当然最新的 Go 内存管理器是经过完全重构的，虽然也区分不同大小 span 的内存在 P 级别和全局级别进行缓存，但是基本上不用考虑这种内存膨胀不可控的问题了。那么什么情况下使用内存池呢？你确定你的业务有一些对象是频繁的复用则可以尝试使用�
�� 目前大部分内存池技术底层依赖的底座都是 sync.Pool，自己写一个也不难。而且 Go 1.13 之后的 sync.Pool 已经可以做到跨 GC span 不释放缓存对象，非常之好。
+2. 定时器。Go 语言早期定时器因为整体使用一把大锁的缘故效率极差，当然最新的就相当好了，通过每个 CPU 核下一个定时器的方法【类似于分片锁】分散了竞争压力，但是很多情况下还是有竞争压力，如果对时间精度要求不高个人建议在自己的应用中自己写一个简单的时间轮实现一个定时器，释放 CPU 压力。
+3. 网络写 buffer 合并。写 buffer 合并一般采用 writev，但是 Go 语言的 writev 有内存泄露问题，我这边一个负责 MOSN 开发的同事元总发现的。他先给 Go 语言官方提交了 PR，然后在 MOSN 中把 writev 扔掉自己写了一个简单好用的写 buffer 合并发送实现：通过 for 循环 10 次从发送 channel 中把网络包读取出来然后合并发送，当然循环中间网络发送 channel 没有足够的网络包就通过 `select-default` 分支立即退出循环。
+
+### channel 使用
+
+Go 语言是一个适合处理 IO 密集型任务的语言，不擅长处理 CPU 密集型任务，其内存通信的基础就是 channel。channel 整体的内存基础是一个 ring buffer 数组和一个 lock，外加其他一些读写通知队列等，也是因为一把大锁的缘故，则 buffer 型 channel 如果使用不当则效率不会很高，如每个 channel element 的内存使用过大。channel 还有一个 closed 字段，用于判定 channel 的写是否被关闭掉，Go 语言对其操作是以原子锁方式进行的，很多人以这个字段为基础进行信号通知，如果使用不当很可能造成 for 循环 CPU 100% 的问题，所以在 for-select 循环中特别要谨慎使用，dubbogo 在这方面踩过坑。
+
+## 四 服务治理
+
+下面为大家讲一下服务治理，说到服务治理，其实最重要的还是服务发现和服务注册，这块逻辑跟 Dubbo 类似，这次不作展开。下面主要包含两方面的内容，分别是限流算法和优雅退出。
+
+### 限流算法
+
+限流算法首先需要考虑限流的对象，dubbogo 需要考虑 interface 和 method。其次是限流方法，首先需要考虑的是单机限流还是集群限流，单机限流算法很多，譬如常用的固定窗口算法和滑动窗口算法，以及更进一步的自适应限流。限流时一个重要问题就是限流参数是很难配的，譬如线上服务到底需要使用多少机器资源合理，限流窗口的时间窗口时长应该多长合适，其 qps 值设置多少合适呢？这都是 dubbogo 需要解决的问题。先进如谷歌的 BBR 算法，可以在当前的网络环境恶化前不断尝试改进相关参数，直到尝试出一段时间内的最佳参数。还有一些业务形态下的限流，如针对会员和非会员分别设计不同的限流链路。
+
+Dubbo 的限流接口源码如下：
+
+
+
+这个接口抽象是非常漂亮的，第一个是限流 url，第二个服务调用。下面是 Dubbo 的固定窗口限流源码：
+
+
+
+上面的代码很明显，"private final" 决定了 Dubbo 使用者只能使用期给定的固定窗口限流限算法，无法扩展。
+
+以下是 dubbogo 的限流接口：
+
+
+
+TpsLimiter 是限流对象，TpsLimitStrategy 是限流算法，RejectedExecutionHandle 是限流动作。
+
+接下来是一个固定窗口算法实现：
+
+
+
+上图是 dubbogo 的固定窗口算法实现，其非线程安全，大家看一下代码就可以了，不推荐大家用。下图是 dubbogo 的滑动窗口算法实现：
+
+
+
+其基本原理是用一个队列存储一段时间内的请求，然后根据队列长度判定即可。
+
+不管是固定窗口还是滑动窗口，其判定算法简单，麻烦的是其参数设置，如下图：
+
+
+
+固定窗口时长精度很难控制。比如说限流一秒 QPS 值 1000，前 100 毫秒来了一千个请求，然后判定算法把请求放过了，而其后 900 毫秒 任何请求都无法处理。一般的处理方法是把时间粒度更精细一些，dubbogo 的时间窗口最小单位是一毫秒，则用户可以把时间窗口设定为 100 毫秒，总体来说一段时间内是很平稳的。下面这个图是我们社区的 commiter 邓明写完博客发出来，行业大佬微信评论如下：
+
+
+
+图中第一个问题是 qps 和 tps 每个请求成本不同，这个问题怎么处理呢？个人觉得这是一个分级限流问题，在同一个服务下针对不同的请求做不同的分级处理。第二个问题 ”配置了 qps 1000，但是请求过来是10万你还是死“，这个就需要更上层的运维能力进行应对，譬如判定为恶意流量攻击就应该在网关层拦截掉，如果是服务能力不行就扩容。
+
+针对分级限流，dubbogo 目前尚无法在同一个进程内完成，这需要 dubbogo 的配置中心更完善以后进行处理，用户可以通过搭建不同的服务链路处理之。譬如会员/非会员分级，同一个服务针对不同的会员等级搭建相应的链路，在网关层就判定一个 userID 是否是会员，然后发送不同的链路。
+
+dubbogo 的单机熔断是基于 hystrix-go 实现的，其判定参数有最大并发请求数、超时时间、错误率；其次是保护窗口，是熔断时长，熔断多久后进行服务恢复；第三个是保护性动作，就是在保护时间窗口之内执行什么样的动作，具体实现用户自定义。
+
+
+
+### 优雅退出
+
+优雅退出也是邓明同学的大作，可以在网络上搜到相关博客。实现优雅退出的步骤有：
+
+1. 告知注册中心，服务即将关闭，此时等待并处理请求；
+2. 注册中心通知别的客户端，别的客户端停止发送新请求，等待已发请求的响应；
+3. 节点处理完所有接收到的请求并且返回响应后，释放作为服务端相关的组件和资源；
+4. 节点释放作为客户端的组件和资源。
+
+
+
+所以每一步基本上都要给程序一定的时间进行等待，所以等的时间窗口是多少呢？dubbogo 默认每个步骤大概花2秒，总体一个时间窗口是10秒。
+
+
+
+基本上在别的 RPC 框架里面，可能不太常见到这种处理。
+
+## 五 Dubbogo 上云
+
+dubbogo 作为微服务框架如何适配 k8s，如何部署？dubbogo 本身是一个 RPC 框架，但是其又有了服务治理能力，这部分能力与 k8s 的部分能力有些重合，不可能为了适配 k8s 就彻底抛弃。目前 Dubbo 官方也没有很好的解决方案供我们参考，所以这里我们 dubbogo 先给出一个简单的常识性的实践方案。下面先分析下 dubbogo 的 interface/service 和 k8s service 两者直接的差别。
+
+
+
+k8s service 是许多具有相同服务能力 pod 资源的聚合，它自己的负载均衡算法以及健康检查等功能。而 Dubbo 里面的 interface/service 仅仅是服务 provider 集合，服务治理能力依赖 dubbo 的 directory、router 和 loadbalace 等额外的功能模块。并且Dubbo 服务区分 group/version，还有 provider、consumer 角色等等。Dubbo interface/service 无法与 k8s service 对标，Dubbo interface/service 和其整体服务治理能力才能对标成 k8s service。二者差异这么大，如何将 dubbo 集成到 k8s 中呢？
+
+k8s 提供了 pod/endpoint/service 三层维度的资源。简单的做法，可以通过监听pod/endpoint/service 三层维度资源的事件，作出合理的处理以达到服务治理的目的。目前我们社区成员王翔提交了一个基于监听 pod 事件来实现服务治理的 pr，优点就是不需要引入额外组件，通过监听 k8s 中最细粒度资源 pod 的事件，通过 k8s apiserver 获取 pod 列表，只是通过 apiserver 使用 etcd 的服务注册和服务通知能力，其他继续使用 Dubbo 的服务治理能力。其优点是模型简单，不需要实现额外的模块，几乎不需要对 Dubbo 作出改动，缺点就是其实无法使用 k8s 自己的健康检查能力，需要自己监听很细粒度的 pod 事件来综合处理服务健康、服务上下线等情况，而且还存在没有使用 k8s service 的事件监听能力，每个 consumer 冗余监听一些不必要监听的事件，加大 apiserver 的网络压力。所以其实
现目前来看可能还不是最优解，与 k8s 建议的operator 方式也有一定的背离。社区目前还在讨论新方案 [...]
+
+## 六 互融互通
+
+关于互融互通，Dubbo 明年有个三个重要目标，其中一个目标是与外面的微服务生态进行互联互通，比如说跟 grpc 互通。目前 dubbo 的 grpc 的解决方案已经开放出来，dubbogo 与 grpc 互通的开发工作也几近完成。
+
+下面左边 dubbogo 的代码生成器工具根据 grpc 的 pb 服务定义文件自动生成的适配 dubbogo 的代码，右边是对应的使用示例。不同于 k8s service 的复杂性，grpc 整体仅仅具有 rpc 能力，没有服务治理能力，所以原始的 grpc 就可以很好的嵌入到 dubbogo 里面，grpc server 的 methodhandler 对我们 dubbogo 来说就是 dubbo invoker，grpc 的一些相关的接口直接跟我们的接口嵌套起来，两个生态就对接起来了。
+
+
+
+
+## 七 展望未来
+
+最后就是展望未来，也就是明年的规划。
+
+
+
+明年我们将会很快实现 dubbo router。社区在 8月份已经实现了 router 功能需要的底层的算法模块，但是当时配置中心下发相关的参数的能力还不是很强，所以没有最终完成。最近服务治理配置刚刚支持了 zookeeper 和 apollo，预计很快就可以将 router 的参数通过配置中心下发的形式支持掉。另外，还有 tracing，我们将会引入社区主流的 tracing 方案，以 opentracing 为标准，去集成 opentracing 开源生态的相关能力。第三个是 kubernetes operator，这个就是刚才说的 K8s 的服务调用，我们会基于 operator 的方案做一版新的基于 k8s 的注册中心实现。最后就是云原生生态的融入，即与 istio 的集成，dubbogo 将会成为 dubbo 在 service mesh 生态中的重要角色。
+
+目前 dubbogo 项目，今年是能 run 起来，质量方面还有很多工作要做，功能基本上到明年可与 dubbo 2.7 补齐，目前已经基本够用。目前落地实践的是 3 个比较典型的公司，一个是携程，还有一个是涂鸦智能。
+
+dubbogo 本身是一个 go 语言项目，也期待与其他 go 社区的指正或者需求，一起成长。
\ No newline at end of file
diff --git a/static/imgs/blog/dubbo-go/busy-idle-time-window.png b/static/imgs/blog/dubbo-go/busy-idle-time-window.png
new file mode 100644
index 0000000..e671ff5
Binary files /dev/null and b/static/imgs/blog/dubbo-go/busy-idle-time-window.png differ
diff --git a/static/imgs/blog/dubbo-go/connected_udp_socket.gif b/static/imgs/blog/dubbo-go/connected_udp_socket.gif
new file mode 100644
index 0000000..011cd23
Binary files /dev/null and b/static/imgs/blog/dubbo-go/connected_udp_socket.gif differ
diff --git a/static/imgs/blog/dubbo-go/dns_udp.gif b/static/imgs/blog/dubbo-go/dns_udp.gif
new file mode 100644
index 0000000..253dddf
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dns_udp.gif differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-arch.png b/static/imgs/blog/dubbo-go/dubbo-go-arch.png
new file mode 100644
index 0000000..6783926
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-arch.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-curcuit-breaker.png b/static/imgs/blog/dubbo-go/dubbo-go-curcuit-breaker.png
new file mode 100644
index 0000000..1ea5105
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-curcuit-breaker.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-generic-invoke.png b/static/imgs/blog/dubbo-go/dubbo-go-generic-invoke.png
new file mode 100644
index 0000000..0e2c25b
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-generic-invoke.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-getty.png b/static/imgs/blog/dubbo-go/dubbo-go-getty.png
new file mode 100644
index 0000000..ffde3b5
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-getty.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-hessian2.png b/static/imgs/blog/dubbo-go/dubbo-go-hessian2.png
new file mode 100644
index 0000000..1368e1c
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-hessian2.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-history.png b/static/imgs/blog/dubbo-go/dubbo-go-history.png
new file mode 100644
index 0000000..0f77e7c
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-history.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-logo.jpg b/static/imgs/blog/dubbo-go/dubbo-go-logo.jpg
new file mode 100644
index 0000000..69c70c7
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-logo.jpg differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-go-roadmap-2019.png b/static/imgs/blog/dubbo-go/dubbo-go-roadmap-2019.png
new file mode 100644
index 0000000..f5ae884
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-go-roadmap-2019.png differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-roadmap-2019.jpg b/static/imgs/blog/dubbo-go/dubbo-roadmap-2019.jpg
new file mode 100644
index 0000000..9cc7e64
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-roadmap-2019.jpg differ
diff --git a/static/imgs/blog/dubbo-go/dubbo-tlp-twitter.jpg b/static/imgs/blog/dubbo-go/dubbo-tlp-twitter.jpg
new file mode 100644
index 0000000..ce27147
Binary files /dev/null and b/static/imgs/blog/dubbo-go/dubbo-tlp-twitter.jpg differ
diff --git a/static/imgs/blog/dubbo-go/fixed-window.png b/static/imgs/blog/dubbo-go/fixed-window.png
new file mode 100644
index 0000000..49b30ef
Binary files /dev/null and b/static/imgs/blog/dubbo-go/fixed-window.png differ
diff --git a/static/imgs/blog/dubbo-go/go-consumer.png b/static/imgs/blog/dubbo-go/go-consumer.png
new file mode 100644
index 0000000..2fc84af
Binary files /dev/null and b/static/imgs/blog/dubbo-go/go-consumer.png differ
diff --git a/static/imgs/blog/dubbo-go/go-provider.png b/static/imgs/blog/dubbo-go/go-provider.png
new file mode 100644
index 0000000..fe5f233
Binary files /dev/null and b/static/imgs/blog/dubbo-go/go-provider.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p1.jpeg b/static/imgs/blog/dubbo-go/gochina/p1.jpeg
new file mode 100644
index 0000000..dc8f1dc
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p1.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p10.jpeg b/static/imgs/blog/dubbo-go/gochina/p10.jpeg
new file mode 100644
index 0000000..8eb3e7f
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p10.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p11.jpeg b/static/imgs/blog/dubbo-go/gochina/p11.jpeg
new file mode 100644
index 0000000..3af59c4
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p11.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p12.jpeg b/static/imgs/blog/dubbo-go/gochina/p12.jpeg
new file mode 100644
index 0000000..7e10f68
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p12.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p13.jpeg b/static/imgs/blog/dubbo-go/gochina/p13.jpeg
new file mode 100644
index 0000000..17d78da
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p13.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p14.jpeg b/static/imgs/blog/dubbo-go/gochina/p14.jpeg
new file mode 100644
index 0000000..b64a975
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p14.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p15.png b/static/imgs/blog/dubbo-go/gochina/p15.png
new file mode 100644
index 0000000..f97468c
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p15.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p16.png b/static/imgs/blog/dubbo-go/gochina/p16.png
new file mode 100644
index 0000000..3f9e924
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p16.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p17.jpeg b/static/imgs/blog/dubbo-go/gochina/p17.jpeg
new file mode 100644
index 0000000..48bb4a9
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p17.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p18.jpeg b/static/imgs/blog/dubbo-go/gochina/p18.jpeg
new file mode 100644
index 0000000..7229033
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p18.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p19.jpeg b/static/imgs/blog/dubbo-go/gochina/p19.jpeg
new file mode 100644
index 0000000..33b4d74
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p19.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p2.jpeg b/static/imgs/blog/dubbo-go/gochina/p2.jpeg
new file mode 100644
index 0000000..a823457
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p2.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p20.png b/static/imgs/blog/dubbo-go/gochina/p20.png
new file mode 100644
index 0000000..7aee88f
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p20.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p21.png b/static/imgs/blog/dubbo-go/gochina/p21.png
new file mode 100644
index 0000000..99649af
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p21.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p22.jpeg b/static/imgs/blog/dubbo-go/gochina/p22.jpeg
new file mode 100644
index 0000000..909738e
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p22.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p23.jpeg b/static/imgs/blog/dubbo-go/gochina/p23.jpeg
new file mode 100644
index 0000000..ec8606b
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p23.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p24.png b/static/imgs/blog/dubbo-go/gochina/p24.png
new file mode 100644
index 0000000..328e046
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p24.png differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p25.jpeg b/static/imgs/blog/dubbo-go/gochina/p25.jpeg
new file mode 100644
index 0000000..c8f1801
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p25.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p26.jpeg b/static/imgs/blog/dubbo-go/gochina/p26.jpeg
new file mode 100644
index 0000000..219784c
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p26.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p3.jpeg b/static/imgs/blog/dubbo-go/gochina/p3.jpeg
new file mode 100644
index 0000000..652bd00
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p3.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p4.jpeg b/static/imgs/blog/dubbo-go/gochina/p4.jpeg
new file mode 100644
index 0000000..5371cbb
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p4.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p5.jpeg b/static/imgs/blog/dubbo-go/gochina/p5.jpeg
new file mode 100644
index 0000000..ad7a3f4
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p5.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p6.jpeg b/static/imgs/blog/dubbo-go/gochina/p6.jpeg
new file mode 100644
index 0000000..13812d7
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p6.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p7.jpeg b/static/imgs/blog/dubbo-go/gochina/p7.jpeg
new file mode 100644
index 0000000..1a174ae
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p7.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p8.jpeg b/static/imgs/blog/dubbo-go/gochina/p8.jpeg
new file mode 100644
index 0000000..fc398af
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p8.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/gochina/p9.jpeg b/static/imgs/blog/dubbo-go/gochina/p9.jpeg
new file mode 100644
index 0000000..42558f4
Binary files /dev/null and b/static/imgs/blog/dubbo-go/gochina/p9.jpeg differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p1.webp b/static/imgs/blog/dubbo-go/grpc/p1.webp
new file mode 100644
index 0000000..45ebc2c
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p1.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p10.webp b/static/imgs/blog/dubbo-go/grpc/p10.webp
new file mode 100644
index 0000000..5e173ad
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p10.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p11.webp b/static/imgs/blog/dubbo-go/grpc/p11.webp
new file mode 100644
index 0000000..9229279
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p11.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p12.webp b/static/imgs/blog/dubbo-go/grpc/p12.webp
new file mode 100644
index 0000000..78a0b75
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p12.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p13.webp b/static/imgs/blog/dubbo-go/grpc/p13.webp
new file mode 100644
index 0000000..5b57aee
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p13.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p14.webp b/static/imgs/blog/dubbo-go/grpc/p14.webp
new file mode 100644
index 0000000..1220afd
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p14.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p2.webp b/static/imgs/blog/dubbo-go/grpc/p2.webp
new file mode 100644
index 0000000..e889897
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p2.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p3.webp b/static/imgs/blog/dubbo-go/grpc/p3.webp
new file mode 100644
index 0000000..ea13224
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p3.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p4.webp b/static/imgs/blog/dubbo-go/grpc/p4.webp
new file mode 100644
index 0000000..1865170
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p4.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p5.webp b/static/imgs/blog/dubbo-go/grpc/p5.webp
new file mode 100644
index 0000000..cb64347
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p5.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p6.webp b/static/imgs/blog/dubbo-go/grpc/p6.webp
new file mode 100644
index 0000000..4ee3dff
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p6.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p7.webp b/static/imgs/blog/dubbo-go/grpc/p7.webp
new file mode 100644
index 0000000..488bf38
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p7.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p8.webp b/static/imgs/blog/dubbo-go/grpc/p8.webp
new file mode 100644
index 0000000..df50648
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p8.webp differ
diff --git a/static/imgs/blog/dubbo-go/grpc/p9.webp b/static/imgs/blog/dubbo-go/grpc/p9.webp
new file mode 100644
index 0000000..7b84140
Binary files /dev/null and b/static/imgs/blog/dubbo-go/grpc/p9.webp differ
diff --git a/static/imgs/blog/dubbo-go/java-go-interop.png b/static/imgs/blog/dubbo-go/java-go-interop.png
new file mode 100644
index 0000000..5229818
Binary files /dev/null and b/static/imgs/blog/dubbo-go/java-go-interop.png differ
diff --git a/static/imgs/blog/dubbo-go/java-provider.png b/static/imgs/blog/dubbo-go/java-provider.png
new file mode 100644
index 0000000..3189a48
Binary files /dev/null and b/static/imgs/blog/dubbo-go/java-provider.png differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p1.png b/static/imgs/blog/dubbo-go/metrics/p1.png
new file mode 100644
index 0000000..0f4f3bf
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p1.png differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p10.webp b/static/imgs/blog/dubbo-go/metrics/p10.webp
new file mode 100644
index 0000000..aec4524
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p10.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p11.webp b/static/imgs/blog/dubbo-go/metrics/p11.webp
new file mode 100644
index 0000000..8b85903
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p11.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p12.webp b/static/imgs/blog/dubbo-go/metrics/p12.webp
new file mode 100644
index 0000000..dd49e55
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p12.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p2.webp b/static/imgs/blog/dubbo-go/metrics/p2.webp
new file mode 100644
index 0000000..becb8db
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p2.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p3.webp b/static/imgs/blog/dubbo-go/metrics/p3.webp
new file mode 100644
index 0000000..8542c87
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p3.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p4.webp b/static/imgs/blog/dubbo-go/metrics/p4.webp
new file mode 100644
index 0000000..9cd95ee
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p4.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p5.webp b/static/imgs/blog/dubbo-go/metrics/p5.webp
new file mode 100644
index 0000000..0b72479
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p5.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p6.webp b/static/imgs/blog/dubbo-go/metrics/p6.webp
new file mode 100644
index 0000000..8240803
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p6.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p7.webp b/static/imgs/blog/dubbo-go/metrics/p7.webp
new file mode 100644
index 0000000..10d6238
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p7.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p8.webp b/static/imgs/blog/dubbo-go/metrics/p8.webp
new file mode 100644
index 0000000..7123293
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p8.webp differ
diff --git a/static/imgs/blog/dubbo-go/metrics/p9.webp b/static/imgs/blog/dubbo-go/metrics/p9.webp
new file mode 100644
index 0000000..730a4db
Binary files /dev/null and b/static/imgs/blog/dubbo-go/metrics/p9.webp differ
diff --git a/static/imgs/blog/dubbo-go/sliding-window.png b/static/imgs/blog/dubbo-go/sliding-window.png
new file mode 100644
index 0000000..132057b
Binary files /dev/null and b/static/imgs/blog/dubbo-go/sliding-window.png differ
diff --git a/static/imgs/blog/dubbo-go/tps-limit-filter.png b/static/imgs/blog/dubbo-go/tps-limit-filter.png
new file mode 100644
index 0000000..8a34165
Binary files /dev/null and b/static/imgs/blog/dubbo-go/tps-limit-filter.png differ
diff --git a/static/imgs/blog/dubbo-go/tps-limiter.png b/static/imgs/blog/dubbo-go/tps-limiter.png
new file mode 100644
index 0000000..3a6f1f1
Binary files /dev/null and b/static/imgs/blog/dubbo-go/tps-limiter.png differ