From 1cc2a20d1850b6206c32848ca15ff541619de353 Mon Sep 17 00:00:00 2001
From: pbting <314226532@qq.com>
Date: Wed, 5 Dec 2018 20:51:05 +0800
Subject: [PATCH] update the format

---
 .../src/main/asciidoc-zh/nacos-config-custom-solution.adoc     | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/spring-cloud-alibaba-docs/src/main/asciidoc-zh/nacos-config-custom-solution.adoc b/spring-cloud-alibaba-docs/src/main/asciidoc-zh/nacos-config-custom-solution.adoc
index 7be806ae..100b92df 100644
--- a/spring-cloud-alibaba-docs/src/main/asciidoc-zh/nacos-config-custom-solution.adoc
+++ b/spring-cloud-alibaba-docs/src/main/asciidoc-zh/nacos-config-custom-solution.adoc
@@ -70,11 +70,8 @@ Spring Boot 提倡约定大于配置。当使用这种方式来实现应用间
 这种方式的优点在于：
 
 * dataid的命名方式完全交给业务方本身，不受 SCA Nacos Config Starter 实现的束缚。
-
 * dataid的命名方式既可以参考第一种方式来命名，又可以充分的发挥主观能动性，结合自己实际的业务给dataid命名。
-
 * 减少了多个应用间如果file-extension不一致，为每个 file-extension 多加这么一个配置的麻烦。
-
 * 当使用这种方式时，不会为这些共享配置强制绑定一个 file-extenson，即可以直接在我们暴露出来的一个变量中 dataid以file-extension 结尾。如果没有显示的说明，这个时候就会以file-extenson为准。
 
 当然这种方案的缺点在于扩展性不强。即如果对于某个共享配置需要做额外的配置，例如额外配置Group/是否需要刷新/是否需要从本地缓存加载等等。因此为了应对这种类型的场景，小组内讨论出了第三种方案。