update post

Signed-off-by: zhaohuabing <zhaohuabing@gmail.com>

content/zh/docs/v1.x/tutorials/dubbo.md

@@ -22,12 +22,12 @@ Dubbo2Istio 可以连接 Dubbo 服务注册表，将其中注册的 Dubbo 服务
 Dubbo 是一种 RPC 协议，来源于 SOA 时代，因此没有严格遵循微服务原则将一个服务实现为一个进程。在 Dubbo 中，有一个 Interface 的概念，一个进程中通常会有多个I nterface。当将 Dubbo 应用加入到服务网格进行服务治理时，有两个选择：
 
 * 按应用（进程）粒度进行服务治理，即以应用作为 Mesh 中的一个 Service。
- * 优点：Mesh 中的 Service 数量相对于接口级服务治理方案更少，控制面需要下发的xds配置少，控制面和 Sidecar 的资源占用相对小。
- * 缺点：无法按照Interface进行流量治理，包括灰度发布、限流、流量镜像等，只能按照应用级别进行流量治理。
+  * 优点：Mesh 中的 Service 数量相对于接口级服务治理方案更少，控制面需要下发的xds配置少，控制面和 Sidecar 的资源占用相对小。
+  * 缺点：无法按照Interface进行流量治理，包括灰度发布、限流、流量镜像等，只能按照应用级别进行流量治理。
 
 * 按接口（Interface）粒度进行服务治理，即以 Dubbo Interface 作为 Mesh 中的一个 Service。
- * 优点：可以按接口进行流量治理，包括灰度发布、限流、流量镜像等。
- * 缺点：Mesh 中的 Service 数量相对于应用级服务治理方案更多，控制面需要下发的xds配置多，控制面和 Sidecar 的资源占用相对大。
+  * 优点：可以按接口进行流量治理，包括灰度发布、限流、流量镜像等。
+  * 缺点：Mesh 中的 Service 数量相对于应用级服务治理方案更多，控制面需要下发的xds配置多，控制面和 Sidecar 的资源占用相对大。
 
 可以看出，这两种治理方式各有优缺点。一般来说，当 Dubbo 应用规模较大、Interface 较多时，建议选择按照应用粒度进行服务治理，以减轻控制面负荷和 Sidecar 的资源消耗；当 Dubbo 应用规模较小、Interfac 数量较少时，建议选择按照 Interface 粒度进行服务治理，以提供最精细的流量治理能力。