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

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

(ઇંગલિશ)

પરિચય

વિશ્વસનીય વિતરિત સિસ્ટમ બનાવવાનો અર્થ એ છે કે તમામ નોડ્સ યોગ્ય રૂપરેખાંકનનો ઉપયોગ કરે છે, અન્ય નોડ્સ સાથે સિંક્રનાઇઝ થાય છે. 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)

ફેન્ટમ પ્રકારો

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

એક સામાન્ય પ્રોટોકોલ જેસન સીરીયલાઇઝેશન સાથેનું 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'ઓમ, અને ક્લાયંટ નોડ થોડા સમય પછી સમાપ્ત થાય છે. સેમી. લોન્ચર એપ્લિકેશન.

સામાન્ય વિકાસ પ્રક્રિયા

ચાલો જોઈએ કે આ રૂપરેખાંકન અભિગમ સમગ્ર વિકાસ પ્રક્રિયાને કેવી રીતે અસર કરે છે.

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