🥇 ਇੱਕ ਵਿਤਰਿਤ ਸਿਸਟਮ ਦੀ ਸੰਕਲਿਤ ਸੰਰਚਨਾ

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਵਿਤਰਿਤ ਸਿਸਟਮ ਦੀ ਸੰਰਚਨਾ ਨਾਲ ਨਜਿੱਠਣ ਦਾ ਇੱਕ ਦਿਲਚਸਪ ਤਰੀਕਾ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗੇ।
ਸੰਰਚਨਾ ਨੂੰ ਸਕਾਲਾ ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਕਿਸਮ ਦੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਿੱਧਾ ਪ੍ਰਸਤੁਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕ ਉਦਾਹਰਨ ਲਾਗੂਕਰਨ ਵੇਰਵੇ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ. ਸਮੁੱਚੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਪ੍ਰਭਾਵ ਸਮੇਤ ਪ੍ਰਸਤਾਵ ਦੇ ਵੱਖ-ਵੱਖ ਪਹਿਲੂਆਂ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ।

(ਰੂਸੀ ਵਿੱਚ)

ਜਾਣ-ਪਛਾਣ

ਮਜ਼ਬੂਤ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ ਸਹੀ ਅਤੇ ਇਕਸਾਰ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਖਾਸ ਹੱਲ ਇੱਕ ਟੈਕਸਟ ਡਿਪਲਾਇਮੈਂਟ ਵਰਣਨ (ਟੇਰਾਫਾਰਮ, ਜਵਾਬਦੇਹ ਜਾਂ ਕੁਝ ਸਮਾਨ) ਅਤੇ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀਆਂ ਸੰਰਚਨਾ ਫਾਈਲਾਂ (ਅਕਸਰ — ਹਰੇਕ ਨੋਡ/ਰੋਲ ਲਈ ਸਮਰਪਿਤ) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। ਅਸੀਂ ਹਰੇਕ ਸੰਚਾਰ ਨੋਡਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਸੰਸਕਰਣਾਂ ਦੇ ਇੱਕੋ ਜਿਹੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹਾਂਗੇ (ਨਹੀਂ ਤਾਂ ਅਸੀਂ ਅਸੰਗਤਤਾ ਦੇ ਮੁੱਦਿਆਂ ਦਾ ਅਨੁਭਵ ਕਰਾਂਗੇ)। JVM ਸੰਸਾਰ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਘੱਟੋ ਘੱਟ ਮੈਸੇਜਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਸਾਰੇ ਸੰਚਾਰ ਨੋਡਾਂ 'ਤੇ ਇੱਕੋ ਸੰਸਕਰਣ ਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਸਿਸਟਮ ਦੀ ਜਾਂਚ ਬਾਰੇ ਕੀ? ਬੇਸ਼ੱਕ, ਏਕੀਕਰਣ ਟੈਸਟਾਂ 'ਤੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਡੇ ਕੋਲ ਸਾਰੇ ਹਿੱਸਿਆਂ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਰਨਟਾਈਮ 'ਤੇ ਟੈਸਟ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਐਕਸਟਰਾਪੋਲੇਟ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਸੰਸਕਰਣ ਰਨਟਾਈਮ ਅਤੇ ਟੈਸਟਿੰਗ ਵਾਤਾਵਰਨ ਦੋਵਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਰੱਖੇ ਜਾਣ।

ਏਕੀਕਰਣ ਟੈਸਟ ਚਲਾਉਣ ਵੇਲੇ, ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ ਇੱਕੋ ਕਲਾਸਪਾਥ ਹੋਣਾ ਅਕਸਰ ਬਹੁਤ ਸੌਖਾ ਹੁੰਦਾ ਹੈ। ਸਾਨੂੰ ਸਿਰਫ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੈਨਾਤੀ 'ਤੇ ਉਹੀ ਕਲਾਸਪਾਥ ਵਰਤਿਆ ਗਿਆ ਹੈ। (ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਕਲਾਸਪਾਥਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਪਰ ਇਸ ਸੰਰਚਨਾ ਨੂੰ ਦਰਸਾਉਣਾ ਅਤੇ ਇਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੈ।) ਇਸ ਲਈ ਚੀਜ਼ਾਂ ਨੂੰ ਸਧਾਰਨ ਰੱਖਣ ਲਈ ਅਸੀਂ ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਕਲਾਸਪਾਥਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ।

ਸੰਰਚਨਾ ਸਾਫਟਵੇਅਰ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਵਿਕਸਿਤ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਪਛਾਣਾਂ ਲਈ ਸੰਸਕਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ
ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਦੇ ਪੜਾਅ. ਸੰਸਕਰਣ ਪ੍ਰਬੰਧਨ ਦੇ ਅਧੀਨ ਸੰਰਚਨਾ ਨੂੰ ਕਵਰ ਕਰਨਾ ਅਤੇ ਕੁਝ ਲੇਬਲਾਂ ਨਾਲ ਵੱਖਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਉਚਿਤ ਜਾਪਦਾ ਹੈ। ਜੇਕਰ ਉਤਪਾਦਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਸੰਰਚਨਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਪਛਾਣਕਰਤਾ ਵਜੋਂ ਸਿੰਗਲ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਕਈ ਵਾਰ ਸਾਡੇ ਕੋਲ ਕਈ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਹੋ ਸਕਦੇ ਹਨ। ਅਤੇ ਹਰੇਕ ਵਾਤਾਵਰਣ ਲਈ ਸਾਨੂੰ ਸੰਰਚਨਾ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸ਼ਾਖਾ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਦੀ ਵਿਲੱਖਣ ਪਛਾਣ ਕਰਨ ਲਈ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਸ਼ਾਖਾ ਅਤੇ ਸੰਸਕਰਣ ਨਾਲ ਲੇਬਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਬ੍ਰਾਂਚ ਲੇਬਲ ਅਤੇ ਸੰਸਕਰਣ ਹਰੇਕ ਨੋਡ 'ਤੇ ਵੰਡੇ ਨੋਡਾਂ, ਪੋਰਟਾਂ, ਬਾਹਰੀ ਸਰੋਤਾਂ, ਕਲਾਸਪਾਥ ਲਾਇਬ੍ਰੇਰੀ ਸੰਸਕਰਣਾਂ ਦੇ ਇੱਕ ਸਿੰਗਲ ਸੁਮੇਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇੱਥੇ ਅਸੀਂ ਕੇਵਲ ਇੱਕ ਸ਼ਾਖਾ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ ਅਤੇ ਤਿੰਨ ਭਾਗਾਂ ਵਾਲੇ ਦਸ਼ਮਲਵ ਸੰਸਕਰਣ (1.2.3) ਦੁਆਰਾ ਸੰਰਚਨਾਵਾਂ ਦੀ ਪਛਾਣ ਕਰਾਂਗੇ, ਉਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਕਿ ਹੋਰ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ।

ਆਧੁਨਿਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੂੰ ਹੁਣ ਹੱਥੀਂ ਸੋਧਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਅਸੀਂ ਤਿਆਰ ਕਰਦੇ ਹਾਂ
ਤੈਨਾਤੀ ਸਮੇਂ ਅਤੇ config ਫਾਈਲਾਂ ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਨਾ ਛੂਹੋ ਬਾਅਦ ਵਿੱਚ ਇਸ ਲਈ ਕੋਈ ਪੁੱਛ ਸਕਦਾ ਹੈ ਕਿ ਅਸੀਂ ਅਜੇ ਵੀ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਲਈ ਟੈਕਸਟ ਫਾਰਮੈਟ ਕਿਉਂ ਵਰਤਦੇ ਹਾਂ? ਇੱਕ ਵਿਹਾਰਕ ਵਿਕਲਪ ਹੈ ਸੰਰਚਨਾ ਨੂੰ ਇੱਕ ਕੰਪਾਈਲੇਸ਼ਨ ਯੂਨਿਟ ਦੇ ਅੰਦਰ ਰੱਖਣਾ ਅਤੇ ਕੰਪਾਈਲ-ਟਾਈਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਲਾਭ ਲੈਣਾ।

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਸੰਕਲਿਤ ਆਰਟੀਫੈਕਟ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਰੱਖਣ ਦੇ ਵਿਚਾਰ ਦੀ ਜਾਂਚ ਕਰਾਂਗੇ।

ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ

ਇਸ ਭਾਗ ਵਿੱਚ ਅਸੀਂ ਸਥਿਰ ਸੰਰਚਨਾ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ। ਦੋ ਸਧਾਰਨ ਸੇਵਾਵਾਂ - ਈਕੋ ਸੇਵਾ ਅਤੇ ਈਕੋ ਸੇਵਾ ਦਾ ਕਲਾਇੰਟ ਕੌਂਫਿਗਰ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਫਿਰ ਦੋਨੋਂ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਦੋ ਵੱਖ-ਵੱਖ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਨੋਡ ਸੰਰਚਨਾ ਲਈ ਹੈ ਅਤੇ ਦੂਜਾ ਦੋ ਨੋਡ ਸੰਰਚਨਾ ਲਈ ਹੈ।

ਇੱਕ ਆਮ ਵੰਡੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਕੁਝ ਨੋਡ ਹੁੰਦੇ ਹਨ। ਨੋਡਸ ਨੂੰ ਕੁਝ ਕਿਸਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ:

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 ਜੋ ਕਿ ਕਲਾਸ ਵਿੱਚ ਨਹੀਂ ਵਰਤੀ ਜਾਂਦੀ। ਇਹ ਇੱਕ ਅਖੌਤੀ ਹੈ ਫੈਂਟਮ ਕਿਸਮ. ਰਨਟਾਈਮ 'ਤੇ ਸਾਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਆਈਡੈਂਟੀਫਾਇਰ ਦੀ ਘੱਟ ਹੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਸੰਕਲਨ ਦੇ ਦੌਰਾਨ ਇਹ ਫੈਂਟਮ ਕਿਸਮ ਵਾਧੂ ਕਿਸਮ ਦੀ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਗਲਤ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਪੋਰਟ ਪਾਸ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚੋਂ ਇੱਕ 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]]
}

ਅਜਿਹੇ ਫੰਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਕੁਝ ਸੰਭਵ ਤਰੀਕੇ ਹਨ.

ਜੇਕਰ ਅਸੀਂ ਡਿਪਲਾਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਪਤੇ ਜਾਣਦੇ ਹਾਂ, ਨੋਡ ਹੋਸਟ ਇੰਸਟੈਂਟੇਸ਼ਨ ਦੇ ਦੌਰਾਨ, ਤਾਂ ਅਸੀਂ ਅਸਲ ਪਤਿਆਂ ਦੇ ਨਾਲ ਸਕੇਲਾ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਿਲਡ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹਾਂ (ਜੋ ਕੰਪਾਈਲ ਟਾਈਮ ਚੈਕ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਏਕੀਕਰਣ ਟੈਸਟ ਸੂਟ ਚਲਾਉਂਦਾ ਹੈ)। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਸਾਡੇ ਮੈਪਿੰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਸਥਿਰ ਤੌਰ 'ਤੇ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਲਈ ਸਰਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ Map[NodeId, NodeAddress].
ਕਦੇ-ਕਦੇ ਅਸੀਂ ਅਸਲ ਪਤੇ ਸਿਰਫ ਬਾਅਦ ਦੇ ਬਿੰਦੂ 'ਤੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਨੋਡ ਅਸਲ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਸਾਡੇ ਕੋਲ ਨੋਡਾਂ ਦੇ ਪਤੇ ਨਹੀਂ ਹੁੰਦੇ ਹਨ ਜੋ ਅਜੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਏ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਇੱਕ ਖੋਜ ਸੇਵਾ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਹੋਰ ਸਾਰੇ ਨੋਡਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹਰੇਕ ਨੋਡ ਉਸ ਸੇਵਾ ਵਿੱਚ ਆਪਣੇ ਪਤੇ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਨਿਰਭਰਤਾ ਲਈ ਗਾਹਕ ਬਣ ਸਕਦਾ ਹੈ।
ਜੇਕਰ ਅਸੀਂ ਸੋਧ ਸਕਦੇ ਹਾਂ /etc/hosts, ਅਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਹੋਸਟ ਨਾਂ (ਜਿਵੇਂ my-project-main-node ਅਤੇ echo-backend) ਅਤੇ ਸਿਰਫ਼ ਤੈਨਾਤੀ ਸਮੇਂ ਇਸ ਨਾਮ ਨੂੰ ip ਐਡਰੈੱਸ ਨਾਲ ਜੋੜੋ।

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਇਹਨਾਂ ਕੇਸਾਂ ਨੂੰ ਹੋਰ ਵੇਰਵਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਅਸਲ ਵਿੱਚ ਸਾਡੇ ਖਿਡੌਣੇ ਦੀ ਉਦਾਹਰਣ ਵਿੱਚ ਸਾਰੇ ਨੋਡਾਂ ਦਾ ਇੱਕੋ IP ਪਤਾ ਹੋਵੇਗਾ - 127.0.0.1.

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਦੋ ਵਿਤਰਿਤ ਸਿਸਟਮ ਲੇਆਉਟ ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ:

ਸਿੰਗਲ ਨੋਡ ਲੇਆਉਟ, ਜਿੱਥੇ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਸਿੰਗਲ ਨੋਡ 'ਤੇ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਦੋ ਨੋਡ ਲੇਆਉਟ, ਜਿੱਥੇ ਸੇਵਾ ਅਤੇ ਕਲਾਇੰਟ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਹਨ।

ਏ ਲਈ ਸੰਰਚਨਾ ਸਿੰਗਲ ਨੋਡ ਖਾਕਾ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

ਸਿੰਗਲ ਨੋਡ ਸੰਰਚਨਾ

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 -> ਸਮੀਖਿਆ -> ਅਭੇਦ -> ਨਿਰੰਤਰ ਏਕੀਕਰਣ -> ਨਿਰੰਤਰ ਤੈਨਾਤੀ

ਪਹੁੰਚ ਦੇ ਹੇਠ ਦਿੱਤੇ ਨਤੀਜੇ ਹਨ:

ਸੰਰਚਨਾ ਇੱਕ ਖਾਸ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਲਈ ਅਨੁਕੂਲ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਨੋਡਾਂ ਵਿਚਕਾਰ ਗਲਤ ਕੁਨੈਕਸ਼ਨ ਹੋਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ.
ਸਿਰਫ਼ ਇੱਕ ਨੋਡ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਣਾ ਆਸਾਨ ਨਹੀਂ ਹੈ। ਲੌਗ ਇਨ ਕਰਨਾ ਅਤੇ ਕੁਝ ਟੈਕਸਟ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਣਾ ਗੈਰਵਾਜਬ ਜਾਪਦਾ ਹੈ। ਇਸ ਲਈ ਸੰਰਚਨਾ ਡ੍ਰਾਈਫਟ ਘੱਟ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।
ਛੋਟੀਆਂ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਕਰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸੰਰਚਨਾ ਬਦਲਾਅ ਉਸੇ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰਨਗੇ, ਅਤੇ ਇਹ ਕੁਝ ਸਮੀਖਿਆ ਪਾਸ ਕਰੇਗਾ।

ਕੀ ਸਾਨੂੰ ਉਤਪਾਦਨ ਸੰਰਚਨਾ ਲਈ ਇੱਕ ਵੱਖਰੀ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਲੋੜ ਹੈ? ਉਤਪਾਦਨ ਸੰਰਚਨਾ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸਨੂੰ ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸ ਲਈ ਇਹ ਪ੍ਰਤੀਬੰਧਿਤ ਪਹੁੰਚ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਰਿਪੋਜ਼ਟਰੀ ਰੱਖਣ ਦੇ ਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਤਪਾਦਨ ਸੰਰਚਨਾ ਸ਼ਾਮਲ ਹੋਵੇਗੀ। ਅਸੀਂ ਸੰਰਚਨਾ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਸਕਦੇ ਹਾਂ - ਇੱਕ ਜਿਸ ਵਿੱਚ ਉਤਪਾਦਨ ਦੇ ਸਭ ਤੋਂ ਖੁੱਲ੍ਹੇ ਮਾਪਦੰਡ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਜਿਸ ਵਿੱਚ ਸੰਰਚਨਾ ਦਾ ਗੁਪਤ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਅਸਲ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹੋਏ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਿਸ਼ਾਲ ਬਹੁਗਿਣਤੀ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸਮਰੱਥ ਕਰੇਗਾ। ਡਿਫੌਲਟ ਪੈਰਾਮੀਟਰ ਮੁੱਲਾਂ ਦੇ ਨਾਲ ਵਿਚਕਾਰਲੇ ਗੁਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਨੂੰ ਪੂਰਾ ਕਰਨਾ ਆਸਾਨ ਹੈ।

ਫਰਕ

ਆਉ ਹੋਰ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਤਕਨੀਕਾਂ ਦੇ ਮੁਕਾਬਲੇ ਪ੍ਰਸਤਾਵਿਤ ਪਹੁੰਚ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਦੇਖੀਏ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਸੰਰਚਨਾ ਨਾਲ ਨਜਿੱਠਣ ਦੇ ਪ੍ਰਸਤਾਵਿਤ ਤਰੀਕੇ ਦੇ ਵੱਖ-ਵੱਖ ਪਹਿਲੂਆਂ ਲਈ ਕੁਝ ਵਿਕਲਪਾਂ ਦੀ ਸੂਚੀ ਦੇਵਾਂਗੇ:

ਟੀਚੇ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਟੈਕਸਟ ਫਾਇਲ.
ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰੇਜ (ਜਿਵੇਂ etcd/zookeeper).
ਸਬ-ਪ੍ਰੋਸੈਸ ਕੰਪੋਨੈਂਟ ਜੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੀਸਟਾਰਟ ਕੀਤੇ ਬਿਨਾਂ ਮੁੜ ਸੰਰਚਿਤ/ਮੁੜ-ਸ਼ੁਰੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਕਲਾਤਮਕਤਾ ਅਤੇ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਸੰਰਚਨਾ।

ਟੈਕਸਟ ਫਾਈਲ ਐਡ-ਹਾਕ ਫਿਕਸ ਦੇ ਰੂਪ ਵਿੱਚ ਕੁਝ ਲਚਕਤਾ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਸਿਸਟਮ ਦਾ ਪ੍ਰਬੰਧਕ ਟਾਰਗੇਟ ਨੋਡ ਵਿੱਚ ਲੌਗਇਨ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ ਤਬਦੀਲੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਡੇ ਸਿਸਟਮਾਂ ਲਈ ਉੱਨਾ ਚੰਗਾ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਪਰਿਵਰਤਨ ਦੇ ਪਿੱਛੇ ਕੋਈ ਨਿਸ਼ਾਨ ਨਹੀਂ ਬਚਿਆ ਹੈ. ਪਰਿਵਰਤਨ ਦੀ ਸਮੀਖਿਆ ਕਿਸੇ ਹੋਰ ਅੱਖਾਂ ਦੁਆਰਾ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤਬਦੀਲੀ ਦਾ ਕਾਰਨ ਕੀ ਹੈ। ਇਸ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ। ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਿਸਟਮ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ ਹੋਰ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਭੁੱਲ ਸਕਦਾ ਹੈ।

(Btw, ਜੇਕਰ ਆਖਰਕਾਰ ਟੈਕਸਟ ਕੌਂਫਿਗ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਤਾਂ ਸਾਨੂੰ ਸਿਰਫ ਪਾਰਸਰ + ਵੈਲੀਡੇਟਰ ਜੋੜਨਾ ਪਏਗਾ ਜੋ ਸਮਾਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। Config ਟਾਈਪ ਕਰੋ ਅਤੇ ਇਹ ਟੈਕਸਟ ਕੌਂਫਿਗਸ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇਗਾ। ਇਹ ਇਹ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੰਪਾਈਲ-ਟਾਈਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਗੁੰਝਲਤਾ ਟੈਕਸਟ-ਅਧਾਰਤ ਸੰਰਚਨਾ ਦੀ ਗੁੰਝਲਤਾ ਨਾਲੋਂ ਥੋੜ੍ਹੀ ਛੋਟੀ ਹੈ, ਕਿਉਂਕਿ ਟੈਕਸਟ-ਅਧਾਰਤ ਸੰਸਕਰਣ ਵਿੱਚ ਸਾਨੂੰ ਕੁਝ ਵਾਧੂ ਕੋਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।)

ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰੇਜ ਐਪਲੀਕੇਸ਼ਨ ਮੈਟਾ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਇੱਕ ਵਧੀਆ ਵਿਧੀ ਹੈ। ਇੱਥੇ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਅਸੀਂ ਕੀ ਸੰਰਚਨਾ ਮੁੱਲ ਸਮਝਦੇ ਹਾਂ ਅਤੇ ਸਿਰਫ਼ ਡੇਟਾ ਕੀ ਹੈ। ਫੰਕਸ਼ਨ ਦਿੱਤਾ ਗਿਆ C => A => B ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਹੀ ਬਦਲਦੇ ਮੁੱਲਾਂ ਨੂੰ ਕਹਿੰਦੇ ਹਾਂ C "ਸੰਰਚਨਾ", ਜਦੋਂ ਕਿ ਅਕਸਰ ਡਾਟਾ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ A - ਸਿਰਫ਼ ਇਨਪੁਟ ਡੇਟਾ। ਫੰਕਸ਼ਨ ਨੂੰ ਡਾਟਾ ਤੋਂ ਪਹਿਲਾਂ ਸੰਰਚਨਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ A. ਇਸ ਵਿਚਾਰ ਨੂੰ ਦੇਖਦੇ ਹੋਏ ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਉਹਨਾਂ ਤਬਦੀਲੀਆਂ ਦੀ ਸੰਭਾਵਿਤ ਬਾਰੰਬਾਰਤਾ ਹੈ ਜੋ ਸੰਰਚਨਾ ਡੇਟਾ ਨੂੰ ਸਿਰਫ਼ ਡੇਟਾ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਨਾਲ ਹੀ ਡੇਟਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਰੋਤ (ਉਪਭੋਗਤਾ) ਤੋਂ ਆਉਂਦਾ ਹੈ ਅਤੇ ਸੰਰਚਨਾ ਇੱਕ ਵੱਖਰੇ ਸਰੋਤ (ਪ੍ਰਬੰਧਕ) ਤੋਂ ਆਉਂਦੀ ਹੈ। ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਨਜਿੱਠਣਾ ਜੋ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਅਦ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਅਜਿਹੇ ਮਾਪਦੰਡਾਂ ਲਈ ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਡਿਲੀਵਰੀ ਵਿਧੀ, ਪਾਰਸਿੰਗ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ, ਗਲਤ ਮੁੱਲਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਹੋਵੇਗਾ। ਇਸ ਲਈ, ਪ੍ਰੋਗਰਾਮ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਅਸੀਂ ਉਹਨਾਂ ਮਾਪਦੰਡਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਘਟਾਵਾਂਗੇ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਬਦਲ ਸਕਦੇ ਹਨ (ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਵੀ ਕਰ ਸਕਦੇ ਹਨ)।

ਇਸ ਪੋਸਟ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਸਾਨੂੰ ਸਥਿਰ ਅਤੇ ਗਤੀਸ਼ੀਲ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਅੰਤਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਸੇਵਾ ਤਰਕ ਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਕੁਝ ਮਾਪਦੰਡਾਂ ਦੀ ਦੁਰਲੱਭ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਡਾਇਨਾਮਿਕ ਪੈਰਾਮੀਟਰ ਕਹਿ ਸਕਦੇ ਹਾਂ। ਨਹੀਂ ਤਾਂ ਉਹ ਸਥਿਰ ਹਨ ਅਤੇ ਪ੍ਰਸਤਾਵਿਤ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੌਂਫਿਗਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਗਤੀਸ਼ੀਲ ਪੁਨਰ-ਸੰਰਚਨਾ ਲਈ ਹੋਰ ਪਹੁੰਚਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਿਸਟਮ ਦੇ ਭਾਗਾਂ ਨੂੰ ਨਵੇਂ ਸੰਰਚਨਾ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇੱਕ ਵੰਡੇ ਸਿਸਟਮ ਦੀਆਂ ਵੱਖਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਲਈ।
(ਮੇਰੀ ਨਿਮਰ ਰਾਏ ਰਨਟਾਈਮ ਪੁਨਰ-ਸੰਰਚਨਾ ਤੋਂ ਬਚਣ ਲਈ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿਸਟਮ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।
ਰੀਸਟਾਰਟ ਕਰਨ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ OS ਸਮਰਥਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਵਧੇਰੇ ਸਿੱਧਾ ਹੋ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੋ ਸਕਦਾ।)

ਸਥਿਰ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਜੋ ਕਈ ਵਾਰ ਲੋਕਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ (ਹੋਰ ਕਾਰਨਾਂ ਤੋਂ ਬਿਨਾਂ) 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਸੰਰਚਨਾ ਅੱਪਡੇਟ ਦੌਰਾਨ ਸਰਵਿਸ ਡਾਊਨਟਾਈਮ ਹੈ। ਦਰਅਸਲ, ਜੇਕਰ ਸਾਨੂੰ ਸਥਿਰ ਸੰਰਚਨਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨੀਆਂ ਹਨ, ਤਾਂ ਸਾਨੂੰ ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਪਵੇਗਾ ਤਾਂ ਜੋ ਨਵੇਂ ਮੁੱਲ ਪ੍ਰਭਾਵੀ ਬਣ ਸਕਣ। ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਡਾਊਨਟਾਈਮ ਦੀਆਂ ਲੋੜਾਂ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਇਸਲਈ ਇਹ ਇੰਨਾ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਜੇਕਰ ਇਹ ਨਾਜ਼ੁਕ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਕਿਸੇ ਵੀ ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਲਈ ਅੱਗੇ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਪਵੇਗੀ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ AWS ELB ਕੁਨੈਕਸ਼ਨ ਡਰੇਨਿੰਗ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਜਦੋਂ ਵੀ ਸਾਨੂੰ ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਸੀਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਸਿਸਟਮ ਦੀ ਇੱਕ ਨਵੀਂ ਉਦਾਹਰਨ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਫਿਰ ਪੁਰਾਣੇ ਸਿਸਟਮ ਨੂੰ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋਏ, ਇਸ ਵਿੱਚ ELB ਨੂੰ ਬਦਲਦੇ ਹਾਂ।

ਸੰਸਕਰਣ ਵਾਲੇ ਆਰਟੀਫੈਕਟ ਦੇ ਅੰਦਰ ਜਾਂ ਬਾਹਰ ਸੰਰਚਨਾ ਰੱਖਣ ਬਾਰੇ ਕੀ? ਕਿਸੇ ਆਰਟੀਫੈਕਟ ਦੇ ਅੰਦਰ ਸੰਰਚਨਾ ਰੱਖਣ ਦਾ ਮਤਲਬ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਹੈ ਕਿ ਇਹ ਸੰਰਚਨਾ ਹੋਰ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਵਾਂਗ ਗੁਣਵੱਤਾ ਭਰੋਸਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪਾਸ ਕਰ ਚੁੱਕੀ ਹੈ। ਇਸ ਲਈ ਕੋਈ ਇਹ ਯਕੀਨੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸੰਰਚਨਾ ਚੰਗੀ ਗੁਣਵੱਤਾ ਅਤੇ ਭਰੋਸੇਮੰਦ ਹੈ. ਇਸਦੇ ਉਲਟ ਇੱਕ ਵੱਖਰੀ ਫਾਈਲ ਵਿੱਚ ਸੰਰਚਨਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਸ ਫਾਈਲ ਵਿੱਚ ਕਿਸਨੇ ਅਤੇ ਕਿਉਂ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਹਨ, ਇਸ ਦਾ ਕੋਈ ਨਿਸ਼ਾਨ ਨਹੀਂ ਹੈ। ਕੀ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ? ਸਾਡਾ ਮੰਨਣਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਸਥਿਰ ਅਤੇ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੀ ਸੰਰਚਨਾ ਹੋਣਾ ਬਿਹਤਰ ਹੈ।

ਆਰਟੀਫੈਕਟ ਦਾ ਸੰਸਕਰਣ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ ਕਦੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਇਸ ਵਿੱਚ ਕਿਹੜੇ ਮੁੱਲ ਸ਼ਾਮਲ ਹਨ, ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਮਰੱਥ/ਅਯੋਗ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹਰੇਕ ਤਬਦੀਲੀ ਕਰਨ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਸੀ। ਕਿਸੇ ਆਰਟੀਫੈਕਟ ਦੇ ਅੰਦਰ ਸੰਰਚਨਾ ਰੱਖਣ ਲਈ ਇਸ ਨੂੰ ਕੁਝ ਜਤਨ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਇਹ ਬਣਾਉਣ ਲਈ ਇੱਕ ਡਿਜ਼ਾਈਨ ਵਿਕਲਪ ਹੈ।

ਲਾਭ ਅਤੇ ਵਿੱਤ

ਇੱਥੇ ਅਸੀਂ ਕੁਝ ਫਾਇਦਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਪ੍ਰਸਤਾਵਿਤ ਪਹੁੰਚ ਦੇ ਕੁਝ ਨੁਕਸਾਨਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਫਾਇਦੇ

ਇੱਕ ਸੰਪੂਰਨ ਵਿਤਰਿਤ ਸਿਸਟਮ ਦੀ ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

ਸੰਰਚਨਾ ਦੀ ਸਥਿਰ ਜਾਂਚ। ਇਹ ਇੱਕ ਉੱਚ ਪੱਧਰ ਦਾ ਵਿਸ਼ਵਾਸ ਦਿੰਦਾ ਹੈ, ਕਿ ਸੰਰਚਨਾ ਸਹੀ ਹੈ ਕਿਸਮ ਦੀਆਂ ਰੁਕਾਵਟਾਂ.
ਸੰਰਚਨਾ ਦੀ ਅਮੀਰ ਭਾਸ਼ਾ। ਆਮ ਤੌਰ 'ਤੇ ਹੋਰ ਸੰਰਚਨਾ ਪਹੁੰਚ ਜ਼ਿਆਦਾਤਰ ਵੇਰੀਏਬਲ ਪ੍ਰਤੀਸਥਾਪਨ ਤੱਕ ਹੀ ਸੀਮਿਤ ਹੁੰਦੀਆਂ ਹਨ।
Scala ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਭਾਸ਼ਾ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਡਿਫੌਲਟ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਗੁਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਵੱਖ-ਵੱਖ ਸਕੋਪ ਸੈੱਟ ਕਰਨ ਲਈ ਵਸਤੂਆਂ, ਅਸੀਂ ਇਹਨਾਂ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੇ ਹਾਂ vals ਨੂੰ ਬਾਹਰੀ ਦਾਇਰੇ (DRY) ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਸ਼ਾਬਦਿਕ ਕ੍ਰਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਜਾਂ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ (Seq, Map, ਆਦਿ).
DSL. ਸਕੇਲਾ ਕੋਲ DSL ਲੇਖਕਾਂ ਲਈ ਵਧੀਆ ਸਮਰਥਨ ਹੈ. ਕੋਈ ਵੀ ਇਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਇੱਕ ਸੰਰਚਨਾ ਭਾਸ਼ਾ ਸਥਾਪਤ ਕਰਨ ਲਈ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੇ ਅਨੁਕੂਲ ਹੈ, ਤਾਂ ਜੋ ਅੰਤਮ ਸੰਰਚਨਾ ਘੱਟੋ ਘੱਟ ਡੋਮੇਨ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਪੜ੍ਹਨਯੋਗ ਹੋਵੇ।
ਨੋਡਾਂ ਵਿੱਚ ਇਕਸਾਰਤਾ ਅਤੇ ਤਾਲਮੇਲ। ਇੱਕ ਥਾਂ 'ਤੇ ਪੂਰੇ ਵਿਤਰਿਤ ਸਿਸਟਮ ਲਈ ਸੰਰਚਨਾ ਹੋਣ ਦਾ ਇੱਕ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਸਾਰੇ ਮੁੱਲਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਸਖਤੀ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸੁਰੱਖਿਅਤ ਪੋਰਟ ਘੋਸ਼ਣਾ ਵੀ ਟਾਈਪ ਕਰੋ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਾਰੀਆਂ ਸੰਭਵ ਸਹੀ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਸਿਸਟਮ ਦੇ ਨੋਡ ਇੱਕੋ ਭਾਸ਼ਾ ਬੋਲਣਗੇ। ਨੋਡਾਂ ਵਿਚਕਾਰ ਸਪੱਸ਼ਟ ਨਿਰਭਰਤਾਵਾਂ ਹਨ ਜੋ ਕੁਝ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਭੁੱਲਣਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਤਬਦੀਲੀਆਂ ਦੀ ਉੱਚ ਗੁਣਵੱਤਾ. ਸਧਾਰਣ PR ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਸਮੁੱਚੀ ਪਹੁੰਚ ਸੰਰਚਨਾ ਵਿੱਚ ਵੀ ਗੁਣਵੱਤਾ ਦੇ ਉੱਚ ਮਾਪਦੰਡ ਸਥਾਪਤ ਕਰਦੀ ਹੈ।
ਸਮਕਾਲੀ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ। ਜਦੋਂ ਵੀ ਅਸੀਂ ਸੰਰਚਨਾ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਕਰਦੇ ਹਾਂ ਆਟੋਮੈਟਿਕ ਤੈਨਾਤੀ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਸਾਰੇ ਨੋਡ ਅੱਪਡੇਟ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ।
ਐਪਲੀਕੇਸ਼ਨ ਸਰਲੀਕਰਨ. ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਪਾਰਸ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਅਤੇ ਗਲਤ ਸੰਰਚਨਾ ਮੁੱਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ। ਇਹ ਸਮੁੱਚੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। (ਕੁਝ ਜਟਿਲਤਾ ਵਿੱਚ ਵਾਧਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੰਰਚਨਾ ਵਿੱਚ ਹੈ, ਪਰ ਇਹ ਸੁਰੱਖਿਆ ਪ੍ਰਤੀ ਇੱਕ ਸੁਚੇਤ ਵਪਾਰ ਹੈ।) ਆਮ ਸੰਰਚਨਾ ਵਿੱਚ ਵਾਪਸ ਆਉਣਾ ਬਹੁਤ ਸਿੱਧਾ ਹੈ - ਸਿਰਫ਼ ਗੁੰਮ ਹੋਏ ਟੁਕੜਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨਾ ਅਤੇ ਵਾਧੂ ਟੁਕੜਿਆਂ ਦੇ ਲਾਗੂ ਕਰਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਕੁਝ ਸਮੇਂ ਲਈ ਮੁਲਤਵੀ ਕਰਨਾ ਆਸਾਨ ਹੈ।
ਸੰਸਕਰਣ ਸੰਰਚਨਾ। ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਉਸੇ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ, ਨਤੀਜੇ ਵਜੋਂ ਸਾਨੂੰ ਵਿਲੱਖਣ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਇੱਕ ਆਰਟੀਫੈਕਟ ਮਿਲਦਾ ਹੈ। ਇਹ ਸਾਨੂੰ ਲੋੜ ਪੈਣ 'ਤੇ ਸੰਰਚਨਾ ਨੂੰ ਵਾਪਸ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ ਇੱਕ ਸੰਰਚਨਾ ਵੀ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਵਰਤੀ ਗਈ ਸੀ ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗੀ। ਸਥਿਰ ਸੰਰਚਨਾ ਵਿਤਰਿਤ ਸਿਸਟਮ ਦੀ ਪੂਰਵ ਅਨੁਮਾਨ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ। ਸੰਰਚਨਾ ਕੰਪਾਈਲ ਸਮੇਂ 'ਤੇ ਫਿਕਸ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਤਪਾਦਨ ਸਿਸਟਮ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਛੇੜਛਾੜ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।
ਮਾਡਿਊਲਰਿਟੀ। ਪ੍ਰਸਤਾਵਿਤ ਫਰੇਮਵਰਕ ਮਾਡਿਊਲਰ ਹੈ ਅਤੇ ਮੌਡਿਊਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ
ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ (ਸੈੱਟਅੱਪ/ਲੇਆਉਟ) ਦਾ ਸਮਰਥਨ ਕਰੋ। ਖਾਸ ਤੌਰ 'ਤੇ, ਇੱਕ ਛੋਟੇ ਪੈਮਾਨੇ ਦਾ ਸਿੰਗਲ ਨੋਡ ਲੇਆਉਟ ਅਤੇ ਇੱਕ ਵੱਡੇ ਪੱਧਰ ਦੀ ਮਲਟੀ ਨੋਡ ਸੈਟਿੰਗ ਹੋਣਾ ਸੰਭਵ ਹੈ। ਕਈ ਉਤਪਾਦਨ ਲੇਆਉਟ ਹੋਣਾ ਉਚਿਤ ਹੈ।
ਟੈਸਟਿੰਗ. ਪਰੀਖਣ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਕੋਈ ਇੱਕ ਨਕਲੀ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਕਿਸਮ ਦੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਨਿਰਭਰਤਾ ਵਜੋਂ ਵਰਤ ਸਕਦਾ ਹੈ। ਮੌਕਸ ਦੁਆਰਾ ਬਦਲੇ ਗਏ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੇ ਨਾਲ ਕੁਝ ਵੱਖ-ਵੱਖ ਟੈਸਟਿੰਗ ਲੇਆਉਟ ਇੱਕੋ ਸਮੇਂ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ।
ਏਕੀਕਰਣ ਟੈਸਟਿੰਗ. ਕਈ ਵਾਰ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਏਕੀਕਰਣ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਪੂਰੀ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਿਸਟਮ ਦੀ ਸੁਰੱਖਿਅਤ ਸੰਰਚਨਾ ਟਾਈਪ ਕਰਨ ਲਈ ਵਰਣਿਤ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸਾਰੇ ਵੰਡੇ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਣਯੋਗ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਸਰਵਰ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹਾਂ। ਸਥਿਤੀ ਦੀ ਨਕਲ ਕਰਨਾ ਆਸਾਨ ਹੈ
ਜਦੋਂ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਪਲਬਧ ਨਹੀਂ ਹੋ ਜਾਂਦੀ ਹੈ।

ਨੁਕਸਾਨ

ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਪਹੁੰਚ "ਆਮ" ਸੰਰਚਨਾ ਤੋਂ ਵੱਖਰੀ ਹੈ ਅਤੇ ਇਹ ਸਾਰੀਆਂ ਲੋੜਾਂ ਦੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਥੇ ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਦੇ ਕੁਝ ਨੁਕਸਾਨ ਹਨ:

ਸਥਿਰ ਸੰਰਚਨਾ। ਇਹ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਾਰੇ ਸੁਰੱਖਿਆ ਉਪਾਵਾਂ ਨੂੰ ਛੱਡ ਕੇ ਉਤਪਾਦਨ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਜਲਦੀ ਠੀਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ ਇਸ ਨੂੰ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦਾ ਹੈ. ਸੰਰਚਨਾ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸੰਕਲਨ ਅਤੇ ਮੁੜ ਤੈਨਾਤੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਅਤੇ ਬੋਝ ਦੋਵੇਂ ਹੈ।
ਸੰਰਚਨਾ ਪੀੜ੍ਹੀ. ਜਦੋਂ ਸੰਰਚਨਾ ਕੁਝ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਇਸ ਪਹੁੰਚ ਲਈ ਬਾਅਦ ਦੇ ਸੰਕਲਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਜੋ ਬਦਲੇ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ)। ਇਸ ਨੂੰ ਬਿਲਡ ਸਿਸਟਮ ਵਿੱਚ ਇਸ ਵਾਧੂ ਪੜਾਅ ਨੂੰ ਜੋੜਨ ਲਈ ਵਾਧੂ ਜਤਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਯੰਤਰ। ਅੱਜ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਹਨ ਜੋ ਟੈਕਸਟ-ਅਧਾਰਿਤ ਸੰਰਚਨਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਓਹਨਾਂ ਚੋਂ ਕੁਝ
ਜਦੋਂ ਸੰਰਚਨਾ ਕੰਪਾਇਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਲਾਗੂ ਨਹੀਂ ਹੋਵੇਗਾ।
ਮਾਨਸਿਕਤਾ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੈ। ਡਿਵੈਲਪਰ ਅਤੇ DevOps ਟੈਕਸਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ ਤੋਂ ਜਾਣੂ ਹਨ। ਸੰਰਚਨਾ ਕੰਪਾਇਲ ਕਰਨ ਦਾ ਵਿਚਾਰ ਉਹਨਾਂ ਨੂੰ ਅਜੀਬ ਲੱਗ ਸਕਦਾ ਹੈ।
ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਲਾਗੂ ਕੀਤੇ ਗਏ ਉਦਾਹਰਣ ਦੀਆਂ ਕੁਝ ਸੀਮਾਵਾਂ ਹਨ:

ਜੇਕਰ ਅਸੀਂ ਵਾਧੂ ਸੰਰਚਨਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ ਜਿਸਦੀ ਨੋਡ ਲਾਗੂਕਰਨ ਦੁਆਰਾ ਮੰਗ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਾਂ ਕੰਪਾਈਲਰ ਗੈਰਹਾਜ਼ਰ ਲਾਗੂਕਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ HList ਜਾਂ ADTs (ਕੇਸ ਕਲਾਸਾਂ) ਗੁਣਾਂ ਅਤੇ ਕੇਕ ਪੈਟਰਨ ਦੀ ਬਜਾਏ ਨੋਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਲਈ।
ਸਾਨੂੰ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਕੁਝ ਬੋਇਲਰਪਲੇਟ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ: (package, import, object ਘੋਸ਼ਣਾਵਾਂ;
override defਦੇ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਦੇ ਡਿਫੌਲਟ ਮੁੱਲ ਹਨ)। ਇਹ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ DSL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਸਮਾਨ ਨੋਡਾਂ ਦੇ ਕਲੱਸਟਰਾਂ ਦੀ ਗਤੀਸ਼ੀਲ ਪੁਨਰ-ਸੰਰਚਨਾ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

ਸਿੱਟਾ

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਕਿਸਮ ਦੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਸਿੱਧੇ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕਰਨ ਦੇ ਵਿਚਾਰ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਹੈ। ਪਹੁੰਚ ਨੂੰ xml- ਅਤੇ ਹੋਰ ਟੈਕਸਟ-ਅਧਾਰਿਤ ਸੰਰਚਨਾਵਾਂ ਦੇ ਬਦਲ ਵਜੋਂ ਕਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਦੇ ਬਾਵਜੂਦ ਕਿ ਸਾਡੀ ਉਦਾਹਰਨ Scala ਵਿੱਚ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ, ਇਸ ਦਾ ਅਨੁਵਾਦ ਹੋਰ ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਭਾਸ਼ਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਕੋਟਲਿਨ, ਸੀ#, ਸਵਿਫਟ, ਆਦਿ) ਵਿੱਚ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ ਇੱਕ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇਸ ਪਹੁੰਚ ਨੂੰ ਅਜ਼ਮਾ ਸਕਦਾ ਹੈ ਅਤੇ, ਜੇਕਰ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਪੁਰਾਣੇ ਢੰਗ ਨਾਲ ਬਦਲੋ।

ਬੇਸ਼ੱਕ, ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ ਲਈ ਉੱਚ ਗੁਣਵੱਤਾ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਬਦਲੇ ਵਿੱਚ ਇਹ ਬਰਾਬਰ ਉੱਚ ਗੁਣਵੱਤਾ ਮਜ਼ਬੂਤ ਸੰਰਚਨਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ.

ਇਸ ਪਹੁੰਚ ਨੂੰ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨ ਲਈ ਮੈਕਰੋ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਕਾਰੋਬਾਰ-ਤਰਕ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਦੀ ਅਸਫਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਕੰਪਾਈਲ ਸਮੇਂ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ DSL ਨੂੰ ਇੱਕ ਡੋਮੇਨ-ਉਪਭੋਗਤਾ-ਅਨੁਕੂਲ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਨਾ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਆਟੋਮੈਟਿਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਐਡਜਸਟਮੈਂਟਸ ਦੇ ਨਾਲ ਗਤੀਸ਼ੀਲ ਸਰੋਤ ਪ੍ਰਬੰਧਨ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਅਸੀਂ ਕਲੱਸਟਰ ਨੋਡਸ ਦੀ ਸੰਖਿਆ ਨੂੰ ਐਡਜਸਟ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਚਾਹ ਸਕਦੇ ਹਾਂ (1) ਨੋਡਸ ਨੂੰ ਥੋੜ੍ਹਾ ਸੋਧਿਆ ਹੋਇਆ ਸੰਰਚਨਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ; (2) ਨਵੇਂ ਨੋਡ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਲੱਸਟਰ ਮੈਨੇਜਰ।

ਧੰਨਵਾਦ

ਮੈਂ ਇਸ ਪੋਸਟ ਦੇ ਡਰਾਫਟ 'ਤੇ ਪ੍ਰੇਰਣਾਦਾਇਕ ਫੀਡਬੈਕ ਦੇਣ ਲਈ ਐਂਡਰੀ ਸਕਸੋਨੋਵ, ਪਾਵੇਲ ਪੋਪੋਵ, ਐਂਟੋਨ ਨੇਹਾਏਵ ਦਾ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹਾਂਗਾ ਜਿਸ ਨੇ ਇਸ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਮਦਦ ਕੀਤੀ।

ਸਰੋਤ: www.habr.com

ਇੱਕ ਵੰਡੇ ਸਿਸਟਮ ਦੀ ਕੰਪਾਇਲ ਕਰਨ ਯੋਗ ਸੰਰਚਨਾ