我嘗試配置管理在云計算中具有很多相關性 爭論 較早。 實際上，我大膽地宣稱配置管理是任何認真嘗試從軟件中節省幾美元的基石。

那么什么是配置管理及其主要目標？ 在不使事情變得過于復雜的情況下，我認為接下來的兩個目標與事實相差不遠。

1. 以可預測的方式建立配置，以確保系統行為正確。
2. 隨著時間的變化，保持配置的一致性。

換句話說，能夠在整個軟件生命周期中以可靠和安全的方式管理行為的變化。

但是什么是配置？ 它是源代碼嗎？ 是否靜態加載到當前的類加載器中？ 可以在運行時更改它嗎？ 它是持久性數據嗎？ VCS是否跟蹤？ 實際上，它存儲在哪里？ 群集中的每臺計算機都可以訪問嗎？ 更改配置后會怎樣？ 我們是否關心更改是否經過驗證？ 用戶更改配置是否被授權這樣做？ 更改如何傳播到集群成員？ 是否會通知應用程序有關配置更改？

在此之前，我想回顧一下有關維護的知識。

維護通常會消耗大約40％至80％（平均60％）的軟件成本。 因此，它可能是最重要的生命周期階段。

關于軟件工程的經常被遺忘的基本事實

簡而言之（無需爭論數字），OAM既困難又昂貴，顯然在動態和彈性的云計算環境中更是如此。 從生產率的角度來看，如果我們可以設計軟件，從而避免反彈VCS，從部署管道一直到生產一直迭代產品發布，并且仍然能夠管理行為更改，那么我們也許應該考慮對嗎？ 顯然，這也將使軟件更適合于不同的環境，即Java的精神和靈魂。

我認為我們將使用配置來延遲決策 ，不僅是關于環境及其資源的決策，而且是針對應用程序業務特定決策的決策。 企業必須能夠快速配置與應用程序服務器資源/基礎架構無關的產品/規則。

因此，我認為發布后不得更改的部分（行為完整性）是程序的一部分，并且配置是運行時行為不變的，嚴格由程序策略控制，以便可以保證可預測的系統行為，并根據發生率在不同級別上實施變革–以有效，非侵入性和可靠的方式（但此為基調）。 我想到了開放/封閉原則。

在Java EE的上下文中，此定義仍然不夠清楚。 Java EE 6發布了DataSourceDefinition注釋，該注釋假設配置是代碼。 組裝者/部署者角色賦予了更多的配置靈活性。 簡而言之，目的是可以在部署之前就可以修改應用程序（特別是其xml描述符），可能會覆蓋硬編碼值。

這種方法一直使我感到困惑，但是也許這取決于不同的人如何看待哪種類型的數據被認為是配置？ 但是，我在職業生涯中從未聽說過，沒有聽說過或未見過任何實際使用過預期目的的人。 這樣做可能有充分的理由。

在Maven中，反饋循環的編譯和打包實際上是并行的-幾乎每個Maven項目都旨在以存檔的形式生成工件。 描述符由Maven生成或由VCS靜態跟蹤。 無論哪種方式，除非將存檔解壓縮和修改，否則此過程都會密封應用程序以進行進一步修改。

但是我無法想象這樣一種情況：打開JAR文件，修改文本文件，重新打包和重新部署（使用您專有的工具– asadmin，wlst等）。 為什么？ 考慮發布新版本的* authentic *存檔時會發生什么。 匯編程序/部署程序所做的更改將被覆蓋或需要重新配置。 因此，如果對版本控制的文件進行臨時更改，而這些更改再也沒有被VCS跟蹤，則可以說不是一個好主意。 即使他們這樣做了，我們也會失去靈活性。

值得一提的是，許多開放源代碼項目都使用數字簽名來簽署發布，以便安全意識強的用戶可以找到壓縮包的數字信任路徑。 如何在不破壞簽名的情況下更改此類存檔的配置？

考慮對開發的影響，其中每個開發人員可能都有一個單獨的數據庫表空間來進行集成測試。 一個聰明的開發人員可能會構建一些對配置文件敏感的Maven插件，以在部署描述符中搜索/替換其私有數據。 但是，為什么在每次更改配置值（例如在兩個JUnit測試之間）時，他都應該為此承擔負擔并遭受周轉打擊 （我不敢認為這些測試的樣子）？ 僅Xml文件本身無法驗證更改，我們需要一個程序來為我們完成更改。 等待1-2分鐘以便應用程序部署只會發現您的值無效，然后再做一遍，這對開發人員的生產力來說是災難。

如果我們進一步研究如何使用階段然后切換的方法來為集群系統部署軟件，則部署描述符將變得更加棘手，因為將需要兩個版本的相同檔案。 以及為什么由于停頓的價值需要改變而導致生產系統在停頓時受到干擾（ 升級 ）？ 考慮何時拒絕某個值-您是否將值改回（重新打包應用程序等）并在群集上回滾，更正值并重試？ 我不知道……但是我現在對在整個群集中維護SLA可靠性和配置一致性感到不安。

在多租戶的情況下，平面名稱=值類型的配置也受到限制。 層次結構或類似圖形的配置規范更適合建模承租人，以實現配置組合等。也許是這樣的：

import javax.validation.constraints.Max;
import javax.validation.constraints.Min;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;@Configuration
public class MysqlXADataSource {@Property(desc = "User name to use for connection authentication.")@Size(min = 6, max = 255)private String user = ""; // default value - hence optional property@Property(desc = "Password to use for connection authentication.")@Size(min = 6, max = 255)private String password = ""; // default value - hence optional property@Property(desc = "A JDBC URL.")@Pattern(regexp = "([a-zA-Z]{3,})://([\w-]+\.)+[\w-]+(/[\w- ./?%&=]*)?")private URL url; // required property@Property(desc = "Port number where a server is listening for requests.")@Min(0)@Max(65535)private Integer portNumber = 1521; // default value - hence optional property@Resourceprivate List<ConfigurableItem> items; // configuration childs
}@Stateless
public class SessionBean {@Resource(name = "jdbc/mysql-ds")private DataSource ds;
}

這將是應用程序視圖，并請注意，不假設在何處以及如何實例化配置，并且我們可以通過使用注釋處理器在編譯時強制類型安全來快速失敗。

這是我的自發反映，也許太過分了。 但是我仍然認為，大型應用程序和小型應用程序都將從運行時配置，未安裝軟件以及與配置源（文件，db，ldap，mib等）分離以及如何對其進行管理中受益。

我什至認為Java SE也將從Configuration Management中受益。

有關配置管理，還有很多其他方面需要討論，例如安全性，管理，通知，架構注冊/發現等。但是我將在這里停下來進行評論/反映/意見–部署描述符是管理配置的好方法還是我們需要更復雜的東西嗎？

這是與Java EE 7專家組郵件列表上的“ [jsr342-experts] Re：配置”和“ [[jsr342-experts] Re：資源配置””主題相關的帖子。 請隨時在此處或郵件列表中發表評論。

參考： Deep Hacks博客上的JCG合作伙伴 KristofferSj?gren的 Java EE配置管理 。

相關文章 ：

• 晴間多云
• 在云中開發和測試
• 故障隔離和恢復：向大規模和超大規模計算學習
• 使用Netbeans開發App Engine Java
• 每個程序員都應該知道的事情