作為 nacos 5w1h 的系列文章，本文將圍繞「where」，講述 nacos 配置管理的三個典型的應用場景：
spring.datasource.url=生產環境的資料庫連線位址
spring.datasource.username=生產環境的資料庫使用者賬號
spring.datasource.password=生產環境的資料庫使用者密碼
複製**
spring.datasource.url=開發環境的資料庫連線位址
spring.datasource.username=開發環境的資料庫使用者賬號
spring.datasource.password=開發環境的資料庫使用者密碼
複製**
回想起來，我當時給的建議並沒有完全解決他的問題，甚至還帶來了其他一些問題。例如，上述的第一點，「將敏感配置從專案剝離」，剝離出來的敏感配置存放到**？怎麼管理這些配置呢？也許，你會想到，存放到應用部署機器的環境變數或某個檔案中。不，一樣有風險，說不定哪天開發同學必須得登入上機器排查問題，就有洩露的風險，總之，得盡可能地做到在整個開發流程都不會有任何洩露的風險。應用中可能不只是連線乙個資料來源，分庫分表的情況，不同資料儲存（如 mysql / redis / elasticsearch 等）的情況，還有，其他更多敏感配置項，配置資料的增多會給管理帶來不便。
另外，「定期修改資料庫賬號、密碼」，修改後我能怎麼方便快捷的下發到所有應用程式中呢？既然是敏感配置，其變更也會帶來不少的風險，我需要能先到小量的幾台機器驗證，保證對業務無影響，我再全部下發到其他所有的機器上去，是否還得有「灰度發布」的功能呢？賬號密碼修改下發後，應用出現異常，影響到業務了，我要怎麼快速地回滾呢？是否還得有「版本控制」、「快速回滾」的功能呢？不是所有的開發同學都有許可權能修改敏感配置資訊，是否還需要有「許可權管控」的功能？對敏感配置的任何操作都應該被記錄，是否還需要有「變更審計」的功能呢？
現在，我有了更好的建議：使用 nacos 配置管理模組，將敏感配置資訊都存放到 nacos 中。nacos 配置管理，其中乙個立身之本就是為敏感配置保駕護航。它提供上述場景所需的功能，通過命名空間區分不同環境（開發、測試、預發、生產），通過「版本控制」保證變更可追溯，通過「快速回滾」保證錯誤變更時影響最小，通過的「灰度發布」功能保障配置安全平穩地變更，還有更多更全面功能（許可權管控、變更審計等）即將支援。
那麼，怎麼將敏感配置專案的配置檔案中遷移到 nacos 中呢？下面以 spring boot 連線 mysql 為例：
新增依賴
com.alibaba.boot
nacos-config-spring-boot-starter
$複製**
注意 spring boot 1.x 使用 nacos-config-spring-boot-starter 0.1.x 版本，spring boot 2.x 使用 nacos-config-spring-boot-starter 0.2.x 版本。
nacos.config.server-addr=127.0.0.1:8848
複製**
新增 @nacospropertysource 註解
@nacospropertysource(dataid = "mysql.properties")
public static void main(string args)
複製**
在本地啟動的 nacos 控制台上新增 dataid 為 mysql.properties 的配置，配置內容為 mysql 連線配置資訊：
完整示例**請參看：github.com/nacos-group…
限流、降級，眾所周知，是在開發高併發系統過程中需要考慮的兩大關鍵點，是執行時保護系統的兩大利器。限流閾值和降級開關，最終是抽象為乙個個的配置項，要想實現執行時的動態調整閾值和開關的啟停，將這些配置項存放到 nacos 的配置模組中最適合不過了。
在今年 8 月的時候，阿里巴巴開源了 sentinel，以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。在阿里巴巴內部，nacos 跟 sentinel 就是多年攜手相伴，砥礪前行的好機油，為雙 11 等各種大促立下了功勞，也為剁手黨提供了良好的購物體驗。
下面就以 sentinel 流控為例，演示如果通過 nacos 來做到執行時的動態控制流量：
新增依賴
com.alibaba.csp
sentinel-core
$com.alibaba.csp
sentinel-datasource-extension
$com.alibaba.csp
sentinel-datasource-nacos
$com.alibaba
fastjson
$複製**
2.模擬併發請求
final class runtask implements runnable catch (blockexception e1) catch (exception e2) finally
}random random2 = new random();
try catch (interruptedexception e)
}}複製**
public class nacosdynamicflowdemo ));
flowrulemanager.register2property(flowruledatasource.getproperty());
// assume we config: resource is `testresource`, initial qps threshold is 5.
flowqpsrunner runner = new flowqpsrunner(key, 1, 10000);
runner.simulatetraffic();
runner.tick();
}複製**
5.執行 nacosdynamicflowdemo，你會看到如下標準輸出資訊
再到 nacos 控制台修改剛剛新建的流控配置，將限流閾值 count 的值修改為 1.0，完整的標準輸出資訊如下
完整示例**請參看：github.com/nacos-group…
流量的動態排程
業務發展壯大到一定的規模，單一的集群已經承載不了全部的使用者請求，需要將使用者的流量分流到不同的集群上。當然，更進一步的方案是：不同的集群位於不同的區域，這樣，除了緩解業務處理的壓力，也給系統帶來容災的能力。
比如，某電商系統有 1 億使用者量，將系統的流量按照使用者的 id 進行切分，id 為 1-1000w 的使用者請求分發到區域 a 的集群 a 上，id 為 10001w-2000w 的使用者請求流量分發到區域 b 的集群 b 上，以此類推，最終將所有使用者的請求流量打散到 10 個不同區域的集群上，同時，每個集群冗餘了一些系統資源。當區域 a 的機房發生不可抗的災難（如**）時，我們需要有動態排程流量的能力，最好能秒級得將流量從區域 a 排程到另外可用的區域的集群上。
這正是 nacos 配置管理大有作為的地方，將使用者 id 的分片和對應的路由規則存放在 nacos 的中，配合統一接入層等的元件，就能將流量打散到各個集群上，進而讓系統能承載更大的流量，以更好的支撐業務的發展。另外，將其存放與 nacos 中，也就具備了配置「動態化」的能力，一旦某區域出現基礎設施無法及時恢復的問題時，只需在 nacos 的控制台上修改 id 分片的路由規則，就能將有問題的區域流量快速切換到其他可用的區域上，保障對業務幾乎無損。nacos 在阿里內部能做到秒級推送到十萬級別機器上的推送效率。
除了以上三個場景，其實還有更多更大膽的應用場景，如「大資料實時計算演算法調整」、「異地容災多活」、「應用業務場景動態推送」等等，可以參看 nacos 的阿里雲產品 acm 的使用場景 。nacos 配置管理模組，將敏感配置收攏管控起來，極大降低資料洩露等風險，並且提供如「動態推送」、「版本控制」、「快速回滾」等功能，保障了敏感配置的變更安全平穩的執行。
在限流與降級的場景，通過乙個示例，為大家演示了如何通過 nacos + sentinel 實現流量的動態控制，這也是 nacos 配置管理的乙個十分典型的應用場景。降級也一樣，大促高峰期間將某個非關鍵的系統元件進行關閉，在過了高峰期後再開啟，這個也是可以通過 nacos 的「動態推送」的功能來實現。
總之，只要系統涉及到了「敏感的配置」、「動態的配置」，都應該考慮將配置放入到 nacos 中，讓 nacos 管控起來。
結合實際場景談一談微服務配置
作為 nacos 5w1h 的系列文章，本文將圍繞 where 講述 nacos 配置管理的三個典型的應用場景 spring.datasource.url 生產環境的資料庫連線位址 spring.datasource.username 生產環境的資料庫使用者賬號 spring.datasource....
三 結合實際，談索引使用的誤區
理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際情況進行綜合分析。下面我們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。1 主鍵就是聚集索引 這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖...
lodash常用方法結合實際專案解析
官方定義 該方法類似 assign，除了它遞迴合併sources 物件自身和繼承的可列舉屬性到object目標物件。如果目標值存在，被解析為undefined的sources 物件屬性將被跳過。陣列和普通物件會遞迴合併，其他物件和值會被直接分配覆蓋。源物件從從左到右分配。後續的 物件屬性會覆蓋之前分...