分布式配置中心

部署演進

單機配置檔案部署

當隨著業務的使用者量增加，通常我們會把我們的服務進行多機器（集群）部署。這時候，配置的發布就變成了如下，多機器配置

1.2、分配式配中心

傳統配置的方式已經暴露出了很多問題，其餘的諸如：歷史版本管理，許可權控制，安全性等等問題，是傳統的配置檔案無法處理的

隨著業務的發展、微服務架構的更新，服務的數量、程式的配置日益增多（各種微服務、各種伺服器位址、各種引數），傳統的配置檔案方式和資料庫的方式已無法滿足開發人員對配置管理的要求：

安全性：配置跟隨源**儲存在**庫中，容易造成配置洩漏；

時效性：修改配置，需要重啟服務才能生效；

侷限性：無法支援動態調整：例如日誌開關、功能開關；

我們選擇的技術棧是要解決實際業務問題和上生產抗流量的（選擇不慎可能造成生產級事故），而不是簡單做個 poc 或者 demo 展示，所以生產級（production ready），可運維（ops ready），可治理，成熟穩定的技術才是我們的首選

在滿足需求的條件下，選擇學習成本最低的方案，因為學習成本低意味著使用簡單、除錯簡單、維護簡單且更便於掌握，對整個專案團隊來說時間是最大的成本。

功能對比

這個指標不太好量化，所以不是很好把握，更多的是靠技術管理者的經驗了。技術前瞻性指標是可以作為社群活躍度指標的延續，換言之，如果一項技術具有較高的前瞻性，那麼其社群活躍度是會持續走高的，可能在乙個爆發節點會達到巔峰

2.3、選用apollo