microconfig.io ನೊಂದಿಗೆ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಿ

ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನಂತರದ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿನ ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳೆಂದರೆ ಅವುಗಳ ನಿದರ್ಶನಗಳ ಸಮರ್ಥ ಮತ್ತು ನಿಖರವಾದ ಸಂರಚನೆಯಾಗಿದೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಹೊಸ ಚೌಕಟ್ಟು ಇದಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ microconfig.io. ಕೆಲವು ವಾಡಿಕೆಯ ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಕಾರ್ಯಗಳನ್ನು ಸಾಕಷ್ಟು ಸೊಗಸಾಗಿ ಪರಿಹರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ನೀವು ಹಲವಾರು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್/ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಬಂದರೆ, ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ದೋಷವನ್ನು ಮಾಡುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯಿದೆ, ಸರಿಯಾದ ಕೌಶಲ್ಯ ಮತ್ತು ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ ಇಲ್ಲದೆ ಹಿಡಿಯಲು ತುಂಬಾ ಕಷ್ಟವಾಗುತ್ತದೆ. ಫ್ರೇಮ್‌ವರ್ಕ್ ಸ್ವತಃ ಹೊಂದಿಸುವ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ನಕಲಿ ನಿದರ್ಶನ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಇದರಿಂದಾಗಿ ದೋಷವನ್ನು ಸೇರಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ನೊಂದಿಗೆ ಸರಳವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ ಯಾಮ್ಲ್. ಇದು ಯಾವುದೇ ಭಾಷೆಯಲ್ಲಿ ಯಾವುದೇ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆಗಿರಬಹುದು. ಈ ಸೇವೆಗೆ ಚೌಕಟ್ಟನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಆದರೆ ಮೊದಲು, ಹೆಚ್ಚಿನ ಅನುಕೂಲಕ್ಕಾಗಿ, ಅದರಲ್ಲಿ microconfig.io ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ Idea IDE ನಲ್ಲಿ ಖಾಲಿ ಯೋಜನೆಯನ್ನು ರಚಿಸೋಣ:

ನಾವು ಪ್ಲಗಿನ್ ಲಾಂಚ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ, ಮೇಲಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿರುವಂತೆ ನೀವು ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸಬಹುದು.

ನಮ್ಮ ಸೇವೆಯನ್ನು ಆದೇಶ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ನಂತರ ಹೊಸ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಇದೇ ರೀತಿಯ ರಚನೆಯನ್ನು ರಚಿಸುತ್ತೇವೆ:

ಸೇವಾ ಹೆಸರಿನೊಂದಿಗೆ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಇರಿಸಿ - application.yaml. ಎಲ್ಲಾ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳನ್ನು ಕೆಲವು ರೀತಿಯ ಪರಿಸರದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ, ಸೇವೆಗಾಗಿ ಸಂರಚನೆಯನ್ನು ರಚಿಸುವುದರ ಜೊತೆಗೆ, ಪರಿಸರವನ್ನು ಸ್ವತಃ ವಿವರಿಸುವುದು ಅವಶ್ಯಕ: ಇದಕ್ಕಾಗಿ ನಾವು ಫೋಲ್ಡರ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ envs ಮತ್ತು ನಮ್ಮ ಕೆಲಸದ ಪರಿಸರದ ಹೆಸರಿನೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ಸೇರಿಸಿ. ಹೀಗಾಗಿ, ಫ್ರೇಮ್‌ವರ್ಕ್ ಪರಿಸರದಲ್ಲಿ ಸೇವೆಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ dev, ಈ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಪ್ಲಗಿನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಹೊಂದಿಸಿರುವುದರಿಂದ.

ಫೈಲ್ ರಚನೆ dev.yaml ಇದು ತುಂಬಾ ಸರಳವಾಗಿರುತ್ತದೆ:

mainorder:
    components:
         - order

ಫ್ರೇಮ್‌ವರ್ಕ್ ಒಟ್ಟಾಗಿ ಗುಂಪು ಮಾಡಲಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಮ್ಮ ಸೇವೆಗಾಗಿ, ಗುಂಪಿಗೆ ಹೆಸರನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮುಖ್ಯ ಕ್ರಮಾಂಕ. ಫ್ರೇಮ್‌ವರ್ಕ್ ಪರಿಸರ ಫೈಲ್‌ನಲ್ಲಿ ಅಂತಹ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಗುಂಪನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅವೆಲ್ಲಕ್ಕೂ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಅದು ಅನುಗುಣವಾದ ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿ ಕಂಡುಬರುತ್ತದೆ.

ಸೇವಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್‌ನಲ್ಲಿಯೇ ಆದೇಶ ಇದೀಗ ಒಂದು ನಿಯತಾಂಕವನ್ನು ಮಾತ್ರ ಸೂಚಿಸೋಣ:

spring.application.name: order

ಈಗ ನಾವು ಪ್ಲಗಿನ್ ಅನ್ನು ರನ್ ಮಾಡೋಣ, ಮತ್ತು ಇದು ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಾರ್ಗದ ಪ್ರಕಾರ ನಮ್ಮ ಸೇವೆಗೆ ಅಗತ್ಯವಿರುವ ಸಂರಚನೆಯನ್ನು ರಚಿಸುತ್ತದೆ:

ಮಾಡಬಹುದು ಜೊತೆಯಾಗು ಮತ್ತು ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸದೆಯೇ, ಫ್ರೇಮ್ವರ್ಕ್ ವಿತರಣೆಯನ್ನು ಸರಳವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಆಜ್ಞಾ ಸಾಲಿನಿಂದ ಚಲಾಯಿಸಿ.
ನಿರ್ಮಾಣ ಸರ್ವರ್‌ನಲ್ಲಿ ಬಳಸಲು ಈ ಪರಿಹಾರವು ಸೂಕ್ತವಾಗಿದೆ.

ಚೌಕಟ್ಟನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ ಆಸ್ತಿ ಸಿಂಟ್ಯಾಕ್ಸ್, ಅಂದರೆ, ಒಟ್ಟಿಗೆ ಬಳಸಬಹುದಾದ ಸಾಮಾನ್ಯ ಆಸ್ತಿ ಫೈಲ್‌ಗಳು ಯಾಮ್ಲ್ ಸಂರಚನೆಗಳು.

ಇನ್ನೊಂದು ಸೇವೆಯನ್ನು ಸೇರಿಸೋಣ ಪಾವತಿ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ.
В ಆದೇಶ:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В ಪಾವತಿ:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

ಈ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳೊಂದಿಗಿನ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಸೇವಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕಾಪಿ-ಪೇಸ್ಟ್‌ನ ಉಪಸ್ಥಿತಿಯಾಗಿದೆ. ಅದನ್ನು ತೊಡೆದುಹಾಕಲು ಚೌಕಟ್ಟು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಾರಂಭಿಸೋಣ - ಸಂರಚನೆಯ ಉಪಸ್ಥಿತಿ ಯುರೇಕಾ ಪ್ರತಿ ಸೂಕ್ಷ್ಮ ಸೇವೆಯ ವಿವರಣೆಯಲ್ಲಿ. ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್‌ನೊಂದಿಗೆ ಹೊಸ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸೋಣ ಮತ್ತು ಅದಕ್ಕೆ ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸೇರಿಸೋಣ:

ಮತ್ತು ಈಗ ನಮ್ಮ ಪ್ರತಿಯೊಂದು ಯೋಜನೆಗಳಿಗೆ ಸಾಲನ್ನು ಸೇರಿಸೋಣ #ಯುರೇಕಾವನ್ನು ಸೇರಿಸಿ.

ಫ್ರೇಮ್‌ವರ್ಕ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಯುರೇಕಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸೇವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಿಗೆ ನಕಲಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತ್ಯೇಕ ಯುರೇಕಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ಪರಿಸರ ಫೈಲ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದಿಲ್ಲ dev.yaml. ಸೇವೆ ಆದೇಶ:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

ಆಮದು ಸಾಲನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನಾವು ಡೇಟಾಬೇಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಸರಿಸಬಹುದು #ಯುರೇಕಾ, ಒರಾಕಲ್ ಸೇರಿದಂತೆ.

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸುವಾಗ ಫ್ರೇಮ್‌ವರ್ಕ್ ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮುಖ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿ ವಿಶೇಷ ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತದೆ ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. ಅದರ ಲಾಗ್‌ನಲ್ಲಿನ ನಮೂದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: “1 ಆಸ್ತಿ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ order/diff-application.yaml" ದೊಡ್ಡ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಸಾಮಾನ್ಯ ಭಾಗಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರಿಂದ ಅನಗತ್ಯವಾದ ಕಾಪಿ-ಪೇಸ್ಟ್‌ಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಸಂರಚನೆಯನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ - ನಮ್ಮ ಸೇವೆಗಳ ಅಂತಿಮ ಬಿಂದುಗಳು ಅನನ್ಯ ಮತ್ತು ಹಾರ್ಡ್-ಕೋಡೆಡ್ ಆಗಿರುತ್ತವೆ, ಇದು ಕೆಟ್ಟದು. ಇದನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸೋಣ.

ಎಲ್ಲಾ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಇತರರು ಉಲ್ಲೇಖಿಸಬಹುದಾದ ಒಂದು ಸಂರಚನೆಯಲ್ಲಿ ಇಡುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ಚೌಕಟ್ಟಿನಲ್ಲಿ ಪರಿಚಯಿಸಲಾಗಿದೆ. ಈ ರೀತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಬದಲಾಗುತ್ತದೆ ಯುರೇಕಾ:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

ಈಗ ಈ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಸಿಸ್ಟಮ್ ಹೆಸರಿನ ಘಟಕವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಅಂತಿಮ ಬಿಂದುಗಳು ಮತ್ತು ಅದರಲ್ಲಿ ಅರ್ಥವನ್ನು ಹುಡುಕುತ್ತದೆ ಯುರೇಕೈಪ್, ತದನಂತರ ಅದನ್ನು ನಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಬದಲಿಸುತ್ತದೆ. ಆದರೆ ವಿಭಿನ್ನ ಪರಿಸರಗಳ ಬಗ್ಗೆ ಏನು? ಇದನ್ನು ಮಾಡಲು, ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ ಅಂತಿಮ ಬಿಂದುಗಳು ಕೆಳಗಿನ ಪ್ರಕಾರ application.dev.yaml. ಫ್ರೇಮ್‌ವರ್ಕ್ ಸ್ವತಂತ್ರವಾಗಿ, ಫೈಲ್ ವಿಸ್ತರಣೆಯ ಆಧಾರದ ಮೇಲೆ, ಈ ಸಂರಚನೆಯು ಯಾವ ಪರಿಸರಕ್ಕೆ ಸೇರಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ:

ದೇವ್ ಫೈಲ್ ವಿಷಯಗಳು:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

ನಮ್ಮ ಸೇವೆಗಳ ಪೋರ್ಟ್‌ಗಳಿಗಾಗಿ ನಾವು ಅದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸಬಹುದು:

server.port: ${ports@order}.

ಎಲ್ಲಾ ಪ್ರಮುಖ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿವೆ, ಇದರಿಂದಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿನ ಚದುರಿದ ನಿಯತಾಂಕಗಳಿಂದ ದೋಷಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನೇಕ ರೆಡಿಮೇಡ್ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಇರುವ ಡೈರೆಕ್ಟರಿಯ ಹೆಸರನ್ನು ನೀವು ಪಡೆಯಬಹುದು ಮತ್ತು ಅದನ್ನು ನಿಯೋಜಿಸಬಹುದು:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರನ್ನು ಹೆಚ್ಚುವರಿಯಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಇದನ್ನು ಸಾಮಾನ್ಯ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿಯೂ ಇರಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಅದೇ ಯುರೇಕಾದಲ್ಲಿ:

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಆದೇಶ ಒಂದು ಸಾಲಿಗೆ ಇಳಿಸಲಾಗುವುದು:

#include eureka, oracle
server.port: ${ports@order}

ಪೋಷಕ ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದ ನಮಗೆ ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಅದನ್ನು ನಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಪೀಳಿಗೆಯ ಸಮಯದಲ್ಲಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಮಗೆ ಆರ್ಡರ್ ಸೇವೆಗಾಗಿ ಅನನ್ಯ ಹೆಸರು ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಬಿಡುತ್ತೇವೆ ವಸಂತ.ಅಪ್ಲಿಕೇಶನ್.ಹೆಸರು.

ನೀವು ಸೇವೆಗೆ ಕಸ್ಟಮ್ ಲಾಗಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸೇರಿಸಬೇಕು ಎಂದು ಹೇಳೋಣ, ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, logback.xml. ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಗುಂಪಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ರಚಿಸೋಣ:

ಮೂಲ ಸಂರಚನೆಯಲ್ಲಿ, ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಬಳಸಿ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಲಾಗಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್ ಅನ್ನು ಎಲ್ಲಿ ಇರಿಸಬೇಕೆಂದು ನಾವು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ಹೇಳುತ್ತೇವೆ @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

ಕಡತದಲ್ಲಿ logback.xml ನಾವು ಪ್ರಮಾಣಿತ ಅನುಬಂಧಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ, ಇದು ಕಾನ್ಫಿಗ್‌ಗಳ ಉತ್ಪಾದನೆಯ ಸಮಯದಲ್ಲಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಬದಲಾಗುವ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ:

<file>logs/${this@name}.log</file>

ಸೇವಾ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗೆ ಆಮದು ಸೇರಿಸುವ ಮೂಲಕ ಲಾಗ್ಬ್ಯಾಕ್, ಪ್ರತಿ ಸೇವೆಗೆ ನಾವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಲಾಗಿಂಗ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ:

#include eureka, oracle, logback
server.port: ${ports@order}

ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳುವ ಸಮಯ ಇದು:

${this@env} - ಪ್ರಸ್ತುತ ಪರಿಸರದ ಹೆಸರನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.
${…@ಹೆಸರು} - ಘಟಕದ ಹೆಸರನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.
${…@configDir} — ಘಟಕದ ಸಂರಚನಾ ಡೈರೆಕ್ಟರಿಗೆ ಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
${…@resultDir} — ಕಾಂಪೊನೆಂಟ್‌ನ ಗಮ್ಯಸ್ಥಾನ ಡೈರೆಕ್ಟರಿಗೆ ಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ (ಫಲಿತಾಂಶವಾದ ಫೈಲ್‌ಗಳನ್ನು ಈ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ).
${this@configRoot} - ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ಟೋರ್‌ನ ಮೂಲ ಡೈರೆಕ್ಟರಿಗೆ ಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಪಡೆಯಲು ಸಿಸ್ಟಮ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಜಾವಾಗೆ ಮಾರ್ಗ:
${env@JAVA_HOME}
ಒಂದೋ, ಚೌಕಟ್ಟನ್ನು ಬರೆಯಲಾಗಿರುವುದರಿಂದ ಜಾವಾ, ನಾವು ಕರೆಯಂತೆಯೇ ಸಿಸ್ಟಮ್ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಪಡೆಯಬಹುದು ವ್ಯವಸ್ಥೆ::getProperty ಈ ರೀತಿಯ ರಚನೆಯನ್ನು ಬಳಸುವುದು:
${[ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]}
ವಿಸ್ತರಣೆ ಭಾಷೆಗೆ ಬೆಂಬಲವನ್ನು ನಮೂದಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ವಸಂತ EL. ಕೆಳಗಿನ ಅಭಿವ್ಯಕ್ತಿಗಳು ಸಂರಚನೆಯಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತವೆ:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

ಮತ್ತು ನೀವು ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ಸ್ಥಳೀಯ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

ಹೀಗಾಗಿ, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಸೂಕ್ಷ್ಮ-ಶ್ರುತಿ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಸಂರಚನೆಗೆ ಚೌಕಟ್ಟು ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದೆ. ಫ್ರೇಮ್‌ವರ್ಕ್ ಅದರ ಮುಖ್ಯ ಕಾರ್ಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರೈಸುತ್ತದೆ - ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ನಕಲು-ಪೇಸ್ಟ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು, ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಕ್ರೋಢೀಕರಿಸುವುದು ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಸಂಭವನೀಯ ದೋಷಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಸಂರಚನೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಸಂಯೋಜಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಈ ಚೌಕಟ್ಟಿನಲ್ಲಿ ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಅದರ ಅಧಿಕೃತ ಪುಟವನ್ನು ಭೇಟಿ ಮಾಡಲು ಮತ್ತು ಪೂರ್ಣವಾಗಿ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ದಸ್ತಾವೇಜನ್ನು, ಅಥವಾ ಮೂಲಗಳನ್ನು ಅಗೆಯಿರಿ ಇಲ್ಲಿ.

ಮೂಲ: www.habr.com