વિતરિત સિસ્ટમનું સંકલન કરી શકાય તેવું રૂપરેખાંકન

આ પોસ્ટમાં અમે વિતરિત સિસ્ટમના રૂપરેખાંકન સાથે વ્યવહાર કરવાની એક રસપ્રદ રીત શેર કરવા માંગીએ છીએ.
રૂપરેખાંકન સીધું જ સ્કેલા ભાષામાં સુરક્ષિત રીતે પ્રદર્શિત થાય છે. એક ઉદાહરણ અમલીકરણ વિગતોમાં વર્ણવેલ છે. સમગ્ર વિકાસ પ્રક્રિયા પર પ્રભાવ સહિત પ્રસ્તાવના વિવિધ પાસાઓની ચર્ચા કરવામાં આવી છે.

(રશિયન)

પરિચય

મજબૂત વિતરિત સિસ્ટમો બનાવવા માટે તમામ નોડ્સ પર યોગ્ય અને સુસંગત રૂપરેખાંકનનો ઉપયોગ જરૂરી છે. એક લાક્ષણિક ઉકેલ એ છે કે ટેક્ષ્ચ્યુઅલ ડિપ્લોયમેન્ટ વર્ણન (ટેરાફોર્મ, એન્સિબલ અથવા કંઈક એકસરખું) અને આપમેળે જનરેટ થયેલ રૂપરેખાંકન ફાઈલો (ઘણીવાર — દરેક નોડ/રોલ માટે સમર્પિત) નો ઉપયોગ કરવો. અમે દરેક કોમ્યુનિકેટિંગ નોડ્સ પર સમાન સંસ્કરણોના સમાન પ્રોટોકોલનો ઉપયોગ કરવા માંગીએ છીએ (અન્યથા અમે અસંગતતા સમસ્યાઓનો અનુભવ કરીશું). 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 જેનો વર્ગમાં ઉપયોગ થતો નથી. તે કહેવાતા છે ફેન્ટમ પ્રકાર. રનટાઇમ વખતે આપણને પ્રોટોકોલ ઓળખકર્તાના ઉદાહરણની ભાગ્યે જ જરૂર પડે છે, તેથી જ અમે તેને સંગ્રહિત કરતા નથી. સંકલન દરમિયાન આ ફેન્ટમ પ્રકાર વધારાની સલામતી આપે છે. અમે ખોટા પ્રોટોકોલ સાથે પોર્ટ પસાર કરી શકતા નથી.

સૌથી વધુ ઉપયોગમાં લેવાતા પ્રોટોકોલ્સમાંનો એક 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. બે નોડ લેઆઉટ, જ્યાં સેવા અને ક્લાયંટ અલગ-અલગ નોડ પર હોય છે.

એ માટે રૂપરેખાંકન એક નોડ લેઆઉટ નીચે મુજબ છે:

સિંગલ નોડ રૂપરેખાંકન

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. રૂપરેખાંકનની સમૃદ્ધ ભાષા. સામાન્ય રીતે અન્ય રૂપરેખાંકન અભિગમો મોટાભાગના ચલ અવેજી સુધી મર્યાદિત હોય છે.
   સ્કેલાનો ઉપયોગ કરીને રૂપરેખાંકનને બહેતર બનાવવા માટે ભાષા સુવિધાઓની વિશાળ શ્રેણીનો ઉપયોગ કરી શકાય છે. દાખલા તરીકે, અમે ડિફૉલ્ટ મૂલ્યો પ્રદાન કરવા માટે લક્ષણોનો ઉપયોગ કરી શકીએ છીએ, વિવિધ અવકાશ સેટ કરવા માટે ઑબ્જેક્ટ્સનો ઉપયોગ કરી શકીએ છીએ, અમે સંદર્ભ લઈ શકીએ છીએ vals બાહ્ય અવકાશ (DRY) માં માત્ર એક જ વાર વ્યાખ્યાયિત થયેલ છે. શાબ્દિક સિક્વન્સ અથવા અમુક વર્ગોના ઉદાહરણોનો ઉપયોગ કરવો શક્ય છે (Seq, Map, વગેરે).
3. ડીએસએલ. સ્કેલા પાસે DSL લેખકો માટે યોગ્ય સમર્થન છે. વ્યક્તિ આ સુવિધાઓનો ઉપયોગ રૂપરેખાંકન ભાષા સ્થાપિત કરવા માટે કરી શકે છે જે વધુ અનુકૂળ અને અંતિમ વપરાશકર્તા મૈત્રીપૂર્ણ હોય, જેથી અંતિમ રૂપરેખાંકન ઓછામાં ઓછું ડોમેન વપરાશકર્તાઓ દ્વારા વાંચી શકાય.
4. સમગ્ર નોડ્સમાં અખંડિતતા અને સુસંગતતા. સમગ્ર વિતરિત પ્રણાલી માટે એક જ જગ્યાએ ગોઠવણી કરવાનો એક ફાયદો એ છે કે તમામ મૂલ્યોને એકવાર સખત રીતે વ્યાખ્યાયિત કરવામાં આવે છે અને પછી તે તમામ સ્થળોએ પુનઃઉપયોગ કરવામાં આવે છે જ્યાં અમને તેમની જરૂર હોય. સલામત પોર્ટ ઘોષણાઓ પણ ટાઈપ કરો ખાતરી કરો કે તમામ સંભવિત યોગ્ય રૂપરેખાંકનોમાં સિસ્ટમના નોડ્સ સમાન ભાષા બોલશે. નોડ્સ વચ્ચે સ્પષ્ટ અવલંબન છે જે કેટલીક સેવાઓ પ્રદાન કરવાનું ભૂલી જવાનું મુશ્કેલ બનાવે છે.
5. ફેરફારોની ઉચ્ચ ગુણવત્તા. સામાન્ય PR પ્રક્રિયા દ્વારા રૂપરેખાંકન ફેરફારો પસાર કરવાનો એકંદર અભિગમ રૂપરેખાંકનમાં પણ ગુણવત્તાના ઉચ્ચ ધોરણો સ્થાપિત કરે છે.
6. એક સાથે રૂપરેખાંકન ફેરફારો. જ્યારે પણ આપણે રૂપરેખાંકનમાં કોઈ ફેરફાર કરીએ છીએ ત્યારે આપોઆપ જમાવટ ખાતરી કરે છે કે તમામ નોડ્સ અપડેટ થઈ રહ્યાં છે.
7. એપ્લિકેશન સરળીકરણ. એપ્લિકેશનને રૂપરેખાંકન પાર્સ અને માન્ય કરવાની અને ખોટા રૂપરેખાંકન મૂલ્યોને હેન્ડલ કરવાની જરૂર નથી. આ એકંદર એપ્લિકેશનને સરળ બનાવે છે. (કેટલીક જટિલતામાં વધારો રૂપરેખાંકનમાં જ છે, પરંતુ તે સલામતી તરફ સભાન વેપાર છે.) સામાન્ય રૂપરેખાંકન પર પાછા ફરવું ખૂબ જ સરળ છે - ફક્ત ખૂટતા ટુકડાઓ ઉમેરો. સંકલિત રૂપરેખાંકન સાથે પ્રારંભ કરવું અને વધારાના ટુકડાઓના અમલીકરણને પછીના સમયમાં મુલતવી રાખવું સરળ છે.
8. વર્ઝન કરેલ રૂપરેખાંકન. એ હકીકતને કારણે કે રૂપરેખાંકન ફેરફારો સમાન વિકાસ પ્રક્રિયાને અનુસરે છે, પરિણામે અમને અનન્ય સંસ્કરણ સાથે આર્ટિફેક્ટ મળે છે. જો જરૂરી હોય તો તે અમને રૂપરેખાંકનને પાછું સ્વિચ કરવાની મંજૂરી આપે છે. અમે એક રૂપરેખાંકન પણ જમાવી શકીએ છીએ જેનો ઉપયોગ એક વર્ષ પહેલા કરવામાં આવ્યો હતો અને તે બરાબર એ જ રીતે કાર્ય કરશે. સ્થિર રૂપરેખાંકન વિતરિત સિસ્ટમની આગાહી અને વિશ્વસનીયતામાં સુધારો કરે છે. રૂપરેખાંકન કમ્પાઇલ સમયે નિશ્ચિત છે અને ઉત્પાદન સિસ્ટમ પર સરળતાથી ચેડાં કરી શકાતા નથી.
9. મોડ્યુલારિટી. સૂચિત માળખું મોડ્યુલર છે અને મોડ્યુલોને વિવિધ રીતે જોડી શકાય છે
   વિવિધ રૂપરેખાંકનો (સેટઅપ્સ/લેઆઉટ) ને સપોર્ટ કરે છે. ખાસ કરીને, નાના પાયે સિંગલ નોડ લેઆઉટ અને મોટા પાયે મલ્ટી નોડ સેટિંગ શક્ય છે. બહુવિધ ઉત્પાદન લેઆઉટ હોવું વાજબી છે.
10. પરીક્ષણ. પરીક્ષણના હેતુઓ માટે કોઈ એક મોક સેવાનો અમલ કરી શકે છે અને તેનો ઉપયોગ સુરક્ષિત રીતે નિર્ભરતા તરીકે કરી શકે છે. મોક્સ દ્વારા બદલવામાં આવેલા વિવિધ ભાગો સાથેના કેટલાક જુદા જુદા પરીક્ષણ લેઆઉટને એકસાથે જાળવી શકાય છે.
11. એકીકરણ પરીક્ષણ. કેટલીકવાર વિતરિત પ્રણાલીઓમાં એકીકરણ પરીક્ષણો ચલાવવાનું મુશ્કેલ હોય છે. સંપૂર્ણ વિતરિત સિસ્ટમના સુરક્ષિત રૂપરેખાંકનને ટાઈપ કરવા માટે વર્ણવેલ અભિગમનો ઉપયોગ કરીને, અમે તમામ વિતરિત ભાગોને એક જ સર્વર પર નિયંત્રિત રીતે ચલાવી શકીએ છીએ. પરિસ્થિતિનું અનુકરણ કરવું સરળ છે
    જ્યારે એક સેવા અનુપલબ્ધ બને છે.

ગેરફાયદામાં

સંકલિત રૂપરેખાંકન અભિગમ "સામાન્ય" રૂપરેખાંકનથી અલગ છે અને તે બધી જરૂરિયાતોને અનુરૂપ ન હોઈ શકે. સંકલિત રૂપરેખાના કેટલાક ગેરફાયદા અહીં છે:

1. સ્થિર રૂપરેખાંકન. તે બધી એપ્લિકેશનો માટે યોગ્ય ન હોઈ શકે. કેટલાક કિસ્સાઓમાં સલામતીના તમામ પગલાંને બાયપાસ કરીને ઉત્પાદનમાં ગોઠવણીને ઝડપથી ઠીક કરવાની જરૂર છે. આ અભિગમ તેને વધુ મુશ્કેલ બનાવે છે. રૂપરેખાંકનમાં કોઈપણ ફેરફાર કર્યા પછી સંકલન અને પુનઃસ્થાપન જરૂરી છે. આ લક્ષણ અને બોજ બંને છે.
2. રૂપરેખાંકન જનરેશન. જ્યારે રૂપરેખા કેટલાક ઓટોમેશન ટૂલ દ્વારા જનરેટ થાય છે ત્યારે આ અભિગમને અનુગામી સંકલનની જરૂર પડે છે (જે બદલામાં નિષ્ફળ થઈ શકે છે). આ વધારાના પગલાને બિલ્ડ સિસ્ટમમાં એકીકૃત કરવા માટે વધારાના પ્રયત્નોની જરૂર પડી શકે છે.
3. સાધનો. આજે ઉપયોગમાં લેવાતા પુષ્કળ સાધનો છે જે ટેક્સ્ટ-આધારિત રૂપરેખાઓ પર આધાર રાખે છે. અમુક
   જ્યારે રૂપરેખાંકન સંકલિત કરવામાં આવે ત્યારે લાગુ થશે નહીં.
4. માનસિકતામાં પરિવર્તન જરૂરી છે. વિકાસકર્તાઓ અને DevOps ટેક્સ્ટ કન્ફિગરેશન ફાઇલોથી પરિચિત છે. રૂપરેખાંકન કમ્પાઇલ કરવાનો વિચાર તેમને વિચિત્ર લાગી શકે છે.
5. કમ્પાઇલેબલ રૂપરેખાંકનનો પરિચય આપતા પહેલા ઉચ્ચ ગુણવત્તાની સોફ્ટવેર ડેવલપમેન્ટ પ્રક્રિયા જરૂરી છે.

અમલમાં મૂકાયેલ ઉદાહરણની કેટલીક મર્યાદાઓ છે:

1. જો અમે વધારાની રૂપરેખા પ્રદાન કરીએ છીએ જે નોડ અમલીકરણ દ્વારા માંગવામાં આવતી નથી, તો કમ્પાઇલર ગેરહાજર અમલીકરણને શોધવામાં અમને મદદ કરશે નહીં. આનો ઉપયોગ કરીને સંબોધિત કરી શકાય છે HList અથવા લક્ષણો અને કેક પેટર્નને બદલે નોડ રૂપરેખાંકન માટે ADTs (કેસ વર્ગો).
2. અમારે રૂપરેખા ફાઈલમાં કેટલીક બોઈલરપ્લેટ પ્રદાન કરવી પડશે: (package, import, object ઘોષણાઓ
   override defના પરિમાણો માટે કે જેમાં ડિફોલ્ટ મૂલ્યો હોય છે). DSL નો ઉપયોગ કરીને આ આંશિક રીતે સંબોધવામાં આવી શકે છે.
3. આ પોસ્ટમાં અમે સમાન ગાંઠોના ક્લસ્ટરોના ગતિશીલ પુનઃરૂપરેખાંકનને આવરી લેતા નથી.

ઉપસંહાર

આ પોસ્ટમાં અમે રૂપરેખાંકનને સીધા જ સ્ત્રોત કોડમાં સુરક્ષિત રીતે રજૂ કરવાના વિચારની ચર્ચા કરી છે. એક્સએમએલ- અને અન્ય ટેક્સ્ટ-આધારિત રૂપરેખાઓના સ્થાને ઘણા કાર્યક્રમોમાં અભિગમનો ઉપયોગ કરી શકાય છે. તેમ છતાં અમારું ઉદાહરણ સ્કેલામાં લાગુ કરવામાં આવ્યું છે, તે અન્ય કમ્પાઇલેબલ ભાષાઓમાં પણ અનુવાદિત થઈ શકે છે (જેમ કે કોટલિન, સી#, સ્વિફ્ટ, વગેરે). કોઈ આ અભિગમને નવા પ્રોજેક્ટમાં અજમાવી શકે છે અને, જો તે યોગ્ય રીતે બંધબેસતું ન હોય તો, જૂના જમાનાની રીત પર સ્વિચ કરો.

અલબત્ત, કમ્પાઇલ કરવા યોગ્ય રૂપરેખાંકન માટે ઉચ્ચ ગુણવત્તાની વિકાસ પ્રક્રિયાની જરૂર છે. બદલામાં તે સમાન ઉચ્ચ ગુણવત્તાની મજબૂત ગોઠવણી પ્રદાન કરવાનું વચન આપે છે.

આ અભિગમને વિવિધ રીતે વિસ્તૃત કરી શકાય છે:

1. કોઈ પણ રૂપરેખાંકન માન્યતા કરવા માટે મેક્રોનો ઉપયોગ કરી શકે છે અને કોઈપણ વ્યવસાય-તર્ક અવરોધોની નિષ્ફળતાના કિસ્સામાં કમ્પાઈલ સમયે નિષ્ફળ થઈ શકે છે.
2. ડોમેન-વપરાશકર્તા-મૈત્રીપૂર્ણ રીતે રૂપરેખાંકનનું પ્રતિનિધિત્વ કરવા માટે DSL લાગુ કરી શકાય છે.
3. સ્વચાલિત ગોઠવણી ગોઠવણો સાથે ગતિશીલ સંસાધન સંચાલન. દાખલા તરીકે, જ્યારે આપણે ક્લસ્ટર નોડ્સની સંખ્યાને સમાયોજિત કરીએ છીએ ત્યારે અમે ઈચ્છી શકીએ છીએ (1) નોડ્સ સહેજ સંશોધિત રૂપરેખાંકન મેળવવા માટે; (2) નવા નોડ્સની માહિતી મેળવવા માટે ક્લસ્ટર મેનેજર.

આભાર

આ પોસ્ટના ડ્રાફ્ટ પર પ્રેરણાદાયી પ્રતિસાદ આપવા બદલ હું એન્ડ્રે સાકસોનોવ, પાવેલ પોપોવ, એન્ટોન નેહાઈવનો આભાર કહેવા માંગુ છું જેણે મને તેને સ્પષ્ટ કરવામાં મદદ કરી.

સોર્સ: www.habr.com