ਕੰਪਾਇਲਡ ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮ ਕੌਂਫਿਗਰੇਸ਼ਨ

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

(ਅੰਗਰੇਜ਼ੀ)

ਜਾਣ ਪਛਾਣ

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

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

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

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

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

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

ਸੰਕਲਿਤ ਸੰਰਚਨਾ

ਇਹ ਭਾਗ ਇੱਕ ਸਥਿਰ ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਦੀ ਉਦਾਹਰਨ ਦਿੰਦਾ ਹੈ। ਦੋ ਸਧਾਰਨ ਸੇਵਾਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ - ਈਕੋ ਸਰਵਿਸ ਅਤੇ ਈਕੋ ਸਰਵਿਸ ਕਲਾਇੰਟ। ਇਹਨਾਂ ਦੋ ਸੇਵਾਵਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਦੋ ਸਿਸਟਮ ਵਿਕਲਪ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ। ਇੱਕ ਵਿਕਲਪ ਵਿੱਚ, ਦੋਵੇਂ ਸੇਵਾਵਾਂ ਇੱਕੋ ਨੋਡ 'ਤੇ ਸਥਿਤ ਹਨ, ਦੂਜੇ ਵਿਕਲਪ ਵਿੱਚ - ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ।

ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੰਡੇ ਸਿਸਟਮ ਵਿੱਚ ਕਈ ਨੋਡ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨੋਡਾਂ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹੋ NodeId:

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]]

ਸ਼ੁੱਧ ਕਿਸਮ

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

HTTP (REST) ​​ਪ੍ਰੋਟੋਕੋਲ ਲਈ, ਪੋਰਟ ਨੰਬਰ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਸੇਵਾ ਲਈ ਮਾਰਗ ਦੀ ਵੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ:

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

ਫੈਂਟਮ ਕਿਸਮਾਂ

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

ਇੱਕ ਆਮ ਪ੍ਰੋਟੋਕੋਲ Json ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਦੇ ਨਾਲ REST API ਹੈ:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

ਜਿੱਥੇ RequestMessage - ਬੇਨਤੀ ਦੀ ਕਿਸਮ, ResponseMessage - ਜਵਾਬ ਦੀ ਕਿਸਮ.
ਬੇਸ਼ੱਕ, ਅਸੀਂ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਵਰਣਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਵਰਣਨ ਦੀ ਸ਼ੁੱਧਤਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਇਸ ਪੋਸਟ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ, ਅਸੀਂ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਇੱਕ ਸਰਲ ਰੂਪ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ਇੱਥੇ ਬੇਨਤੀ url ਨਾਲ ਜੋੜੀ ਗਈ ਇੱਕ ਸਤਰ ਹੈ ਅਤੇ ਜਵਾਬ HTTP ਜਵਾਬ ਦੇ ਮੁੱਖ ਭਾਗ ਵਿੱਚ ਵਾਪਸ ਕੀਤੀ ਗਈ ਸਤਰ ਹੈ।

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

ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਨਿਰਭਰਤਾ ਨੂੰ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਪੋਰਟਾਂ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹਨ EndPointਦੇ ਹੋਰ ਨੋਡਸ:

  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)
  }

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

ਕਲਾਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਅਸੀਂ ਈਕੋ ਸੇਵਾ 'ਤੇ ਨਿਰਭਰਤਾ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹਾਂ:

  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 - ਇੱਕ ਪ੍ਰਭਾਵ ਕਿਸਮ ਦੀ ਕਲਾਸ ਜੋ ਤੁਹਾਨੂੰ ਵਿਅਕਤੀਗਤ ਪ੍ਰਭਾਵਾਂ (ਲਗਭਗ ਇੱਕ ਮੋਨਾਡ) ਨੂੰ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਇਸਨੂੰ ਵਰਤਣਾ ਬਿਹਤਰ ਲੱਗਦਾ ਹੈ Monad/ConcurrentEffect.

ਇਸ ਫੰਕਸ਼ਨ ਦਸਤਖਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਸੀਂ ਕਈ ਸੇਵਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸੇਵਾ ਜੋ ਕੁਝ ਨਹੀਂ ਕਰਦੀ:

  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
}

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਅਸੀਂ ਇਸ ਨੋਡ ਲਈ ਲੋੜੀਂਦੀ ਸੰਰਚਨਾ ਦੀ ਸਹੀ ਕਿਸਮ ਨਿਰਧਾਰਤ ਕਰ ਰਹੇ ਹਾਂ। ਜੇਕਰ ਅਸੀਂ ਕਿਸੇ ਖਾਸ ਸੇਵਾ ਲਈ ਲੋੜੀਂਦੀ ਸੰਰਚਨਾ ਕਿਸਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਭੁੱਲ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਸੰਕਲਨ ਗਲਤੀ ਹੋਵੇਗੀ। ਨਾਲ ਹੀ, ਅਸੀਂ ਇੱਕ ਨੋਡ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵਾਂਗੇ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਸਾਰੇ ਲੋੜੀਂਦੇ ਡੇਟਾ ਦੇ ਨਾਲ ਢੁਕਵੀਂ ਕਿਸਮ ਦੀ ਕੋਈ ਵਸਤੂ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

ਹੋਸਟ ਨਾਮ ਰੈਜ਼ੋਲਿਊਸ਼ਨ

ਇੱਕ ਰਿਮੋਟ ਹੋਸਟ ਨਾਲ ਜੁੜਨ ਲਈ, ਸਾਨੂੰ ਇੱਕ ਅਸਲੀ IP ਐਡਰੈੱਸ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਪਤਾ ਬਾਕੀ ਸੰਰਚਨਾ ਨਾਲੋਂ ਬਾਅਦ ਵਿੱਚ ਜਾਣਿਆ ਜਾਵੇਗਾ। ਇਸ ਲਈ ਸਾਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਨੋਡ ID ਨੂੰ ਇੱਕ ਪਤੇ 'ਤੇ ਮੈਪ ਕਰਦਾ ਹੈ:

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

ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ:

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

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

ਅੱਗੇ, ਅਸੀਂ ਵੰਡੇ ਸਿਸਟਮ ਲਈ ਦੋ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ:

1. ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਨੋਡ 'ਤੇ ਰੱਖਣਾ।
2. ਅਤੇ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਈਕੋ ਸੇਵਾ ਅਤੇ ਈਕੋ ਕਲਾਇੰਟ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰ ਰਿਹਾ ਹੈ।

ਲਈ ਸੰਰਚਨਾ ਇੱਕ ਨੋਡ:

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

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 ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਖਤਮ ਕਰੋ. (Ctrl-C ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁਕਤ ਕਰਦਾ ਹੈ।)

ਸੰਰਚਨਾ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੇ ਗੁਣਾਂ ਦਾ ਇੱਕੋ ਸੈੱਟ ਇੱਕ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਦੋ ਵੱਖਰੇ ਨੋਡ:

ਦੋ ਨੋਡ ਸੰਰਚਨਾ

  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"
  }

ਮਹੱਤਵਪੂਰਨ! ਧਿਆਨ ਦਿਓ ਕਿ ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ। ਅਸੀਂ ਇੱਕ ਨੋਡ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਨੋਡ ਦੀ ਨਿਰਭਰਤਾ ਵਿਧੀ ਦੇ ਲਾਗੂ ਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ। ਕੰਪਾਈਲਰ ਦੁਆਰਾ ਨਿਰਭਰਤਾ ਕਿਸਮ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਕਿਸਮ ਸ਼ਾਮਿਲ ਹੈ। ਜਦੋਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਿਰਭਰਤਾ ਵਿੱਚ ਸਹੀ ਟੀਚਾ ਨੋਡ ID ਸ਼ਾਮਲ ਹੋਵੇਗਾ। ਇਸ ਸਕੀਮ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਪੋਰਟ ਨੰਬਰ ਨੂੰ ਬਿਲਕੁਲ ਇੱਕ ਵਾਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਹਮੇਸ਼ਾ ਸਹੀ ਪੋਰਟ ਦਾ ਹਵਾਲਾ ਦੇਣ ਦੀ ਗਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਦੋ ਸਿਸਟਮ ਨੋਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਇਸ ਸੰਰਚਨਾ ਲਈ, ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਉਹੀ ਸੇਵਾ ਲਾਗੂਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਫਰਕ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਹੁਣ ਸਾਡੇ ਕੋਲ ਦੋ ਵਸਤੂਆਂ ਹਨ ਜੋ ਸੇਵਾਵਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੈੱਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ:

  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'om, ਅਤੇ ਕਲਾਇੰਟ ਨੋਡ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਸੀ.ਐਮ. ਲਾਂਚਰ ਐਪ.

ਆਮ ਵਿਕਾਸ ਦੀ ਪ੍ਰਕਿਰਿਆ

ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਸੰਰਚਨਾ ਪਹੁੰਚ ਸਮੁੱਚੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।

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

ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਤਬਦੀਲੀ ਕੋਡ ਤਬਦੀਲੀ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਇਸ ਲਈ, ਹਰੇਕ
ਤਬਦੀਲੀ ਨੂੰ ਆਮ ਗੁਣਵੱਤਾ ਭਰੋਸਾ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਜਾਵੇਗਾ:

ਬੱਗ ਟਰੈਕਰ ਵਿੱਚ ਟਿਕਟ -> PR -> ਸਮੀਖਿਆ -> ਸੰਬੰਧਿਤ ਸ਼ਾਖਾਵਾਂ ਨਾਲ ਮਿਲਾਓ ->
ਏਕੀਕਰਣ -> ਤੈਨਾਤੀ

ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਮੁੱਖ ਨਤੀਜੇ ਹਨ:

1. ਵਿਤਰਿਤ ਸਿਸਟਮ ਦੇ ਸਾਰੇ ਨੋਡਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਇਕਸਾਰ ਹੋਵੇਗੀ। ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਸਾਰੇ ਨੋਡ ਇੱਕ ਸਰੋਤ ਤੋਂ ਇੱਕੋ ਜਿਹੀ ਸੰਰਚਨਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ.

2. ਸਿਰਫ ਇੱਕ ਨੋਡ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਇਸ ਲਈ, "ਸੰਰਚਨਾ ਵਹਿਣ" ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ।

3. ਸੰਰਚਨਾ ਵਿੱਚ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

4. ਜ਼ਿਆਦਾਤਰ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਸਮੁੱਚੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਹੋਣਗੀਆਂ ਅਤੇ ਸਮੀਖਿਆ ਦੇ ਅਧੀਨ ਹੋਣਗੀਆਂ।

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

ਸੰਭਵ ਭਿੰਨਤਾਵਾਂ

ਆਉ ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਦੀ ਤੁਲਨਾ ਕੁਝ ਆਮ ਵਿਕਲਪਾਂ ਨਾਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

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

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

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

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

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

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

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

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

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

ਲਾਭ ਅਤੇ ਹਾਨੀਆਂ

ਮੈਂ ਪ੍ਰਸਤਾਵਿਤ ਤਕਨਾਲੋਜੀ ਦੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹਾਂਗਾ।

ਲਾਭ

ਹੇਠਾਂ ਇੱਕ ਕੰਪਾਈਲਡ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਸਿਸਟਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀਆਂ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ:

1. ਸਥਿਰ ਸੰਰਚਨਾ ਜਾਂਚ। ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਹਾਇਕ ਹੈ
   ਸੰਰਚਨਾ ਸਹੀ ਹੈ।
2. ਅਮੀਰ ਸੰਰਚਨਾ ਭਾਸ਼ਾ. ਆਮ ਤੌਰ 'ਤੇ, ਹੋਰ ਸੰਰਚਨਾ ਵਿਧੀਆਂ ਵੱਧ ਤੋਂ ਵੱਧ ਸਟ੍ਰਿੰਗ ਵੇਰੀਏਬਲ ਬਦਲ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੀਆਂ ਹਨ। Scala ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਭਾਸ਼ਾ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ ਅਸੀਂ ਵਰਤ ਸਕਦੇ ਹਾਂ
   ਡਿਫਾਲਟ ਮੁੱਲਾਂ ਲਈ ਗੁਣ, ਸਮੂਹ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਆਬਜੈਕਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਐਨਕਲੋਜ਼ਿੰਗ ਸਕੋਪ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਵਾਰ ਘੋਸ਼ਿਤ ਕੀਤੇ ਵਾਲਾਂ (DRY) ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੇ ਹਾਂ। ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਕਲਾਸ ਨੂੰ ਸਿੱਧੇ ਸੰਰਚਨਾ ਦੇ ਅੰਦਰ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ (Seq, Map, ਕਸਟਮ ਕਲਾਸਾਂ)।
3. DSL. Scala ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ ਜੋ ਇੱਕ DSL ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਫਾਇਦਾ ਉਠਾਉਣਾ ਅਤੇ ਇੱਕ ਸੰਰਚਨਾ ਭਾਸ਼ਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸੰਭਵ ਹੈ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਟੀਚੇ ਸਮੂਹ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਤਾਂ ਜੋ ਸੰਰਚਨਾ ਘੱਟੋ ਘੱਟ ਡੋਮੇਨ ਮਾਹਰਾਂ ਦੁਆਰਾ ਪੜ੍ਹਨਯੋਗ ਹੋਵੇ। ਮਾਹਰ, ਉਦਾਹਰਨ ਲਈ, ਸੰਰਚਨਾ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ।
4. ਨੋਡਾਂ ਵਿਚਕਾਰ ਇਕਸਾਰਤਾ ਅਤੇ ਸਮਕਾਲੀ। ਇੱਕ ਸਿੰਗਲ ਬਿੰਦੂ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਇੱਕ ਪੂਰੇ ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮ ਦੀ ਸੰਰਚਨਾ ਹੋਣ ਦਾ ਇੱਕ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਸਾਰੇ ਮੁੱਲਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਘੋਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਜਿੱਥੇ ਵੀ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਦੁਬਾਰਾ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਪੋਰਟਾਂ ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਨ ਲਈ ਫੈਂਟਮ ਕਿਸਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਨੋਡ ਸਾਰੀਆਂ ਸਹੀ ਸਿਸਟਮ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਅਨੁਕੂਲ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤ ਰਹੇ ਹਨ। ਨੋਡਾਂ ਵਿਚਕਾਰ ਸਪੱਸ਼ਟ ਲਾਜ਼ਮੀ ਨਿਰਭਰਤਾ ਹੋਣ ਨਾਲ ਇਹ ਯਕੀਨੀ ਹੁੰਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ।
5. ਉੱਚ ਗੁਣਵੱਤਾ ਵਿੱਚ ਬਦਲਾਅ. ਇੱਕ ਸਾਂਝੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਰਚਨਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਨਾਲ ਸੰਰਚਨਾ ਲਈ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੇ ਮਿਆਰਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਵੀ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।
6. ਸਮਕਾਲੀ ਸੰਰਚਨਾ ਅੱਪਡੇਟ. ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਾਅਦ ਆਟੋਮੈਟਿਕ ਸਿਸਟਮ ਤੈਨਾਤੀ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਾਰੇ ਨੋਡ ਅੱਪਡੇਟ ਕੀਤੇ ਗਏ ਹਨ।
7. ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ. ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਾਰਸਿੰਗ, ਸੰਰਚਨਾ ਜਾਂਚ, ਜਾਂ ਗਲਤ ਮੁੱਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ. (ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ ਦੇਖੀ ਗਈ ਕੁਝ ਸੰਰਚਨਾ ਜਟਿਲਤਾ ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਰਫ ਇੱਕ ਸੁਚੇਤ ਫੈਸਲਾ ਹੈ ਜੋ ਕਿ ਵਧੇਰੇ ਕਿਸਮ ਦੀ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਇੱਛਾ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਹੈ।) ਆਮ ਸੰਰਚਨਾ ਤੇ ਵਾਪਸ ਜਾਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ - ਬਸ ਗੁੰਮ ਨੂੰ ਲਾਗੂ ਕਰੋ ਹਿੱਸੇ. ਇਸ ਲਈ, ਤੁਸੀਂ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, ਬੇਲੋੜੇ ਹਿੱਸਿਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨੂੰ ਉਦੋਂ ਤੱਕ ਮੁਲਤਵੀ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਇਹ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ.
8. ਪ੍ਰਮਾਣਿਤ ਸੰਰਚਨਾ। ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਕਿਸੇ ਹੋਰ ਤਬਦੀਲੀਆਂ ਦੀ ਆਮ ਕਿਸਮਤ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸਾਨੂੰ ਜੋ ਆਉਟਪੁੱਟ ਮਿਲਦਾ ਹੈ ਉਹ ਇੱਕ ਵਿਲੱਖਣ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਇੱਕ ਕਲਾਤਮਕ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਾਨੂੰ, ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੰਰਚਨਾ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਦੀ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਸਿਸਟਮ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗਾ। ਇੱਕ ਸਥਿਰ ਸੰਰਚਨਾ ਇੱਕ ਵੰਡੇ ਸਿਸਟਮ ਦੀ ਭਵਿੱਖਬਾਣੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ। ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਨੂੰ ਸੰਕਲਨ ਦੇ ਪੜਾਅ 'ਤੇ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਜਾਅਲੀ ਬਣਾਉਣਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ।
9. ਮਾਡਿਊਲਰਿਟੀ। ਪ੍ਰਸਤਾਵਿਤ ਫਰੇਮਵਰਕ ਮਾਡਿਊਲਰ ਹੈ ਅਤੇ ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਮੋਡਿਊਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਰੂਪ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਨੋਡ 'ਤੇ ਚਲਾਉਣ ਲਈ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਕਈ ਨੋਡਾਂ 'ਤੇ ਚਲਾਉਣ ਲਈ ਸੰਰਚਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਸਿਸਟਮ ਦੇ ਉਤਪਾਦਨ ਉਦਾਹਰਨਾਂ ਲਈ ਕਈ ਸੰਰਚਨਾਵਾਂ ਬਣਾ ਸਕਦੇ ਹੋ।
10. ਟੈਸਟਿੰਗ. ਵਿਅਕਤੀਗਤ ਸੇਵਾਵਾਂ ਨੂੰ ਨਕਲੀ ਵਸਤੂਆਂ ਨਾਲ ਬਦਲ ਕੇ, ਤੁਸੀਂ ਸਿਸਟਮ ਦੇ ਕਈ ਸੰਸਕਰਣ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਜਾਂਚ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹਨ।
11. ਏਕੀਕਰਣ ਟੈਸਟਿੰਗ. ਪੂਰੇ ਵਿਤਰਿਤ ਸਿਸਟਮ ਲਈ ਇੱਕ ਸਿੰਗਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੋਣ ਨਾਲ ਏਕੀਕਰਣ ਟੈਸਟਿੰਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਇੱਕ ਨਿਯੰਤਰਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਾਰੇ ਭਾਗਾਂ ਨੂੰ ਚਲਾਉਣਾ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਨਕਲ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਅਜਿਹੀ ਸਥਿਤੀ ਜਿੱਥੇ ਕੁਝ ਨੋਡ ਪਹੁੰਚਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ।

ਨੁਕਸਾਨ ਅਤੇ ਸੀਮਾਵਾਂ

ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਹੋਰ ਸੰਰਚਨਾ ਪਹੁੰਚਾਂ ਤੋਂ ਵੱਖਰੀ ਹੈ ਅਤੇ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਢੁਕਵੀਂ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਹੇਠਾਂ ਕੁਝ ਨੁਕਸਾਨ ਹਨ:

1. ਸਥਿਰ ਸੰਰਚਨਾ। ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਾਰੇ ਸੁਰੱਖਿਆ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਛੱਡ ਕੇ. ਇਸ ਪਹੁੰਚ ਨਾਲ ਇਹ ਹੋਰ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ. ਬਹੁਤ ਘੱਟ ਤੋਂ ਘੱਟ, ਸੰਕਲਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਤੈਨਾਤੀ ਦੀ ਅਜੇ ਵੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਹ ਪਹੁੰਚ ਦੀ ਇੱਕ ਲਾਭਦਾਇਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਅਤੇ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕ ਨੁਕਸਾਨ ਹੈ।
2. ਸੰਰਚਨਾ ਪੀੜ੍ਹੀ. ਜੇਕਰ ਸੰਰਚਨਾ ਫਾਇਲ ਇੱਕ ਆਟੋਮੈਟਿਕ ਟੂਲ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਬਿਲਡ ਸਕ੍ਰਿਪਟ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਲਈ ਵਾਧੂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
3. ਸੰਦ। ਵਰਤਮਾਨ ਵਿੱਚ, ਸੰਰਚਨਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਸਹੂਲਤਾਂ ਅਤੇ ਤਕਨੀਕਾਂ ਟੈਕਸਟ ਫਾਈਲਾਂ 'ਤੇ ਅਧਾਰਤ ਹਨ। ਅਜਿਹੀਆਂ ਸਾਰੀਆਂ ਉਪਯੋਗਤਾਵਾਂ/ਤਕਨੀਕਾਂ ਇੱਕ ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੋਣਗੀਆਂ।
4. ਰਵੱਈਏ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੈ। ਡਿਵੈਲਪਰ ਅਤੇ DevOps ਟੈਕਸਟ ਫਾਈਲਾਂ ਦੇ ਆਦੀ ਹਨ। ਇੱਕ ਸੰਰਚਨਾ ਕੰਪਾਇਲ ਕਰਨ ਦਾ ਬਹੁਤ ਹੀ ਵਿਚਾਰ ਥੋੜਾ ਅਚਾਨਕ ਅਤੇ ਅਸਾਧਾਰਨ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਅਸਵੀਕਾਰ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
5. ਇੱਕ ਉੱਚ ਗੁਣਵੱਤਾ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਹੈ. ਕੰਪਾਇਲ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ ਆਰਾਮ ਨਾਲ ਵਰਤਣ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ (CI/CD) ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਪੂਰਾ ਆਟੋਮੇਸ਼ਨ ਜ਼ਰੂਰੀ ਹੈ। ਨਹੀਂ ਤਾਂ ਇਹ ਕਾਫ਼ੀ ਅਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ.

ਆਉ ਅਸੀਂ ਵਿਚਾਰੀ ਗਈ ਉਦਾਹਰਣ ਦੀਆਂ ਕਈ ਸੀਮਾਵਾਂ 'ਤੇ ਵੀ ਧਿਆਨ ਦੇਈਏ ਜੋ ਇੱਕ ਸੰਕਲਿਤ ਸੰਰਚਨਾ ਦੇ ਵਿਚਾਰ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ:

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

ਸਿੱਟਾ

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

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

ਵਿਚਾਰੀ ਪਹੁੰਚ ਦਾ ਵਿਸਤਾਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

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

ਪ੍ਰਵਾਨਗੀ

ਮੈਂ ਡਰਾਫਟ ਲੇਖ ਦੀ ਰਚਨਾਤਮਕ ਆਲੋਚਨਾ ਲਈ ਆਂਦਰੇਈ ਸਕਸੋਨੋਵ, ਪਾਵੇਲ ਪੋਪੋਵ ਅਤੇ ਐਂਟੋਨ ਨੇਖਾਏਵ ਦਾ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਸਰੋਤ: www.habr.com