add newlines to some docs

docs/cn/client.md

@@ -98,18 +98,28 @@ BNS是百度内常用的命名服务，比如bns://rdev.matrix.all，其中"bns"
 10.24.234.18
 10.24.234.19
 ```
-此命名服务的优点是易于修改，方便单测；缺点是非中心管理，更新时需要修改每个上游的列表文件，不适合线上部署。
+
+优点: 易于修改，方便单测。
+
+缺点: 更新时需要修改每个上游的列表文件，不适合线上部署。
 
 ### list://\<addr1\>,\<addr2\>...
 
 服务器列表直接跟在list://之后，以逗号分隔，比如"list://db-bce-81-3-186.db01:7000,m1-bce-44-67-72.m1:7000,cp01-rd-cos-006.cp01:7000"中有三个地址。
+
 地址后可以声明tag，用一个或多个空格分隔，相同的地址+不同的tag被认为是不同的实例。
-此命名服务的优点是可在命令行中直接配置，方便单测；缺点是无法在运行时修改，完全不能用于线上部署。
+
+优点: 可在命令行中直接配置，方便单测。
+
+缺点: 无法在运行时修改，完全不能用于线上部署。
 
 ### http://\<url\>
 
 连接一个域名下所有的机器, 例如http://www.baidu.com:80 ，注意连接单点的Init（两个参数）虽然也可传入域名，但只会连接域名下的一台机器。
-此命名服务的优点在于DNS的通用性，公网内网均可使用；缺点是受限于DNS的格式限制无法传递复杂的meta数据，也无法实现通知机制。
+
+优点: DNS的通用性，公网内网均可使用。
+
+缺点: 受限于DNS的格式限制无法传递复杂的meta数据，也无法实现通知机制。
 
 ### consul://\<service-name\>
 
@@ -131,8 +141,11 @@ tag的用途主要是实现“粗粒度的wrr”，当给同一个地址加上
 
 ### VIP相关的问题
 VIP一般是4层负载均衡器的公网ip，背后有多个RS。当客户端连接至VIP时，VIP会选择一个RS建立连接，当客户端连接断开时，VIP也会断开与对应RS的连接。
+
 如果客户端只与VIP建立一个连接(brpc中的单连接)，那么来自这个客户端的所有流量都会落到一台RS上。如果客户端的数量非常多，至少在集群的角度，所有的RS还是会分到足够多的连接，从而基本均衡。但如果客户端的数量不多，或客户端的负载差异很大，那么可能在个别RS上出现热点。另一个问题是当有多个vip可选时，客户端分给它们的流量与各自后面的RS数量可能不一致。
+
 解决这个问题的一种方法是使用连接池模式(pooled)，这样客户端对一个vip就可能建立多个连接(约为一段时间内的最大并发度)，从而让负载落到多个RS上。如果有多个vip，可以用[wrr负载均衡](#wrr)给不同的vip声明不同的权重从而分到对应比例的流量，或给相同的vip后加上多个不同的tag而被认为是多个不同的实例。
+
 注意：在客户端使用单连接时，给相同的vip加上不同的tag确实能让这个vip分到更多的流量，但连接仍然只会有一个，这是由目前brpc实现决定的。
 
 ### 命名服务过滤器

docs/en/client.md

@@ -98,18 +98,30 @@ Servers are put in the file specified by `path`. For example, in "file://conf/ma
 10.24.234.18
 10.24.234.19
 ```
-Pros: easy to modify, convenient for unittests. Cons: need to update every client when the list changes, not suitable for online deployment.
+
+Pros: easy to modify, convenient for unittests.
+
+Cons: need to update every client when the list changes, not suitable for online deployment.
 
 ### list://\<addr1\>,\<addr2\>...
 
 Servers are directly written after list://, separated by comma. For example: "list://db-bce-81-3-186.db01:7000,m1-bce-44-67-72.m1:7000,cp01-rd-cos-006.cp01:7000" has 3 addresses.
+
 Tags can be appended to addresses, separated with one or more spaces. Same address + different tags are treated as different instances.
-Pros: directly configurable in CLI, convenient for unittests. Cons: cannot be updated at runtime, not suitable for online deployment at all.
+
+Pros: directly configurable in CLI, convenient for unittests.
+
+Cons: cannot be updated at runtime, not suitable for online deployment at all.
 
 ### http://\<url\>
 
-Connect all servers under the domain, for example: http://www.baidu.com:80. Note: although Init() for connecting single server(2 parameters) accepts hostname as well, it only connects one server under the domain.
-Pros: Versatility of DNS, useable both in private or public network. Cons: limited by transmission formats of DNS, unable to implement notification mechanisms.
+Connect all servers under the domain, for example: http://www.baidu.com:80. 
+
+Note: although Init() for connecting single server(2 parameters) accepts hostname as well, it only connects one server under the domain.
+
+Pros: Versatility of DNS, useable both in private or public network.
+
+Cons: limited by transmission formats of DNS, unable to implement notification mechanisms.
 
 ### consul://\<service-name\>
 
@@ -131,8 +143,11 @@ tag was used for implementing "coarse-grained wrr": different tags are appended
 
 ### VIP related issues
 VIP is often the public IP of layer-4 load balancer, which proxies traffic to RS behide. When a client connects to the VIP, a connection is established to a chosen RS. When the client connection is broken, the connection to the RS is reset as well.
+
 If one client establishes only one connection to the VIP("single" connection type in brpc), all traffic from the client lands on one RS. If number of clients are large enough, each RS should gets many connections and roughly balanced, at least from the cluster perspective. However, if clients are not large enough or workload from clients are very different, some RS may be overloaded. Another issue is that when multiple VIP are listed together, the traffic to them may not be proportional to the number of RS behide them.
+
 One solution to these issues is to use "pooled" connection type, so that one client may create multiple connections to one VIP (roughly the max concurrency recently) to make traffic land on different RS. If more than one VIP are present, consider using [wrr load balancing](#wrr) to assign weights to different VIP, or add different tags to VIP to form more instances.
+
 Note: When the client uses "single" connection type, even if one VIP appended with different tags can get more traffic, the connection is still one. This is decided by current implementation in brpc.
 
 ### Naming Service Filter