來源：https://zhenbianshu.github.io
問題
之前的文章從Spring 的環境到 Spring Cloud 的配置中提到過，我們在使用 Spring Cloud 進行動態化配置，它的實作步驟是先將動態配置通過 @Value 注入到一個動態配置 Bean，并將這個 Bean 用注解標記為 @RefreshScope，在配置變更后，這些動態配置 Bean 會被統一銷毀，
之后 Spring Cloud 的 ContextRefresher 會將變更后的配置作為一個新的 Spring Environment 加載進 ApplicationContext，由于 Scoped Bean 都是 Lazy Init 的，它們會在下一次使用時被使用新的 Environment 重新創建，
這套動態配置加載流程在使我們服務更加靈活的同時，也帶來了很大的風險，首先從業務上，修改配置不像上線這么”重量級”，不必要找 QA 進行回歸測驗，這就有可能引發一系列奇怪的 Bug，而且長時間發現不了，另外，Spring Cloud 本身沒有 “fallback” 機制，一旦配置的資料型別出了問題，就會導致服務不可用，
為此，我給 Spring Cloud 提了個 issue，但作者認為變動太大，不好改也不必改，
其實我也明白這個問題的困境，每個人都得為自己要修改的配置負責，即使框架支持了 fallback，但將錯誤吞掉，配置修改后不生效也沒什么變化可能也并不符合用戶的期望，所以，盡量讓用戶要修改的配置正確成為了新的目標，
基于這種需求，我添加了一個動態配置的校驗器，但實作里一部分代碼來自 github，所以本文在總結思路的同時，也幫助我理解所有代碼，
整體思路
由于框架層沒法做太多事情，所以我的計劃是將這些配置取出來，構造出一個獨立的 Java 類，并在服務外新建一個 ApplicationContext 試圖通過構造出來的 Java 類初始化一個 Spring Bean，如果這個 Spring Bean 初始化程序中報錯了，說明配置是有問題的，
動態編譯
通過配置構造 Java 類
首先要通過 .properties 檔案構造出一個 Java 類，但問題是在配置里我們是不知道這些配置將要被怎么使用的，不知道它要被 Spring EL 如何處理，又將被轉成什么型別，
這里我采用的策略是給配置添加注釋，注釋里使用一定的格式宣告 EL 運算式和要生成的欄位型別，當然這種實作有點 low，有人提議把這些資訊放到配置項的 key 里，之后會再進行優化，
把各個欄位決議完成后放到準備到的類模板中，就生成了一個 Config.java 類字串，之后就要將這個字串編譯成位元組碼并由 Spring 加載成 Bean，
JavaCompiler
由于 Config.java 是在運行時生成的，所以編譯也只能在運行時了，萬幸 Java 有提供 javax.util.JavaCompiler 類進行 Java 類的動態編譯，省去了”寫入檔案 —— 命令列編譯 —— 類加載 —— 清理檔案” 的復雜流程，
JavaCompiler 的典型應用示例如下：
JavaCompiler javaCompiler = ToolProvider.getSystemJavaCompiler();
JavaFileManager fileManager = javaCompiler.getStandardFileManager(null, null, null);
CompilationTask task = javaCompiler.getTask(out, fileManager, diagnosticListener, options, classes, compilationUnits);
task.call();
FileObject outputFile = fileManager.getFileForOutput(null, null, null, null);
outputFile.getCharContent(true);
流程如下圖：JavaCompiler 通過 JavaFileManager 管理輸入和輸出檔案，使用時通過 getTask() 方法提交一個異步 CompilationTask 進行代碼編譯，代碼編譯時，JavaCompiler 通過 getCharContent() 從傳入的 compilationUnits 獲取到 .java 檔案內容，把編譯后的結果呼叫 CompiledByteCode 的 openOutputStream() 方法寫到 CompiledByteCode 物件里，
委托模式
由于 JavaCompiler 的默認實作都是通過檔案進行的，這不符合我的期望，我需要的是輸入和輸出都在記憶體進行，所以需要修改 JavaCompiler 的實作，JavaCompiler、JavaFileManager、JavaFileObject(Input/Output) 分別使用委托模式實作， 其中 JavaFileManager 已經有 ForwardingJavaFileManager 的實作，JavaFileObject 也有 SimpleJavaFileObject 的實作，我們繼承其實作后重寫部分方法即可，
我參考的原始碼：https://github.com/trung/InMemoryJavaCompiler
Spring Bean 實體化
要將 Config 類實體化成 Bean，我們可以在 xml 里預定義它，在編譯結束后創建一個簡易的 FileSystemXmlApplicationContext 實體化這個 xml 內的 Bean，
類加載器
首先要讓 Spring 能夠加載到這些編譯好的位元組碼，這就需要 ClassLoader 的配合，類加載器的默認實作不可能知道去加載我們記憶體里編譯好的位元組碼，只好新加一個 ClassLoader，實作也很簡單，繼承 ClassLoader 抽象類，并實作 findClass 方法即可，
class MemoryClassLoader extends ClassLoader {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 在 CompiledByteCode 類里將編譯后的位元組碼放到 classLoader 的 classBytes 欄位內，
byte[] buf = classBytes.get(name);
if (buf == null) {
return super.findClass(name);
}
return defineClass(name, buf, 0, buf.length);
}
}
配置和實作
由于 Config Bean 的初始化依賴動態配置，我們還要把這些配置也添加到 Spring 環境內，我們知道 Spring 環境配置是由多個 PropertySource 構成的，向里面添加一個實作即可，然后就可以呼叫 application 的 refresh() 方法初始化背景關系了，另外 Config Bean 被設定為懶加載了，不要忘記 get 一下使其被創建，
最終的代碼如下：
FileSystemXmlApplicationContext applicationContext = new FileSystemXmlApplicationContext();
applicationContext.setClassLoader(memoryClassLoader);
applicationContext.setConfigLocation("classpath*:/test.xml");
Map<String, Object> propertyMap = buildDynamicPropertyMap();
MapPropertySource mapPropertySource = new MapPropertySource("validate_source", propertyMap);
applicationContext.getEnvironment().getPropertySources().addFirst(mapPropertySource);
applicationContext.refresh();
applicationContext.getBean("config");
小結
小專案完成的程序中，復習了很多知識，也嘗試了業務代碼中幾乎不會用到的設計模式，充滿了挑戰性，
當然它現在還有配置不夠方便、錯誤提示不夠明確、沒解決配置 namespace 等問題，留到后面慢慢優化吧~
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288738.html
標籤：Java