add more images

docs/cn/client.md

@@ -339,9 +339,7 @@ brpc::DoNothing()可获得一个什么都不干的done，专门用于半同步
 
 brpc::StartCancel(CallId)可取消任意RPC，CallId必须**在发起RPC前**通过Controller.call_id()获得，其他时刻都可能有race condition。
 
-Icon
-
-是brpc::StartCancel(CallId)，不是controller.StartCancel()，后者被禁用，没有效果。
+> 是brpc::StartCancel(CallId)，不是controller.StartCancel()，后者被禁用，没有效果。
 
 顾名思义，StartCancel调用完成后RPC并未立刻结束，你不应该碰触Controller的任何字段或删除任何资源，它们自然会在RPC结束时被done中对应逻辑处理。如果你一定要在原地等到RPC结束（一般不需要），则可通过Join(call_id)。
 

docs/cn/flags.md

@@ -69,41 +69,39 @@ flagfile中可以使用`--flagfile包含另一个flagfile。`
 
 访问/flags/NAME?setvalue=VALUE即可动态修改一个gflag的值，validator会被调用。
 
-Icon
-
 为了防止误修改，需要动态修改的gflag必须有validator，显示此类gflag名字时有(R)后缀。
 
-![img](http://wiki.baidu.com/download/thumbnails/71337189/image2015-9-21%2021%3A49%3A48.png?version=1&modificationDate=1442843389000&api=v2)
+![img](../images/reloadable_flags.png)
 
 *修改成功后会显示如下信息*：
 
-![img](http://wiki.baidu.com/download/attachments/37774685/image2015-2-22%2012%3A30%3A54.png?version=1&modificationDate=1424579454000&api=v2)
+![img](../images/flag_setvalue.png)
 
 *尝试修改不允许修改的gflag会显示如下错误信息*：
 
-![img](http://wiki.baidu.com/download/attachments/37774685/image2015-2-22%2012%3A30%3A1.png?version=1&modificationDate=1424579401000&api=v2)
+![img](../images/set_flag_reject.png)
 
 *设置一个不允许的值会显示如下错误（flag值不会变化）*：
 
-![img](http://wiki.baidu.com/download/attachments/37774685/image2015-2-22%2012%3A35%3A9.png?version=1&modificationDate=1424579709000&api=v2)
+![img](../images/set_flag_invalid_value.png)
 
  
 
 r31658之后支持可视化地修改，在浏览器上访问时将看到(R)下多了下划线：
 
-![img](http://wiki.baidu.com/download/attachments/71337189/image2015-12-24%2022%3A55%3A29.png?version=1&modificationDate=1450968931000&api=v2)
+![img](../images/the_r_after_flag.png)
 
 点击后在一个独立页面可视化地修改对应的flag：
 
-![img](http://wiki.baidu.com/download/attachments/71337189/image2015-12-24%2022%3A56%3A3.png?version=1&modificationDate=1450968965000&api=v2)
+![img](../images/set_flag_with_form.png)
 
 填入true后确定：
 
-![img](http://wiki.baidu.com/download/attachments/71337189/image2015-12-24%2022%3A57%3A13.png?version=1&modificationDate=1450969035000&api=v2)
+![img](../images/set_flag_with_form_2.png)
 
 返回/flags可以看到对应的flag已经被修改了：
 
-![img](http://wiki.baidu.com/download/attachments/71337189/image2015-12-24%2022%3A57%3A57.png?version=1&modificationDate=1450969079000&api=v2)
+![img](../images/set_flag_with_form_3.png)
 
  
 

docs/cn/lalb.md

@@ -131,9 +131,7 @@ QPS和latency使用一个循环队列统计，默认容量128。我们可以使
 
 权值计算在各个环节都有最小值限制，为了防止某个节点的权值过低而使其完全没有访问机会。即使一些延时远大于平均延时的节点，也应该有足够的权值，以确保它们可以被定期访问，否则即使它们变快了，我们也不会知道。
 
-Icon
-
-除了待删除节点，所有节点的权值绝对不会为0。
+> 除了待删除节点，所有节点的权值绝对不会为0。
 
 这也制造了一个问题：即使一个server非常缓慢（但没有断开连接），它的权值也不会为0，所以总会有一些请求被定期送过去而铁定超时。当qps不高时，为了降低影响面，探测间隔必须拉长。比如为了把对qps=1000的影响控制在1%%内，故障server的权值必须低至使其探测间隔为10秒以上，这降低了我们发现server变快的速度。这个问题的解决方法有：
 

docs/cn/server_debugging.md

@@ -2,9 +2,7 @@
 
 查看 /vars/bthread_worker_**count** 和 /vars/bthread_worker_**usage**。分别是工作线程的个数，和正在被使用的工作线程个数。
 
-Icon
-
-如果usage和count接近，说明线程不够用了。
+> 如果usage和count接近，说明线程不够用了。
 
 比如，下图中有24个工作线程，正在使用的是23.93个，说明所有的工作线程都被打满了，不够用了。
 
@@ -20,9 +18,7 @@ Icon
 
 查看 /vars/process_core_**count** 和 /vars/process_cpu_**usage**。分别是cpu核心的个数，和正在使用的cpu核数。
 
-Icon
-
-如果usage和count接近，说明CPU不够用了。
+> 如果usage和count接近，说明CPU不够用了。
 
 下图中cpu核数为24，正在使用的核心数是20.9个，CPU是瓶颈了。