ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ಕಂಪೈಬಲ್ ಕಾನ್ಫಿಗರೇಶನ್

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ.
ಸಂರಚನೆಯನ್ನು ನೇರವಾಗಿ ಸ್ಕಾಲಾ ಭಾಷೆಯಲ್ಲಿ ಒಂದು ರೀತಿಯ ಸುರಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆ ಅನುಷ್ಠಾನವನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಒಟ್ಟಾರೆ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಸೇರಿದಂತೆ ಪ್ರಸ್ತಾವನೆಯ ವಿವಿಧ ಅಂಶಗಳನ್ನು ಚರ್ಚಿಸಲಾಗಿದೆ.

(ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ)

ಪರಿಚಯ

ದೃಢವಾದ ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಸರಿಯಾದ ಮತ್ತು ಸುಸಂಬದ್ಧವಾದ ಸಂರಚನೆಯ ಬಳಕೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಒಂದು ವಿಶಿಷ್ಟ ಪರಿಹಾರವೆಂದರೆ ಪಠ್ಯದ ನಿಯೋಜನೆ ವಿವರಣೆ (ಟೆರಾಫಾರ್ಮ್, ಅನ್ಸಿಬಲ್ ಅಥವಾ ಅದೇ ರೀತಿಯ) ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸುವುದು (ಸಾಮಾನ್ಯವಾಗಿ - ಪ್ರತಿ ನೋಡ್/ಪಾತ್ರಕ್ಕೆ ಮೀಸಲಾಗಿರುತ್ತದೆ). ಪ್ರತಿ ಸಂವಹನ ನೋಡ್‌ಗಳಲ್ಲಿ ಅದೇ ಆವೃತ್ತಿಗಳ ಅದೇ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ (ಇಲ್ಲದಿದ್ದರೆ ನಾವು ಅಸಾಮರಸ್ಯದ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸುತ್ತೇವೆ). JVM ಜಗತ್ತಿನಲ್ಲಿ ಇದರರ್ಥ ಕನಿಷ್ಠ ಸಂದೇಶ ಕಳುಹಿಸುವ ಲೈಬ್ರರಿಯು ಎಲ್ಲಾ ಸಂವಹನ ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಆವೃತ್ತಿಯಾಗಿರಬೇಕು.

ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಬಗ್ಗೆ ಏನು? ಸಹಜವಾಗಿ, ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳಿಗೆ ಬರುವ ಮೊದಲು ನಾವು ಎಲ್ಲಾ ಘಟಕಗಳಿಗೆ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಎಕ್ಸ್‌ಟ್ರಾಪೋಲೇಟ್ ಮಾಡಲು, ಎಲ್ಲಾ ಲೈಬ್ರರಿಗಳ ಆವೃತ್ತಿಗಳನ್ನು ರನ್‌ಟೈಮ್ ಮತ್ತು ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಒಂದೇ ರೀತಿ ಇರಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.

ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಾಗ, ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಕ್ಲಾಸ್‌ಪಾತ್ ಹೊಂದಲು ಇದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ನಿಯೋಜನೆಯಲ್ಲಿ ಅದೇ ಕ್ಲಾಸ್‌ಪಾತ್ ಅನ್ನು ಬಳಸಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. (ವಿಭಿನ್ನ ನೋಡ್‌ಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಕ್ಲಾಸ್‌ಪಾತ್‌ಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿದೆ, ಆದರೆ ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಸರಿಯಾಗಿ ನಿಯೋಜಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟ.) ಆದ್ದರಿಂದ ವಿಷಯಗಳನ್ನು ಸರಳವಾಗಿಡಲು ನಾವು ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಕ್ಲಾಸ್‌ಪಾತ್‌ಗಳನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸುತ್ತೇವೆ.

ಸಂರಚನೆಯು ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ವಿಕಸನಗೊಳ್ಳುತ್ತದೆ. ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ವಿವಿಧ ಗುರುತಿಸಲು ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ
ಸಾಫ್ಟ್ವೇರ್ ವಿಕಾಸದ ಹಂತಗಳು. ಆವೃತ್ತಿ ನಿರ್ವಹಣೆಯ ಅಡಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಒಳಗೊಳ್ಳಲು ಮತ್ತು ಕೆಲವು ಲೇಬಲ್‌ಗಳೊಂದಿಗೆ ವಿಭಿನ್ನ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಇದು ಸಮಂಜಸವೆಂದು ತೋರುತ್ತದೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೇವಲ ಒಂದು ಕಾನ್ಫಿಗರೇಶನ್ ಇದ್ದರೆ, ನಾವು ಒಂದೇ ಆವೃತ್ತಿಯನ್ನು ಗುರುತಿಸುವಿಕೆಯಾಗಿ ಬಳಸಬಹುದು. ಕೆಲವೊಮ್ಮೆ ನಾವು ಬಹು ಉತ್ಪಾದನಾ ಪರಿಸರವನ್ನು ಹೊಂದಿರಬಹುದು. ಮತ್ತು ಪ್ರತಿಯೊಂದು ಪರಿಸರಕ್ಕೂ ನಮಗೆ ಸಂರಚನೆಯ ಪ್ರತ್ಯೇಕ ಶಾಖೆ ಬೇಕಾಗಬಹುದು. ಆದ್ದರಿಂದ ವಿಭಿನ್ನ ಸಂರಚನೆಗಳನ್ನು ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಲು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಶಾಖೆ ಮತ್ತು ಆವೃತ್ತಿಯೊಂದಿಗೆ ಲೇಬಲ್ ಮಾಡಬಹುದು. ಪ್ರತಿಯೊಂದು ಶಾಖೆಯ ಲೇಬಲ್ ಮತ್ತು ಆವೃತ್ತಿಯು ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ವಿತರಿಸಲಾದ ನೋಡ್‌ಗಳು, ಪೋರ್ಟ್‌ಗಳು, ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲಗಳು, ಕ್ಲಾಸ್‌ಪಾತ್ ಲೈಬ್ರರಿ ಆವೃತ್ತಿಗಳ ಏಕ ಸಂಯೋಜನೆಗೆ ಅನುರೂಪವಾಗಿದೆ. ಇಲ್ಲಿ ನಾವು ಒಂದೇ ಶಾಖೆಯನ್ನು ಮಾತ್ರ ಕವರ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಇತರ ಕಲಾಕೃತಿಗಳಂತೆಯೇ ಮೂರು ಘಟಕಗಳ ದಶಮಾಂಶ ಆವೃತ್ತಿ (1.2.3) ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತೇವೆ.

ಆಧುನಿಕ ಪರಿಸರದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಇನ್ನು ಮುಂದೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಉತ್ಪಾದಿಸುತ್ತೇವೆ
ನಿಯೋಜನೆ ಸಮಯದಲ್ಲಿ ಫೈಲ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು ಅವರನ್ನು ಮುಟ್ಟಲೇ ಇಲ್ಲ ನಂತರ. ಹಾಗಾದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಿಗಾಗಿ ನಾವು ಇನ್ನೂ ಪಠ್ಯ ಸ್ವರೂಪವನ್ನು ಏಕೆ ಬಳಸುತ್ತೇವೆ ಎಂದು ಒಬ್ಬರು ಕೇಳಬಹುದು? ಒಂದು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಆಯ್ಕೆಯು ಸಂಕಲನ ಘಟಕದೊಳಗೆ ಸಂರಚನೆಯನ್ನು ಇರಿಸುವುದು ಮತ್ತು ಕಂಪೈಲ್-ಟೈಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮೌಲ್ಯೀಕರಣದಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುವುದು.

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಸಂಕಲಿಸಿದ ಕಲಾಕೃತಿಯಲ್ಲಿ ಸಂರಚನೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ ಕಲ್ಪನೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಸಂಕಲಿಸಬಹುದಾದ ಸಂರಚನೆ

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

ವಿಶಿಷ್ಟವಾದ ವಿತರಣೆ ವ್ಯವಸ್ಥೆಯು ಕೆಲವು ನೋಡ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಕೆಲವು ಪ್ರಕಾರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೋಡ್ಗಳನ್ನು ಗುರುತಿಸಬಹುದು:

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

ಅಥವಾ ಕೇವಲ

case class NodeId(hostName: String)

ಅಥವಾ

object Singleton
type NodeId = Singleton.type

ಈ ನೋಡ್‌ಗಳು ವಿವಿಧ ಪಾತ್ರಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಕೆಲವು ಸೇವೆಗಳನ್ನು ಚಲಾಯಿಸುತ್ತವೆ ಮತ್ತು TCP/HTTP ಸಂಪರ್ಕಗಳ ಮೂಲಕ ಇತರ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

TCP ಸಂಪರ್ಕಕ್ಕಾಗಿ ಕನಿಷ್ಠ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯ ಅಗತ್ಯವಿದೆ. ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮಾತನಾಡುತ್ತಿದ್ದಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ನೋಡ್‌ಗಳ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ರೂಪಿಸಲು ಕೆಳಗಿನ ವರ್ಗವನ್ನು ಘೋಷಿಸೋಣ:

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

ಅಲ್ಲಿ Port ಕೇವಲ ಒಂದು Int ಅನುಮತಿಸಲಾದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

ಸಂಸ್ಕರಿಸಿದ ವಿಧಗಳು

ನೋಡಿ ಸಂಸ್ಕರಿಸಿದ ಗ್ರಂಥಾಲಯ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಇತರ ಪ್ರಕಾರಗಳಿಗೆ ಕಂಪೈಲ್ ಸಮಯದ ನಿರ್ಬಂಧಗಳನ್ನು ಸೇರಿಸಲು ಇದು ಅನುಮತಿಸುತ್ತದೆ. ಈ ವಿಷಯದಲ್ಲಿ Int ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುವ 16-ಬಿಟ್ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಲು ಮಾತ್ರ ಅನುಮತಿಸಲಾಗಿದೆ. ಈ ಕಾನ್ಫಿಗರೇಶನ್ ವಿಧಾನಕ್ಕಾಗಿ ಈ ಗ್ರಂಥಾಲಯವನ್ನು ಬಳಸುವ ಅವಶ್ಯಕತೆಯಿಲ್ಲ. ಇದು ತುಂಬಾ ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ.

HTTP (REST) ​​ಗಾಗಿ ನಮಗೆ ಸೇವೆಯ ಮಾರ್ಗವೂ ಬೇಕಾಗಬಹುದು:

type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]]
case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix)

ಫ್ಯಾಂಟಮ್ ಪ್ರಕಾರ

ಸಂಕಲನದ ಸಮಯದಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಗುರುತಿಸಲು ನಾವು ಟೈಪ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಘೋಷಿಸುವ ಸ್ಕಾಲಾ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ Protocol ಅದನ್ನು ತರಗತಿಯಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಇದು ಒಂದು so called ಫ್ಯಾಂಟಮ್ ಪ್ರಕಾರ. ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ನಮಗೆ ಪ್ರೋಟೋಕಾಲ್ ಐಡೆಂಟಿಫೈಯರ್‌ನ ನಿದರ್ಶನ ವಿರಳವಾಗಿ ಬೇಕಾಗುತ್ತದೆ, ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ಸಂಕಲನದ ಸಮಯದಲ್ಲಿ ಈ ಫ್ಯಾಂಟಮ್ ಪ್ರಕಾರವು ಹೆಚ್ಚುವರಿ ರೀತಿಯ ಸುರಕ್ಷತೆಯನ್ನು ನೀಡುತ್ತದೆ. ತಪ್ಪಾದ ಪ್ರೋಟೋಕಾಲ್ನೊಂದಿಗೆ ನಾವು ಪೋರ್ಟ್ ಅನ್ನು ರವಾನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

Json ಧಾರಾವಾಹಿಯೊಂದಿಗೆ REST API ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

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

ಈ ಪೋಸ್ಟ್‌ನ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಪ್ರೋಟೋಕಾಲ್‌ನ ಸರಳ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತೇವೆ:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ಈ ಪ್ರೋಟೋಕಾಲ್ ವಿನಂತಿಯಲ್ಲಿ ಸಂದೇಶವನ್ನು url ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಂದೇಶವನ್ನು ಸರಳ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.

ಸೇವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸೇವೆಯ ಹೆಸರು, ಪೋರ್ಟ್‌ಗಳ ಸಂಗ್ರಹ ಮತ್ತು ಕೆಲವು ಅವಲಂಬನೆಗಳಿಂದ ವಿವರಿಸಬಹುದು. ಸ್ಕಾಲಾದಲ್ಲಿ ಈ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಹೇಗೆ ಪ್ರತಿನಿಧಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಸಂಭಾವ್ಯ ಮಾರ್ಗಗಳಿವೆ (ಉದಾಹರಣೆಗೆ, HList, ಬೀಜಗಣಿತದ ಡೇಟಾ ಪ್ರಕಾರಗಳು). ಈ ಪೋಸ್ಟ್‌ನ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಸಂಯೋಜಿಸಬಹುದಾದ ತುಣುಕುಗಳನ್ನು (ಮಾಡ್ಯೂಲ್‌ಗಳು) ಗುಣಲಕ್ಷಣಗಳಾಗಿ ಪ್ರತಿನಿಧಿಸುತ್ತೇವೆ. (ಈ ಕಂಪೈಬಲ್ ಕಾನ್ಫಿಗರೇಶನ್ ವಿಧಾನಕ್ಕೆ ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಕಲ್ಪನೆಯ ಒಂದು ಸಂಭವನೀಯ ಅನುಷ್ಠಾನವಾಗಿದೆ.)

ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಇತರ ನೋಡ್‌ಗಳ ಅಂತಿಮ ಬಿಂದುಗಳಾಗಿ ಬಳಸಿಕೊಂಡು ಅವಲಂಬನೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು:

  type EchoProtocol[A] = SimpleHttpGetRest[A, A]

  trait EchoConfig[A] extends ServiceConfig {
    def portNumber: PortNumber = 8081
    def echoPort: PortWithPrefix[EchoProtocol[A]] = PortWithPrefix[EchoProtocol[A]](portNumber, "echo")
    def echoService: HttpSimpleGetEndPoint[NodeId, EchoProtocol[A]] = providedSimpleService(echoPort)
  }

ಎಕೋ ಸೇವೆಗೆ ಪೋರ್ಟ್ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ. ಮತ್ತು ಈ ಪೋರ್ಟ್ ಎಕೋ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ನಾವು ಘೋಷಿಸುತ್ತೇವೆ. ಈ ಕ್ಷಣದಲ್ಲಿ ನಾವು ನಿರ್ದಿಷ್ಟ ಪೋರ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಲಕ್ಷಣವು ಅಮೂರ್ತ ವಿಧಾನಗಳ ಘೋಷಣೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಅಮೂರ್ತ ವಿಧಾನಗಳನ್ನು ಬಳಸಿದರೆ, ಕಂಪೈಲರ್‌ಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ನಿದರ್ಶನದಲ್ಲಿ ಅನುಷ್ಠಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇಲ್ಲಿ ನಾವು ಅನುಷ್ಠಾನವನ್ನು ಒದಗಿಸಿದ್ದೇವೆ (8081) ಮತ್ತು ನಾವು ಅದನ್ನು ಕಾಂಕ್ರೀಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಬಿಟ್ಟುಬಿಟ್ಟರೆ ಅದನ್ನು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿಧ್ವನಿ ಸೇವಾ ಕ್ಲೈಂಟ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಾವು ಅವಲಂಬನೆಯನ್ನು ಘೋಷಿಸಬಹುದು:

  trait EchoClientConfig[A] {
    def testMessage: String = "test"
    def pollInterval: FiniteDuration
    def echoServiceDependency: HttpSimpleGetEndPoint[_, EchoProtocol[A]]
  }

ಅವಲಂಬನೆಯು ಅದೇ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿದೆ echoService. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಅದೇ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೇಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಈ ಎರಡು ಅವಲಂಬನೆಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ ಅವು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂದು ನಾವು ಖಚಿತವಾಗಿ ಹೇಳಬಹುದು.

ಸೇವೆಗಳ ಅನುಷ್ಠಾನ

ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ಆಕರ್ಷಕವಾಗಿ ಸ್ಥಗಿತಗೊಳಿಸಲು ಒಂದು ಕಾರ್ಯದ ಅಗತ್ಯವಿದೆ. (ಸೇವೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವು ಪರೀಕ್ಷೆಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ.) ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆಗಾಗಿ ಅಂತಹ ಕಾರ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಕೆಲವು ಆಯ್ಕೆಗಳಿವೆ (ಉದಾಹರಣೆಗೆ, ನಾವು ಟೈಪ್ ಕ್ಲಾಸ್‌ಗಳನ್ನು ಬಳಸಬಹುದು). ಈ ಪೋಸ್ಟ್‌ಗಾಗಿ ನಾವು ಮತ್ತೆ ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಬಳಸಿಕೊಂಡು ಸೇವೆಯನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು cats.Resource ಇದು ಈಗಾಗಲೇ ಬ್ರಾಕೆಟಿಂಗ್ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಬಿಡುಗಡೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಂಪನ್ಮೂಲವನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಕೆಲವು ರನ್ಟೈಮ್ ಸಂದರ್ಭವನ್ನು ಒದಗಿಸಬೇಕು. ಆದ್ದರಿಂದ ಸೇವೆಯ ಪ್ರಾರಂಭದ ಕಾರ್ಯವು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

ಅಲ್ಲಿ

• Config - ಈ ಸೇವಾ ಸ್ಟಾರ್ಟರ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಕಾರ
• AddressResolver - ಇತರ ನೋಡ್‌ಗಳ ನೈಜ ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ರನ್‌ಟೈಮ್ ಆಬ್ಜೆಕ್ಟ್ (ವಿವರಗಳಿಗಾಗಿ ಓದುವುದನ್ನು ಮುಂದುವರಿಸಿ).

ಇತರ ಪ್ರಕಾರಗಳು ಬರುತ್ತವೆ cats:

• F[_] - ಪರಿಣಾಮದ ಪ್ರಕಾರ (ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ F[A] ಕೇವಲ ಆಗಿರಬಹುದು () => A. ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಬಳಸುತ್ತೇವೆ cats.IO.)
• Reader[A,B] - ಒಂದು ಕಾರ್ಯಕ್ಕೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸಮಾನಾರ್ಥಕವಾಗಿದೆ A => B
• cats.Resource - ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡಲು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದೆ
• Timer - ನಿದ್ರೆ / ಸಮಯವನ್ನು ಅಳೆಯಲು ಅನುಮತಿಸುತ್ತದೆ
• ContextShift - ಅನಲಾಗ್ ExecutionContext
• Applicative - ಪರಿಣಾಮದಲ್ಲಿರುವ ಕಾರ್ಯಗಳ ಹೊದಿಕೆ (ಬಹುತೇಕ ಮೊನಾಡ್) (ನಾವು ಅಂತಿಮವಾಗಿ ಅದನ್ನು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಬದಲಾಯಿಸಬಹುದು)

ಈ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಕೆಲವು ಸೇವೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಏನನ್ನೂ ಮಾಡದ ಸೇವೆ:

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config <: Any
    def resource(...): ResourceReader[F, Config, Unit] =
      Reader(_ => Resource.pure[F, Unit](()))
  }

(ನೋಡಿ ಮೂಲ ಕೋಡ್ ಇತರ ಸೇವೆಗಳ ಅನುಷ್ಠಾನಗಳಿಗಾಗಿ - ಪ್ರತಿಧ್ವನಿ ಸೇವೆ,
ಪ್ರತಿಧ್ವನಿ ಕ್ಲೈಂಟ್ ಮತ್ತು ಜೀವಿತಾವಧಿ ನಿಯಂತ್ರಕರು.)

ನೋಡ್ ಎನ್ನುವುದು ಕೆಲವು ಸೇವೆಗಳನ್ನು ನಡೆಸುವ ಏಕೈಕ ವಸ್ತುವಾಗಿದೆ (ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಮೂಲಕ ಸಂಪನ್ಮೂಲಗಳ ಸರಪಳಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು):

object SingleNodeImpl extends ZeroServiceImpl[IO]
  with EchoServiceService
  with EchoClientService
  with FiniteDurationLifecycleServiceImpl
{
  type Config = EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig
}

ನೋಡ್‌ನಲ್ಲಿ ಈ ನೋಡ್‌ಗೆ ಅಗತ್ಯವಿರುವ ನಿಖರವಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಕಂಪೈಲರ್ ನಮಗೆ ವಸ್ತುವನ್ನು (ಕೇಕ್) ಸಾಕಷ್ಟಿಲ್ಲದ ಪ್ರಕಾರ ನಿರ್ಮಿಸಲು ಬಿಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ಸೇವಾ ಲಕ್ಷಣವು ನಿರ್ಬಂಧವನ್ನು ಘೋಷಿಸುತ್ತದೆ Config ಮಾದರಿ. ಸಂಪೂರ್ಣ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಒದಗಿಸದೆ ನಾವು ನೋಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ನೋಡ್ ವಿಳಾಸ ರೆಸಲ್ಯೂಶನ್

ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ನಮಗೆ ಪ್ರತಿ ನೋಡ್‌ಗೆ ನಿಜವಾದ ಹೋಸ್ಟ್ ವಿಳಾಸದ ಅಗತ್ಯವಿದೆ. ಇದು ಸಂರಚನೆಯ ಇತರ ಭಾಗಗಳಿಗಿಂತ ನಂತರ ತಿಳಿಯಬಹುದು. ಆದ್ದರಿಂದ, ನೋಡ್ ಐಡಿ ಮತ್ತು ಅದರ ನಿಜವಾದ ವಿಳಾಸದ ನಡುವೆ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಪೂರೈಸಲು ನಮಗೆ ಒಂದು ಮಾರ್ಗ ಬೇಕು. ಈ ಮ್ಯಾಪಿಂಗ್ ಒಂದು ಕಾರ್ಯವಾಗಿದೆ:

case class NodeAddress[NodeId](host: Uri.Host)
trait AddressResolver[F[_]] {
  def resolve[NodeId](nodeId: NodeId): F[NodeAddress[NodeId]]
}

ಅಂತಹ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೆಲವು ಸಂಭಾವ್ಯ ಮಾರ್ಗಗಳಿವೆ.

1. ನಿಯೋಜನೆಯ ಮೊದಲು ನಮಗೆ ನಿಜವಾದ ವಿಳಾಸಗಳು ತಿಳಿದಿದ್ದರೆ, ನೋಡ್ ಹೋಸ್ಟ್‌ಗಳ ತತ್‌ಕ್ಷಣದ ಸಮಯದಲ್ಲಿ, ನಾವು ನಿಜವಾದ ವಿಳಾಸಗಳೊಂದಿಗೆ ಸ್ಕಾಲಾ ಕೋಡ್ ಅನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ನಂತರ ಬಿಲ್ಡ್ ಅನ್ನು ರನ್ ಮಾಡಬಹುದು (ಇದು ಕಂಪೈಲ್ ಸಮಯ ಪರಿಶೀಲನೆಗಳನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಏಕೀಕರಣ ಪರೀಕ್ಷಾ ಸೂಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಮ್ಮ ಮ್ಯಾಪಿಂಗ್ ಕಾರ್ಯವನ್ನು ಸ್ಥಿರವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸರಳಗೊಳಿಸಬಹುದು a Map[NodeId, NodeAddress].
2. ಕೆಲವೊಮ್ಮೆ ನಾವು ನೋಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ನಂತರದ ಹಂತದಲ್ಲಿ ಮಾತ್ರ ನಿಜವಾದ ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ ಅಥವಾ ಇನ್ನೂ ಪ್ರಾರಂಭಿಸದ ನೋಡ್‌ಗಳ ವಿಳಾಸಗಳನ್ನು ನಾವು ಹೊಂದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಅನ್ವೇಷಣೆ ಸೇವೆಯನ್ನು ಹೊಂದಿರಬಹುದು ಅದು ಎಲ್ಲಾ ಇತರ ನೋಡ್‌ಗಳ ಮೊದಲು ಪ್ರಾರಂಭವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ನೋಡ್ ಆ ಸೇವೆಯಲ್ಲಿ ಅದರ ವಿಳಾಸವನ್ನು ಜಾಹೀರಾತು ಮಾಡಬಹುದು ಮತ್ತು ಅವಲಂಬನೆಗಳಿಗೆ ಚಂದಾದಾರರಾಗಬಹುದು.
3. ನಾವು ಮಾರ್ಪಡಿಸಬಹುದಾದರೆ /etc/hosts, ನಾವು ಪೂರ್ವನಿರ್ಧರಿತ ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಬಳಸಬಹುದು (ಹಾಗೆ my-project-main-node ಮತ್ತು echo-backend) ಮತ್ತು ನಿಯೋಜನೆ ಸಮಯದಲ್ಲಿ ಈ ಹೆಸರನ್ನು IP ವಿಳಾಸದೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ.

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಈ ಪ್ರಕರಣಗಳನ್ನು ಹೆಚ್ಚಿನ ವಿವರಗಳಲ್ಲಿ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ ನಮ್ಮ ಆಟಿಕೆ ಉದಾಹರಣೆಯಲ್ಲಿ ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಒಂದೇ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರುತ್ತವೆ - 127.0.0.1.

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಎರಡು ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್ ಲೇಔಟ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ:

1. ಏಕ ನೋಡ್ ಲೇಔಟ್, ಅಲ್ಲಿ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.
2. ಎರಡು ನೋಡ್ ಲೇಔಟ್, ಅಲ್ಲಿ ಸೇವೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ವಿಭಿನ್ನ ನೋಡ್‌ಗಳಲ್ಲಿದೆ.

a ಗಾಗಿ ಸಂರಚನೆ ಒಂದೇ ನೋಡ್ ಲೇಔಟ್ ಈ ಕೆಳಗಿನಂತಿದೆ:

ಏಕ ನೋಡ್ ಕಾನ್ಫಿಗರೇಶನ್

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton // identifier of the single node 
  // configuration of server
  type NodeId = Singleton.type
  def nodeId = Singleton

  /** Type safe service port specification. */
  override def portNumber: PortNumber = 8088

  // configuration of client

  /** We'll use the service provided by the same host. */
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  // lifecycle controller configuration
  def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9.
}

ಇಲ್ಲಿ ನಾವು ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಎರಡನ್ನೂ ವಿಸ್ತರಿಸುವ ಒಂದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ನಾವು ಲೈಫ್‌ಸೈಕಲ್ ನಿಯಂತ್ರಕವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ lifetime ಮಧ್ಯಂತರ ಹಾದುಹೋಗುತ್ತದೆ.

ಎರಡು ಪ್ರತ್ಯೇಕ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಿಸ್ಟಮ್‌ನ ವಿನ್ಯಾಸವನ್ನು ರಚಿಸಲು ಒಂದೇ ರೀತಿಯ ಸೇವಾ ಅನುಷ್ಠಾನಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ನಾವು ಕೇವಲ ರಚಿಸಬೇಕಾಗಿದೆ ಎರಡು ಪ್ರತ್ಯೇಕ ನೋಡ್ ಸಂರಚನೆಗಳು ಸೂಕ್ತ ಸೇವೆಗಳೊಂದಿಗೆ:

ಎರಡು ನೋಡ್‌ಗಳ ಸಂರಚನೆ

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig
  {
    type NodeId = NodeIdImpl

    def nodeId = NodeServer

    override def portNumber: PortNumber = 8080
  }

  object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig
  {
    // NB! dependency specification
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9.

    def testMessage: String = "dolly"
  }

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

ಎರಡು ನೋಡ್ಗಳ ಅನುಷ್ಠಾನ

ಈ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ನಾವು ಒಂದೇ ರೀತಿಯ ಸೇವೆಗಳ ಅನುಷ್ಠಾನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಯಾವುದೇ ಬದಲಾವಣೆಗಳಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಾವು ವಿಭಿನ್ನ ಸೇವೆಗಳನ್ನು ಹೊಂದಿರುವ ಎರಡು ವಿಭಿನ್ನ ನೋಡ್ ಅನುಷ್ಠಾನಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ:

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl {
    type Config = EchoConfig[String] with SigTermLifecycleConfig
  }

  object TwoJvmNodeClientImpl extends ZeroServiceImpl[IO] with EchoClientService with FiniteDurationLifecycleServiceImpl {
    type Config = EchoClientConfig[String] with FiniteDurationLifecycleConfig
  }

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

ಒಟ್ಟಾರೆ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ

ಈ ವಿಧಾನವು ನಾವು ಸಂರಚನೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ವಿಧಾನವನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಕೋಡ್ ಆಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕಲಾಕೃತಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಇತರ ಕೋಡ್ ಕಲಾಕೃತಿಗಳಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಕಲಾಕೃತಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಸಮಂಜಸವೆಂದು ತೋರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಒಂದೇ ಕೋಡ್ ಬೇಸ್‌ನಲ್ಲಿ ಬಹುಸಂಖ್ಯೆಯ ಸಂರಚನೆಗಳನ್ನು ಹೊಂದಬಹುದು. ಮತ್ತು ಸಹಜವಾಗಿ, ನಾವು ವಿವಿಧ ಕಾನ್ಫಿಗರೇಶನ್ ಶಾಖೆಗಳ ಬಹು ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಬಹುದು. ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಾವು ಲೈಬ್ರರಿಗಳ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಮತ್ತು ನಾವು ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿದಾಗಲೆಲ್ಲಾ ಇದು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

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

ಟಿಕೆಟ್ -> PR -> ವಿಮರ್ಶೆ -> ವಿಲೀನ -> ನಿರಂತರ ಏಕೀಕರಣ -> ನಿರಂತರ ನಿಯೋಜನೆ

ವಿಧಾನದ ಕೆಳಗಿನ ಪರಿಣಾಮಗಳು ಇವೆ:

1. ನಿರ್ದಿಷ್ಟ ಸಿಸ್ಟಂನ ನಿದರ್ಶನಕ್ಕೆ ಸಂರಚನೆಯು ಸುಸಂಬದ್ಧವಾಗಿದೆ. ನೋಡ್‌ಗಳ ನಡುವೆ ತಪ್ಪಾದ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ.
2. ಕೇವಲ ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಸುಲಭವಲ್ಲ. ಕೆಲವು ಪಠ್ಯ ಫೈಲ್‌ಗಳನ್ನು ಲಾಗ್ ಇನ್ ಮಾಡುವುದು ಮತ್ತು ಬದಲಾಯಿಸುವುದು ಅಸಮಂಜಸವೆಂದು ತೋರುತ್ತದೆ. ಆದ್ದರಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಡ್ರಿಫ್ಟ್ ಕಡಿಮೆ ಸಾಧ್ಯ.
3. ಸಣ್ಣ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು ಸುಲಭವಲ್ಲ.
4. ಹೆಚ್ಚಿನ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳು ಅದೇ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ ಮತ್ತು ಇದು ಕೆಲವು ವಿಮರ್ಶೆಯನ್ನು ರವಾನಿಸುತ್ತದೆ.

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

ಬದಲಾವಣೆಗಳು

ಇತರ ಸಂರಚನಾ ನಿರ್ವಹಣಾ ತಂತ್ರಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರಸ್ತಾವಿತ ವಿಧಾನದ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ನೋಡೋಣ.

ಮೊದಲನೆಯದಾಗಿ, ಸಂರಚನೆಯೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಉದ್ದೇಶಿತ ವಿಧಾನದ ವಿವಿಧ ಅಂಶಗಳಿಗೆ ನಾವು ಕೆಲವು ಪರ್ಯಾಯಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತೇವೆ:

1. ಗುರಿ ಯಂತ್ರದಲ್ಲಿ ಪಠ್ಯ ಫೈಲ್.
2. ಕೇಂದ್ರೀಕೃತ ಕೀ-ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆ (ಹಾಗೆ etcd/zookeeper).
3. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸದೆಯೇ ಮರುಸಂರಚಿಸಬಹುದಾದ/ಮರುಪ್ರಾರಂಭಿಸಬಹುದಾದ ಉಪಪ್ರಕ್ರಿಯೆ ಘಟಕಗಳು.
4. ಕಲಾಕೃತಿ ಮತ್ತು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದ ಹೊರಗಿನ ಸಂರಚನೆ.

ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರಗಳ ವಿಷಯದಲ್ಲಿ ಪಠ್ಯ ಫೈಲ್ ಕೆಲವು ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ. ಸಿಸ್ಟಂನ ನಿರ್ವಾಹಕರು ಗುರಿ ನೋಡ್‌ಗೆ ಲಾಗಿನ್ ಮಾಡಬಹುದು, ಬದಲಾವಣೆಯನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು. ಇದು ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಉತ್ತಮವಾಗಿಲ್ಲದಿರಬಹುದು. ಬದಲಾವಣೆಯ ಹಿಂದೆ ಯಾವುದೇ ಕುರುಹುಗಳು ಉಳಿದಿಲ್ಲ. ಬದಲಾವಣೆಯನ್ನು ಮತ್ತೊಂದು ಜೋಡಿ ಕಣ್ಣುಗಳಿಂದ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ. ಬದಲಾವಣೆಗೆ ಕಾರಣವೇನು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟವಾಗಬಹುದು. ಇದನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿಲ್ಲ. ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿರ್ವಾಹಕರು ಇತರ ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಸಂರಚನೆಯನ್ನು ನವೀಕರಿಸಲು ಮರೆಯಬಹುದು.

(Btw, ಅಂತಿಮವಾಗಿ ಪಠ್ಯ ಸಂರಚನಾ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ನಾವು ಅದನ್ನು ಉತ್ಪಾದಿಸಬಹುದಾದ ಪಾರ್ಸರ್ + ವ್ಯಾಲಿಡೇಟರ್ ಅನ್ನು ಮಾತ್ರ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ Config ಟೈಪ್ ಮಾಡಿ ಮತ್ತು ಪಠ್ಯ ಸಂರಚನೆಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು ಇದು ಸಾಕಾಗುತ್ತದೆ. ಕಂಪೈಲ್-ಟೈಮ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಸಂಕೀರ್ಣತೆಯು ಪಠ್ಯ-ಆಧಾರಿತ ಸಂರಚನೆಗಳ ಸಂಕೀರ್ಣತೆಗಿಂತ ಸ್ವಲ್ಪ ಚಿಕ್ಕದಾಗಿದೆ ಎಂದು ಇದು ತೋರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪಠ್ಯ-ಆಧಾರಿತ ಆವೃತ್ತಿಯಲ್ಲಿ ನಮಗೆ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಅಗತ್ಯವಿದೆ.)

ಅಪ್ಲಿಕೇಶನ್ ಮೆಟಾ ನಿಯತಾಂಕಗಳನ್ನು ವಿತರಿಸಲು ಕೇಂದ್ರೀಕೃತ ಕೀ-ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆಯು ಉತ್ತಮ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಇಲ್ಲಿ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಮೌಲ್ಯಗಳು ಮತ್ತು ಕೇವಲ ಡೇಟಾ ಯಾವುದು ಎಂದು ಪರಿಗಣಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು. ಕಾರ್ಯವನ್ನು ನೀಡಲಾಗಿದೆ C => A => B ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಅಪರೂಪವಾಗಿ ಬದಲಾಗುವ ಮೌಲ್ಯಗಳನ್ನು ಕರೆಯುತ್ತೇವೆ C "ಕಾನ್ಫಿರೇಶನ್", ಆಗಾಗ್ಗೆ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸುವಾಗ A - ಕೇವಲ ಇನ್ಪುಟ್ ಡೇಟಾ. ಡೇಟಾಕ್ಕಿಂತ ಮುಂಚಿತವಾಗಿ ಕಾರ್ಯಕ್ಕೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಒದಗಿಸಬೇಕು A. ಈ ಕಲ್ಪನೆಯನ್ನು ನೀಡಿದರೆ, ಕೇವಲ ಡೇಟಾದಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಬಳಸಬಹುದಾದ ಬದಲಾವಣೆಗಳ ನಿರೀಕ್ಷಿತ ಆವರ್ತನ ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಡೇಟಾವು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಮೂಲದಿಂದ (ಬಳಕೆದಾರ) ಬರುತ್ತದೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಬೇರೆ ಮೂಲದಿಂದ (ನಿರ್ವಾಹಕ) ಬರುತ್ತದೆ. ಪ್ರಾರಂಭದ ಪ್ರಕ್ರಿಯೆಯ ನಂತರ ಬದಲಾಯಿಸಬಹುದಾದ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್ ಸಂಕೀರ್ಣತೆಯ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಅಂತಹ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಿಗಾಗಿ ನಾವು ಅವುಗಳ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನ, ಪಾರ್ಸಿಂಗ್ ಮತ್ತು ಮೌಲ್ಯೀಕರಣ, ತಪ್ಪಾದ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಪ್ರೋಗ್ರಾಂ ಸಂಕೀರ್ಣತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಬದಲಾಯಿಸಬಹುದಾದ ನಿಯತಾಂಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಉತ್ತಮ (ಅಥವಾ ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುವುದು).

ಈ ಪೋಸ್ಟ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನಾವು ಸ್ಥಿರ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ನಿಯತಾಂಕಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡಬೇಕು. ಸೇವಾ ತರ್ಕಕ್ಕೆ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಕೆಲವು ನಿಯತಾಂಕಗಳ ಅಪರೂಪದ ಬದಲಾವಣೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಅವುಗಳನ್ನು ಡೈನಾಮಿಕ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಎಂದು ಕರೆಯಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ ಅವು ಸ್ಥಿರವಾಗಿರುತ್ತವೆ ಮತ್ತು ಪ್ರಸ್ತಾವಿತ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಡೈನಾಮಿಕ್ ಮರುಸಂರಚನೆಗಾಗಿ ಇತರ ವಿಧಾನಗಳು ಬೇಕಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್‌ನ ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವ ರೀತಿಯಲ್ಲಿಯೇ ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಸಿಸ್ಟಮ್‌ನ ಭಾಗಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು.
(ನನ್ನ ವಿನಮ್ರ ಅಭಿಪ್ರಾಯವೆಂದರೆ ರನ್ಟೈಮ್ ಮರುಸಂರಚನೆಯನ್ನು ತಪ್ಪಿಸುವುದು ಏಕೆಂದರೆ ಇದು ಸಿಸ್ಟಮ್ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಮರುಪ್ರಾರಂಭಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳ OS ಬೆಂಬಲವನ್ನು ಅವಲಂಬಿಸುವುದು ಹೆಚ್ಚು ಸರಳವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಇದು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಾಗದಿರಬಹುದು.)

ಸ್ಥಿರ ಸಂರಚನೆಯನ್ನು ಬಳಸುವ ಒಂದು ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಕೆಲವೊಮ್ಮೆ ಜನರು ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರಿಗಣಿಸುವಂತೆ ಮಾಡುತ್ತದೆ (ಇತರ ಕಾರಣಗಳಿಲ್ಲದೆ) ಕಾನ್ಫಿಗರೇಶನ್ ನವೀಕರಣದ ಸಮಯದಲ್ಲಿ ಸೇವೆಯ ಅಲಭ್ಯತೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಸ್ಥಿರ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾದರೆ, ನಾವು ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕು ಇದರಿಂದ ಹೊಸ ಮೌಲ್ಯಗಳು ಪರಿಣಾಮಕಾರಿಯಾಗುತ್ತವೆ. ಅಲಭ್ಯತೆಯ ಅವಶ್ಯಕತೆಗಳು ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಬದಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಇದು ನಿರ್ಣಾಯಕವಾಗಿರುವುದಿಲ್ಲ. ಇದು ನಿರ್ಣಾಯಕವಾಗಿದ್ದರೆ, ಯಾವುದೇ ಸಿಸ್ಟಂ ಮರುಪ್ರಾರಂಭಿಸಲು ನಾವು ಮುಂದೆ ಯೋಜಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು AWS ELB ಸಂಪರ್ಕ ಬರಿದಾಗುತ್ತಿದೆ. ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ ನಾವು ಸಿಸ್ಟಂ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾದಾಗ, ನಾವು ಸಿಸ್ಟಮ್‌ನ ಹೊಸ ನಿದರ್ಶನವನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ನಂತರ ELB ಅನ್ನು ಅದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೇವೆ, ಆದರೆ ಹಳೆಯ ಸಿಸ್ಟಂ ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪರ್ಕಗಳನ್ನು ಪೂರೈಸಲು ಅನುಮತಿಸುತ್ತೇವೆ.

ಆವೃತ್ತಿಯ ಕಲಾಕೃತಿಯ ಒಳಗೆ ಅಥವಾ ಹೊರಗೆ ಸಂರಚನೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದರ ಬಗ್ಗೆ ಏನು? ಕಲಾಕೃತಿಯೊಳಗೆ ಸಂರಚನೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಎಂದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಈ ಸಂರಚನೆಯು ಇತರ ಕಲಾಕೃತಿಗಳಂತೆಯೇ ಅದೇ ಗುಣಮಟ್ಟದ ಭರವಸೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಂಗೀಕರಿಸಿದೆ. ಆದ್ದರಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಎಂದು ಒಬ್ಬರು ಖಚಿತವಾಗಿರಬಹುದು. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಎಂದರೆ ಆ ಫೈಲ್‌ಗೆ ಯಾರು ಮತ್ತು ಏಕೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ್ದಾರೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಕುರುಹುಗಳಿಲ್ಲ. ಇದು ಮುಖ್ಯವೇ? ಹೆಚ್ಚಿನ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸ್ಥಿರ ಮತ್ತು ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿರುವುದು ಉತ್ತಮ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.

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

ಸಾಧಕ-ಬಾಧಕ

ಇಲ್ಲಿ ನಾವು ಕೆಲವು ಅನುಕೂಲಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಪ್ರಸ್ತಾವಿತ ವಿಧಾನದ ಕೆಲವು ಅನಾನುಕೂಲಗಳನ್ನು ಚರ್ಚಿಸಲು ಬಯಸುತ್ತೇವೆ.

ಪ್ರಯೋಜನಗಳು

ಸಂಪೂರ್ಣ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ಸಂಕಲಿಸಬಹುದಾದ ಸಂರಚನೆಯ ವೈಶಿಷ್ಟ್ಯಗಳು:

1. ಸಂರಚನೆಯ ಸ್ಥಿರ ಪರಿಶೀಲನೆ. ಇದು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ನಿರ್ಬಂಧಗಳನ್ನು ನೀಡಿದ ಸಂರಚನೆಯು ಸರಿಯಾಗಿದೆ.
2. ಸಂರಚನೆಯ ಶ್ರೀಮಂತ ಭಾಷೆ. ವಿಶಿಷ್ಟವಾಗಿ ಇತರ ಸಂರಚನಾ ವಿಧಾನಗಳು ಹೆಚ್ಚಿನ ವೇರಿಯಬಲ್ ಪರ್ಯಾಯಕ್ಕೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ.
   ಸ್ಕಾಲಾವನ್ನು ಬಳಸುವುದರಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಭಾಷಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಒದಗಿಸಲು ನಾವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಳಸಬಹುದು, ವಿಭಿನ್ನ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿಸಲು ವಸ್ತುಗಳು, ನಾವು ಉಲ್ಲೇಖಿಸಬಹುದು valಗಳು ಬಾಹ್ಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ (DRY) ಒಮ್ಮೆ ಮಾತ್ರ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಅಕ್ಷರಶಃ ಅನುಕ್ರಮಗಳು ಅಥವಾ ಕೆಲವು ವರ್ಗಗಳ ನಿದರ್ಶನಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿದೆ (Seq, Map, ಇತ್ಯಾದಿ).
3. DSL. DSL ಬರಹಗಾರರಿಗೆ ಸ್ಕಲಾ ಯೋಗ್ಯ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದೆ. ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಮತ್ತು ಅಂತಿಮ-ಬಳಕೆದಾರ ಸ್ನೇಹಿಯಾಗಿರುವ ಕಾನ್ಫಿಗರೇಶನ್ ಭಾಷೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಒಬ್ಬರು ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಬಹುದು, ಇದರಿಂದಾಗಿ ಅಂತಿಮ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಡೊಮೇನ್ ಬಳಕೆದಾರರಿಂದ ಕನಿಷ್ಠ ಓದಬಹುದಾಗಿದೆ.
4. ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸಮಗ್ರತೆ ಮತ್ತು ಸುಸಂಬದ್ಧತೆ. ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಪೂರ್ಣ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸಂರಚನೆಯನ್ನು ಹೊಂದುವ ಪ್ರಯೋಜನವೆಂದರೆ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಒಮ್ಮೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಮತ್ತು ನಂತರ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸ್ಥಳಗಳಲ್ಲಿ ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಸುರಕ್ಷಿತ ಪೋರ್ಟ್ ಘೋಷಣೆಗಳನ್ನು ಟೈಪ್ ಮಾಡಿ ಎಲ್ಲಾ ಸಂಭವನೀಯ ಸರಿಯಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನ ನೋಡ್‌ಗಳು ಒಂದೇ ಭಾಷೆಯನ್ನು ಮಾತನಾಡುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ನೋಡ್‌ಗಳ ನಡುವೆ ಸ್ಪಷ್ಟವಾದ ಅವಲಂಬನೆಗಳು ಇವೆ, ಇದು ಕೆಲವು ಸೇವೆಗಳನ್ನು ಒದಗಿಸಲು ಮರೆಯಲು ಕಷ್ಟವಾಗುತ್ತದೆ.
5. ಬದಲಾವಣೆಗಳ ಉತ್ತಮ ಗುಣಮಟ್ಟ. ಸಾಮಾನ್ಯ PR ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಸಂರಚನಾ ಬದಲಾವಣೆಗಳನ್ನು ಹಾದುಹೋಗುವ ಒಟ್ಟಾರೆ ವಿಧಾನವು ಸಂರಚನೆಯಲ್ಲಿ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಗುಣಮಟ್ಟವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ.
6. ಏಕಕಾಲಿಕ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳು. ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಾವು ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗಲೆಲ್ಲಾ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯು ಎಲ್ಲಾ ನೋಡ್‌ಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
7. ಅಪ್ಲಿಕೇಶನ್ ಸರಳೀಕರಣ. ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಮತ್ತು ಮೌಲ್ಯೀಕರಿಸಲು ಮತ್ತು ತಪ್ಪಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಒಟ್ಟಾರೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ. (ಕೆಲವು ಸಂಕೀರ್ಣತೆಯ ಹೆಚ್ಚಳವು ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿದೆ, ಆದರೆ ಇದು ಸುರಕ್ಷತೆಯ ಕಡೆಗೆ ಪ್ರಜ್ಞಾಪೂರ್ವಕ ವ್ಯಾಪಾರ-ವಹಿವಾಟು.) ಸಾಮಾನ್ಯ ಸಂರಚನೆಗೆ ಮರಳಲು ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ - ಕಾಣೆಯಾದ ತುಣುಕುಗಳನ್ನು ಸೇರಿಸಿ. ಸಂಕಲಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಸುಲಭ ಮತ್ತು ಹೆಚ್ಚುವರಿ ತುಣುಕುಗಳ ಅನುಷ್ಠಾನವನ್ನು ಕೆಲವು ನಂತರದ ಸಮಯಗಳಿಗೆ ಮುಂದೂಡುವುದು.
8. ಆವೃತ್ತಿಯ ಸಂರಚನೆ. ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳು ಅದೇ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ, ಇದರ ಪರಿಣಾಮವಾಗಿ ನಾವು ಅನನ್ಯ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕಲಾಕೃತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಅಗತ್ಯವಿದ್ದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಒಂದು ವರ್ಷದ ಹಿಂದೆ ಬಳಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಹ ನಿಯೋಜಿಸಬಹುದು ಮತ್ತು ಅದು ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಸ್ಥಿರವಾದ ಸಂರಚನೆಯು ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ಭವಿಷ್ಯ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ಕಂಪೈಲ್ ಸಮಯದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸುಲಭವಾಗಿ ಟ್ಯಾಂಪರ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
9. ಮಾಡ್ಯುಲಾರಿಟಿ. ಪ್ರಸ್ತಾವಿತ ಚೌಕಟ್ಟು ಮಾಡ್ಯುಲರ್ ಆಗಿದೆ ಮತ್ತು ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಸಂಯೋಜಿಸಬಹುದು
   ವಿಭಿನ್ನ ಸಂರಚನೆಗಳನ್ನು ಬೆಂಬಲಿಸಿ (ಸೆಟಪ್‌ಗಳು/ಲೇಔಟ್‌ಗಳು). ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸಣ್ಣ ಪ್ರಮಾಣದ ಏಕ ನೋಡ್ ವಿನ್ಯಾಸ ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಮಲ್ಟಿ ನೋಡ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಹೊಂದಲು ಸಾಧ್ಯವಿದೆ. ಬಹು ಉತ್ಪಾದನಾ ವಿನ್ಯಾಸಗಳನ್ನು ಹೊಂದಲು ಇದು ಸಮಂಜಸವಾಗಿದೆ.
10. ಪರೀಕ್ಷೆ. ಪರೀಕ್ಷಾ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಒಬ್ಬರು ಅಣಕು ಸೇವೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಒಂದು ರೀತಿಯ ಸುರಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಅವಲಂಬನೆಯಾಗಿ ಬಳಸಬಹುದು. ಅಣಕುಗಳಿಂದ ಬದಲಾಯಿಸಲಾದ ವಿವಿಧ ಭಾಗಗಳೊಂದಿಗೆ ಕೆಲವು ವಿಭಿನ್ನ ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಿರ್ವಹಿಸಬಹುದು.
11. ಏಕೀಕರಣ ಪರೀಕ್ಷೆ. ಕೆಲವೊಮ್ಮೆ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಸಂಪೂರ್ಣ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯ ಸುರಕ್ಷಿತ ಸಂರಚನೆಯನ್ನು ಟೈಪ್ ಮಾಡಲು ವಿವರಿಸಿದ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಎಲ್ಲಾ ವಿತರಿಸಿದ ಭಾಗಗಳನ್ನು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ನಿಯಂತ್ರಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಚಲಾಯಿಸಬಹುದು. ಪರಿಸ್ಥಿತಿಯನ್ನು ಅನುಕರಿಸುವುದು ಸುಲಭ
    ಸೇವೆಗಳಲ್ಲಿ ಒಂದು ಅಲಭ್ಯವಾದಾಗ.

ಅನಾನುಕೂಲಗಳು

ಸಂಕಲಿಸಿದ ಸಂರಚನಾ ವಿಧಾನವು "ಸಾಮಾನ್ಯ" ಸಂರಚನೆಯಿಂದ ಭಿನ್ನವಾಗಿದೆ ಮತ್ತು ಇದು ಎಲ್ಲಾ ಅಗತ್ಯಗಳಿಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಸಂಕಲಿಸಿದ ಸಂರಚನೆಯ ಕೆಲವು ಅನಾನುಕೂಲಗಳು ಇಲ್ಲಿವೆ:

1. ಸ್ಥಿರ ಸಂರಚನೆ. ಇದು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲದಿರಬಹುದು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಎಲ್ಲಾ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಸಂರಚನೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ. ಈ ವಿಧಾನವು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಸಂರಚನೆಯಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಯನ್ನು ಮಾಡಿದ ನಂತರ ಸಂಕಲನ ಮತ್ತು ಮರುನಿಯೋಜನೆಯ ಅಗತ್ಯವಿದೆ. ಇದು ವೈಶಿಷ್ಟ್ಯ ಮತ್ತು ಹೊರೆ ಎರಡೂ ಆಗಿದೆ.
2. ಕಾನ್ಫಿಗರೇಶನ್ ಉತ್ಪಾದನೆ. ಕೆಲವು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಉಪಕರಣದಿಂದ ಸಂರಚನೆಯನ್ನು ರಚಿಸಿದಾಗ ಈ ವಿಧಾನಕ್ಕೆ ನಂತರದ ಸಂಕಲನದ ಅಗತ್ಯವಿರುತ್ತದೆ (ಇದು ವಿಫಲವಾಗಬಹುದು). ಈ ಹೆಚ್ಚುವರಿ ಹಂತವನ್ನು ನಿರ್ಮಾಣ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಯೋಜಿಸಲು ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರಬಹುದು.
3. ವಾದ್ಯಗಳು. ಪಠ್ಯ-ಆಧಾರಿತ ಸಂರಚನೆಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಸಾಕಷ್ಟು ಉಪಕರಣಗಳು ಇಂದು ಬಳಕೆಯಲ್ಲಿವೆ. ಅವರಲ್ಲಿ ಕೆಲವರು
   ಕಾನ್ಫಿಗರೇಶನ್ ಕಂಪೈಲ್ ಮಾಡಿದಾಗ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
4. ಮನಸ್ಥಿತಿಯಲ್ಲಿ ಬದಲಾವಣೆಯ ಅಗತ್ಯವಿದೆ. ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು DevOps ಪಠ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಪರಿಚಿತವಾಗಿವೆ. ಸಂರಚನೆಯನ್ನು ಕಂಪೈಲ್ ಮಾಡುವ ಕಲ್ಪನೆಯು ಅವರಿಗೆ ವಿಚಿತ್ರವಾಗಿ ಕಾಣಿಸಬಹುದು.
5. ಸಂಕಲಿಸಬಹುದಾದ ಸಂರಚನೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೊದಲು ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದೆ.

ಅನುಷ್ಠಾನಗೊಂಡ ಉದಾಹರಣೆಯ ಕೆಲವು ಮಿತಿಗಳಿವೆ:

1. ನೋಡ್ ಅನುಷ್ಠಾನದಿಂದ ಬೇಡಿಕೆಯಿಲ್ಲದ ಹೆಚ್ಚುವರಿ ಸಂರಚನೆಯನ್ನು ನಾವು ಒದಗಿಸಿದರೆ, ಗೈರುಹಾಜರಿಯ ಅನುಷ್ಠಾನವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕಂಪೈಲರ್ ನಮಗೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಪರಿಹರಿಸಬಹುದು HList ಅಥವಾ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಕೇಕ್ ಪ್ಯಾಟರ್ನ್ ಬದಲಿಗೆ ನೋಡ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ಎಡಿಟಿಗಳು (ಕೇಸ್ ಕ್ಲಾಸ್‌ಗಳು).
2. ಸಂರಚನಾ ಫೈಲ್‌ನಲ್ಲಿ ನಾವು ಕೆಲವು ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ ಅನ್ನು ಒದಗಿಸಬೇಕಾಗಿದೆ: (package, import, object ಘೋಷಣೆಗಳು;
   override defಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ನಿಯತಾಂಕಗಳಿಗಾಗಿ). ಇದನ್ನು DSL ಬಳಸಿಕೊಂಡು ಭಾಗಶಃ ಪರಿಹರಿಸಬಹುದು.
3. ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಒಂದೇ ರೀತಿಯ ನೋಡ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ಗಳ ಡೈನಾಮಿಕ್ ಮರುಸಂರಚನೆಯನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.

ತೀರ್ಮಾನ

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನೇರವಾಗಿ ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ಒಂದು ರೀತಿಯ ಸುರಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿನಿಧಿಸುವ ಕಲ್ಪನೆಯನ್ನು ಚರ್ಚಿಸಿದ್ದೇವೆ. ವಿಧಾನವನ್ನು xml- ಮತ್ತು ಇತರ ಪಠ್ಯ-ಆಧಾರಿತ ಸಂರಚನೆಗಳಿಗೆ ಬದಲಿಯಾಗಿ ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಬಳಸಬಹುದು. ಅದರ ಹೊರತಾಗಿಯೂ ನಮ್ಮ ಉದಾಹರಣೆಯನ್ನು ಸ್ಕಾಲಾದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ, ಇದನ್ನು ಇತರ ಸಂಕಲಿಸಬಹುದಾದ ಭಾಷೆಗಳಿಗೆ (ಕೋಟ್ಲಿನ್, ಸಿ #, ಸ್ವಿಫ್ಟ್, ಇತ್ಯಾದಿ) ಅನುವಾದಿಸಬಹುದು. ಹೊಸ ಯೋಜನೆಯಲ್ಲಿ ಈ ವಿಧಾನವನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು ಮತ್ತು ಅದು ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಹಳೆಯ ಶೈಲಿಗೆ ಬದಲಿಸಿ.

ಸಹಜವಾಗಿ, ಸಂಕಲಿಸಬಹುದಾದ ಸಂರಚನೆಗೆ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದೆ. ಪ್ರತಿಯಾಗಿ ಇದು ಸಮನಾಗಿ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ದೃಢವಾದ ಸಂರಚನೆಯನ್ನು ಒದಗಿಸಲು ಭರವಸೆ ನೀಡುತ್ತದೆ.

ಈ ವಿಧಾನವನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ವಿಸ್ತರಿಸಬಹುದು:

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

ಧನ್ಯವಾದಗಳು

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

ಮೂಲ: www.habr.com