🥇බෙදා හරින ලද පද්ධතියක සම්පාදනය කළ හැකි වින්‍යාසය

මෙම ලිපියෙන් අපි බෙදා හරින ලද පද්ධතියක වින්‍යාසය සමඟ ගනුදෙනු කිරීමේ රසවත් ක්‍රමයක් බෙදා ගැනීමට කැමැත්තෙමු.
වින්‍යාසය Scala භාෂාවෙන් වර්ගය ආරක්ෂිත ආකාරයෙන් සෘජුවම නිරූපණය කෙරේ. උදාහරණයක් ක්රියාත්මක කිරීම විස්තරාත්මකව විස්තර කර ඇත. සමස්ත සංවර්ධන ක්‍රියාවලියට බලපෑම් ඇතුළු යෝජනාවේ විවිධ පැති සාකච්ඡා කෙරේ.

(රුසියානු භාෂාවෙන්)

හැදින්වීම

ශක්තිමත් බෙදා හරින ලද පද්ධති ගොඩනැගීමට සියලුම නෝඩ් වල නිවැරදි සහ සුසංයෝගී වින්‍යාසය භාවිතා කිරීම අවශ්‍ය වේ. සාමාන්‍ය විසඳුමක් නම් පාඨමය යෙදවුම් විස්තරයක් (ටෙරාෆෝම්, ඇසිබල් හෝ ඒ හා සමාන දෙයක්) සහ ස්වයංක්‍රීයව උත්පාදනය කරන ලද වින්‍යාස ගොනු (බොහෝ විට - එක් එක් නෝඩ්/භූමිකාව සඳහා කැප කර ඇත) භාවිතා කිරීමයි. අපට එක් එක් සන්නිවේදන නෝඩ් වල එකම අනුවාදවල එකම ප්‍රොටෝකෝල භාවිතා කිරීමට අවශ්‍ය වනු ඇත (එසේ නොමැති නම් අපට නොගැලපෙන ගැටළු අත්විඳිය හැකිය). JVM ලෝකයේ මෙයින් අදහස් කරන්නේ අවම වශයෙන් පණිවුඩකරණ පුස්තකාලය සියලුම සන්නිවේදන නෝඩ් වල එකම අනුවාදයක තිබිය යුතු බවයි.

පද්ධතිය පරීක්ෂා කිරීම ගැන කුමක් කිව හැකිද? ඇත්ත වශයෙන්ම, අපි ඒකාබද්ධතා පරීක්ෂණවලට පැමිණීමට පෙර සියලුම සංරචක සඳහා ඒකක පරීක්ෂණ තිබිය යුතුය. ධාවන කාලය මත පරීක්ෂණ ප්‍රතිඵල විකාශනය කිරීමට හැකි වීම සඳහා, සියලුම පුස්තකාලවල අනුවාද ධාවන කාලය සහ පරීක්ෂණ පරිසරය යන දෙකෙහිම එක හා සමානව තබා ගැනීමට අප වග බලා ගත යුතුය.

ඒකාබද්ධතා පරීක්ෂණ ක්‍රියාත්මක කරන විට, සියලුම නෝඩ් වල එකම පන්ති මාර්ගයක් තිබීම බොහෝ විට පහසු වේ. අපට අවශ්‍ය වන්නේ යෙදවීමේදී එකම පන්ති මාර්ගය භාවිතා කරන බවට සහතික වීම පමණි. (විවිධ නෝඩ් වල විවිධ ක්ලාස්පාත් භාවිතා කළ හැක, නමුත් මෙම වින්‍යාසය නිරූපනය කිරීම සහ එය නිවැරදිව යෙදවීම වඩාත් අපහසු වේ.) එබැවින් දේවල් සරලව තබා ගැනීම සඳහා අපි සියලු නෝඩ් වල එකම ක්ලාස්පාත් පමණක් සලකා බලමු.

වින්‍යාසය මෘදුකාංගය සමඟ එක්ව පරිණාමය වීමට නැඹුරු වේ. අපි සාමාන්‍යයෙන් විවිධ හඳුනා ගැනීමට අනුවාද භාවිතා කරමු
මෘදුකාංග පරිණාමයේ අදියර. අනුවාද කළමනාකරණය යටතේ වින්‍යාසය ආවරණය කිරීම සහ සමහර ලේබල් සමඟ විවිධ වින්‍යාසයන් හඳුනා ගැනීම සාධාරණ බව පෙනේ. නිෂ්පාදනයේ ඇත්තේ එක් වින්‍යාසයක් පමණක් නම්, අපට හඳුනාගැනීමක් ලෙස තනි අනුවාදයක් භාවිතා කළ හැක. සමහර විට අපට බහු නිෂ්පාදන පරිසරයන් තිබිය හැක. තවද එක් එක් පරිසරය සඳහා අපට වෙනම වින්‍යාස ශාඛාවක් අවශ්‍ය විය හැකිය. එබැවින් විවිධ වින්‍යාසයන් අනන්‍ය ලෙස හඳුනා ගැනීම සඳහා වින්‍යාසයන් ශාඛාව සහ අනුවාදය සමඟ ලේබල් කළ හැක. එක් එක් ශාඛා ලේබලය සහ අනුවාදය එක් එක් නෝඩය මත බෙදා හරින ලද නෝඩ්, වරායන්, බාහිර සම්පත්, පන්ති මාර්ග පුස්තකාල අනුවාදවල තනි සංයෝජනයකට අනුරූප වේ. මෙහිදී අපි තනි ශාඛාව පමණක් ආවරණය කර අනෙකුත් කෞතුක වස්තු මෙන් ම සංරචක තුනක දශම අනුවාදයකින් (1.2.3) වින්‍යාසයන් හඳුනා ගනිමු.

නවීන පරිසරවල වින්‍යාස ගොනු තවදුරටත් අතින් වෙනස් නොවේ. සාමාන්යයෙන් අපි උත්පාදනය කරමු
වින්‍යාසගත කිරීමේ වේලාවේදී ගොනු වින්‍යාස කරන්න සහ කවදාවත් ඒවා අල්ලන්න එපා පසුව. එසේනම් අප තවමත් වින්‍යාස ගොනු සඳහා පෙළ ආකෘතිය භාවිතා කරන්නේ මන්දැයි කෙනෙකුට ඇසිය හැක. ශක්‍ය විකල්පයක් වන්නේ වින්‍යාසය සම්පාදන ඒකකයක් තුළ තැබීම සහ සම්පාදන-කාල වින්‍යාස වලංගුකරණයෙන් ප්‍රතිලාභ ලබා ගැනීමයි.

මෙම ලිපියෙන් අපි සම්පාදනය කරන ලද කෞතුක වස්තුවේ වින්‍යාසය තබා ගැනීමේ අදහස විමසා බලමු.

සම්පාදනය කළ හැකි වින්‍යාසය

මෙම කොටසේදී අපි ස්ථිතික වින්‍යාසය පිළිබඳ උදාහරණයක් සාකච්ඡා කරමු. සරල සේවා දෙකක් - echo සේවාව සහ echo සේවාවේ සේවාදායකයා වින්‍යාස කර ක්‍රියාත්මක කෙරේ. එවිට සේවා දෙකම සහිත විවිධ බෙදාහැරීමේ පද්ධති දෙකක් ක්ෂණිකව ක්රියාත්මක වේ. එකක් තනි නෝඩ් වින්‍යාසයක් සඳහා වන අතර තවත් එකක් නෝඩ් දෙකක වින්‍යාසය සඳහා වේ.

සාමාන්‍ය බෙදාහැරීමේ පද්ධතියක් නෝඩ් කිහිපයකින් සමන්විත වේ. කිසියම් වර්ගයක් භාවිතා කර නෝඩ් හඳුනාගත හැකිය:

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-bit අගයන් පමණක් ලබා ගැනීමට අවසර ඇත. මෙම වින්‍යාස කිරීමේ ප්‍රවේශය සඳහා මෙම පුස්තකාලය භාවිතා කිරීමේ අවශ්‍යතාවයක් නොමැත. එය ඉතා හොඳින් ගැලපෙන බව පෙනේ.

HTTP (REST) සඳහා අපට සේවාවේ මාර්ගයක් ද අවශ්‍ය විය හැකිය:

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

ෆැන්ටම් වර්ගය

සම්පාදනය කිරීමේදී ප්‍රොටෝකෝලය හඳුනා ගැනීම සඳහා අපි භාවිතා කරන්නේ ප්‍රකාශිත ආකාරයේ තර්කයේ Scala විශේෂාංගය Protocol පන්තියේ භාවිතා නොකරන බව. එය ඊනියා එකක් ෆැන්ටම් වර්ගය. ක්‍රියාත්මක වන විට අපට ප්‍රොටෝකෝල හඳුනාගැනීමේ අවස්ථාවක් අවශ්‍ය වන්නේ කලාතුරකිනි, අප එය ගබඩා නොකරන්නේ එබැවිනි. සම්පාදනය කිරීමේදී මෙම ෆැන්ටම් වර්ගය අමතර ආරක්ෂාවක් ලබා දෙයි. වැරදි ප්‍රොටෝකෝලයකින් අපට port pass කළ නොහැක.

වඩාත් බහුලව භාවිතා වන ප්‍රොටෝකෝල වලින් එකක් වන්නේ Json අනුක්‍රමිකකරණය සමඟ REST API ය:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

එහිදී RequestMessage සේවාදායකයාට සේවාදායකයට යැවිය හැකි මූලික පණිවිඩ වර්ගය සහ ResponseMessage සේවාදායකයෙන් ලැබෙන ප්‍රතිචාර පණිවිඩයයි. ඇත්ත වශයෙන්ම, අපට අවශ්‍ය නිරවද්‍යතාවයෙන් සන්නිවේදන ප්‍රොටෝකෝලය සඳහන් කරන වෙනත් ප්‍රොටෝකෝල විස්තර නිර්මාණය කළ හැකිය.

මෙම ලිපියේ අරමුණු සඳහා අපි ප්‍රොටෝකෝලයේ සරල අනුවාදයක් භාවිතා කරන්නෙමු:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

මෙම ප්‍රොටෝකෝලය තුළ ඉල්ලීම් පණිවිඩය url වෙත අමුණා ඇති අතර ප්‍රතිචාර පණිවිඩය සරල තන්තුවක් ලෙස ආපසු එවනු ලැබේ.

සේවා වින්‍යාසය සේවා නාමය, වරායන් එකතුවක් සහ සමහර පරායත්තතා මගින් විස්තර කළ හැක. Scala හි මෙම සියලු මූලද්‍රව්‍ය නිරූපණය කරන්නේ කෙසේද යන්න පිළිබඳ හැකි ක්‍රම කිහිපයක් තිබේ (උදාහරණයක් ලෙස, 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)
  }

Echo සේවාවට අවශ්‍ය වන්නේ වරායක් වින්‍යාස කිරීම පමණි. තවද මෙම වරාය echo protocol සඳහා සහය දක්වන බව අපි ප්‍රකාශ කරමු. මේ මොහොතේ අපට විශේෂිත වරායක් සඳහන් කිරීමට අවශ්‍ය නොවන බව සලකන්න, මන්ද ගතිගුණ මඟින් වියුක්ත ක්‍රම ප්‍රකාශ කිරීමට ඉඩ සලසයි. අපි වියුක්ත ක්‍රම භාවිතා කරන්නේ නම්, සම්පාදකයට වින්‍යාස කිරීමේ අවස්ථාවක ක්‍රියාත්මක කිරීමක් අවශ්‍ය වේ. මෙන්න අපි ක්රියාත්මක කිරීම ලබා දී ඇත (8081) සහ අපි එය කොන්ක්‍රීට් වින්‍යාසයකින් මඟ හැරියහොත් එය පෙරනිමි අගය ලෙස භාවිතා කරනු ඇත.

echo සේවා සේවාදායකයාගේ වින්‍යාසය තුළ අපට යැපීම ප්‍රකාශ කළ හැක:

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

(බලන්න ප්රභව කේතය වෙනත් සේවා ක්‍රියාත්මක කිරීම් සඳහා - echo සේවාව,
echo සේවාදායකයා සහ ජීවිත කාලය පාලකයන්.)

නෝඩයක් යනු සේවා කිහිපයක් ධාවනය කරන තනි වස්තුවකි (සම්පත් දාමයක් ආරම්භ කිරීම කේක් රටාව මගින් සක්‍රීය කර ඇත):

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

මෙම නෝඩයට අවශ්‍ය නිශ්චිත වින්‍යාස වර්ගය අපි නෝඩයේ සඳහන් කරන බව සලකන්න. සම්පාදකයා අපට වස්තුව (කේක්) ප්‍රමාණවත් නොවන වර්ගයකින් තැනීමට ඉඩ නොදේ, මන්ද සෑම සේවා ලක්ෂණයක්ම සීමාවක් ප්‍රකාශ කරයි. Config වර්ගය. එසේම සම්පූර්ණ වින්‍යාසය ලබා නොදී අපට නෝඩය ආරම්භ කිරීමට නොහැකි වනු ඇත.

නෝඩ් ලිපින විභේදනය

සම්බන්ධතාවයක් ස්ථාපනය කිරීම සඳහා අපට එක් එක් නෝඩය සඳහා සැබෑ සත්කාරක ලිපිනයක් අවශ්‍ය වේ. එය වින්‍යාසයේ අනෙකුත් කොටස් වලට වඩා පසුව දැනගත හැක. එබැවින්, අපට node id සහ එහි සත්‍ය ලිපිනය අතර සිතියම්ගත කිරීමක් සැපයීමට ක්‍රමයක් අවශ්‍ය වේ. මෙම සිතියම්කරණය කාර්යයකි:

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

එවැනි කාර්යයක් ක්රියාත්මක කිරීමට හැකි ක්රම කිහිපයක් තිබේ.

අපි යෙදවීමට පෙර සත්‍ය ලිපින දන්නේ නම්, node hosts instantation අතරතුර, එවිට අපට සත්‍ය ලිපින සමඟ Scala කේතය ජනනය කර පසුව ගොඩනැගීම ක්‍රියාත්මක කළ හැකිය (එය සම්පාදනය කරන කාල පරීක්‍ෂණ සිදු කර පසුව ඒකාබද්ධ පරීක්ෂණ කට්ටලය ක්‍රියාත්මක කරයි). මෙහිදී අපගේ සිතියම්කරණ කාර්යය ස්ථිතිකව දන්නා අතර එය a වැනි දෙයකට සරල කළ හැක Map[NodeId, NodeAddress].
සමහර විට අපි සත්‍ය ලිපින ලබා ගන්නේ නෝඩය ඇත්ත වශයෙන්ම ආරම්භ වූ විට පසු අවස්ථාවක හෝ අප සතුව තවමත් ආරම්භ කර නොමැති නෝඩ් වල ලිපින නොමැත. මෙම අවස්ථාවෙහිදී අපට අනෙකුත් සියලුම නෝඩ් වලට පෙර ආරම්භ කරන ලද සොයාගැනීම් සේවාවක් තිබිය හැකි අතර සෑම නෝඩයක්ම එම සේවාවෙහි ලිපිනය ප්‍රචාරය කර පරායත්තතා සඳහා දායක විය හැක.
අපට වෙනස් කළ හැකි නම් /etc/hosts, අපට පූර්ව නිර්වචනය කළ සත්කාරක නම් භාවිතා කළ හැක (වැනි my-project-main-node සහ echo-backend) සහ යෙදවීමේ වේලාවේදී මෙම නම ip ලිපිනය සමඟ සම්බන්ධ කරන්න.

මෙම ලිපියෙන් අපි මෙම අවස්ථා වැඩි විස්තර ආවරණය නොකරමු. ඇත්ත වශයෙන්ම අපගේ සෙල්ලම් බඩු උදාහරණයේ සියලුම නෝඩ් වලට එකම IP ලිපිනයක් ඇත - 127.0.0.1.

මෙම ලිපියෙන් අපි බෙදා හරින ලද පද්ධති පිරිසැලසුම් දෙකක් සලකා බලමු:

තනි නෝඩ් පිරිසැලසුම, සියලුම සේවාවන් තනි නෝඩය මත තබා ඇත.
සේවා සහ සේවාලාභියා විවිධ නෝඩ් වල ඇති නෝඩ් පිරිසැලසුම දෙකක්.

a සඳහා වින්‍යාසය තනි නෝඩය පිරිසැලසුම පහත පරිදි වේ:

තනි නෝඩ් වින්‍යාසය

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

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

  // configuration of client

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

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

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

මෙහිදී අපි සේවාදායකය සහ සේවාදායක වින්‍යාසය යන දෙකම දිගු කරන තනි වින්‍යාසයක් නිර්මාණය කරමු. සාමාන්‍යයෙන් සේවාදායකයා සහ සේවාදායකය අවසන් කරන ජීවන චක්‍ර පාලකයක් අපි වින්‍යාස කරමු lifetime පරතරය සමත් වේ.

එකම සේවා ක්‍රියාත්මක කිරීම් සහ වින්‍යාසයන් වෙනම නෝඩ් දෙකක් සහිත පද්ධතියේ පිරිසැලසුම නිර්මාණය කිරීමට භාවිතා කළ හැක. අපට අවශ්‍ය වන්නේ නිර්මාණය කිරීම පමණි වෙනම node configs දෙකක් සුදුසු සේවාවන් සමඟ:

නෝඩ් දෙකක වින්‍යාසය

  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, echo සේවාලාභියා වින්‍යාස කළ සීමිත කාල සීමාවෙන් පසුව අවසන් වනු ඇත. බලන්න ආරම්භක යෙදුම විස්තර සඳහා.

සමස්ත සංවර්ධන ක්රියාවලිය

මෙම ප්‍රවේශය අපි වින්‍යාසය සමඟ වැඩ කරන ආකාරය වෙනස් කරන්නේ කෙසේදැයි බලමු.

කේතය ලෙස වින්‍යාස කිරීම සම්පාදනය කර කෞතුක වස්තුවක් නිෂ්පාදනය කරයි. වෙනත් කේත පුරාවස්තු වලින් වින්‍යාස කෞතුක වස්තු වෙන් කිරීම සාධාරණ බව පෙනේ. බොහෝ විට අපට එකම කේත පදනම මත වින්‍යාසයන් රාශියක් තිබිය හැකිය. ඇත්ත වශයෙන්ම, අපට විවිධ වින්‍යාස ශාඛාවල බහු අනුවාද තිබිය හැකිය. වින්‍යාසයකදී අපට පුස්තකාලවල විශේෂිත අනුවාද තෝරාගත හැකි අතර අප මෙම වින්‍යාසය යොදවන සෑම විටම මෙය නියතව පවතිනු ඇත.

වින්‍යාස වෙනස් කිරීමක් කේත වෙනසක් බවට පත්වේ. එබැවින් එය එකම තත්ත්ව සහතික කිරීමේ ක්‍රියාවලියකින් ආවරණය කළ යුතුය:

ටිකට් -> PR -> සමාලෝචනය -> ඒකාබද්ධ කිරීම -> අඛණ්ඩ ඒකාබද්ධ කිරීම -> අඛණ්ඩ යෙදවීම

ප්රවේශයේ පහත සඳහන් ප්රතිවිපාක ඇත:

වින්‍යාසය යම් පද්ධතියක නිදසුනකට අනුකූල වේ. නෝඩ් අතර වැරදි සම්බන්ධතාවයක් ඇති කිරීමට ක්රමයක් නොමැති බව පෙනේ.
එක් නෝඩයක පමණක් වින්‍යාසය වෙනස් කිරීම පහසු නැත. ලොග් වී සමහර පෙළ ගොනු වෙනස් කිරීම අසාධාරණ බව පෙනේ. එබැවින් වින්‍යාස ප්ලාවිතය අඩු විය හැකිය.
කුඩා මානකරන වෙනස්කම් සිදු කිරීම පහසු නැත.
බොහෝ වින්‍යාස වෙනස් කිරීම් එකම සංවර්ධන ක්‍රියාවලිය අනුගමනය කරනු ඇති අතර එය යම් සමාලෝචනයක් සමත් වනු ඇත.

නිෂ්පාදන වින්‍යාසය සඳහා අපට වෙනම ගබඩාවක් අවශ්‍යද? නිෂ්පාදන වින්‍යාසය තුළ අපි බොහෝ පුද්ගලයන්ට ළඟා විය නොහැකි ලෙස තබා ගැනීමට කැමති සංවේදී තොරතුරු අඩංගු විය හැකිය. එබැවින් නිෂ්පාදන වින්‍යාසය අඩංගු සීමා සහිත ප්‍රවේශයක් සහිත වෙනම ගබඩාවක් තබා ගැනීම වටී. අපට වින්‍යාසය කොටස් දෙකකට බෙදිය හැකිය - නිෂ්පාදනයේ වඩාත්ම විවෘත පරාමිතීන් අඩංගු එකක් සහ වින්‍යාසයේ රහස් කොටස අඩංගු එකක්. මෙමගින් බොහෝ සංවර්ධකයින්ට අතිමහත් බහුතරයක පරාමිති වෙත ප්‍රවේශ විය හැකි අතරම සැබවින්ම සංවේදී දේවල් වෙත ප්‍රවේශය සීමා කෙරේ. පෙරනිමි පරාමිති අගයන් සමඟ අතරමැදි ගතිලක්ෂණ භාවිතයෙන් මෙය ඉටු කිරීම පහසුය.

ප්රභේදන

අනෙකුත් වින්‍යාස කළමනාකරණ ශිල්පීය ක්‍රම හා සසඳන විට යෝජිත ප්‍රවේශයේ වාසි සහ අවාසි බලමු.

පළමුවෙන්ම, අපි වින්‍යාසය සමඟ කටයුතු කිරීමේ යෝජිත ක්‍රමයේ විවිධ පැති සඳහා විකල්ප කිහිපයක් ලැයිස්තුගත කරන්නෙමු:

ඉලක්ක යන්ත්‍රයේ පෙළ ගොනුව.
මධ්‍යගත යතුරු අගය ගබඩා කිරීම (වැනි etcd/zookeeper).
ක්‍රියාවලිය නැවත ආරම්භ නොකර නැවත වින්‍යාසගත කළ හැකි/නැවත ආරම්භ කළ හැකි උපක්‍රියාවලි සංරචක.
කෞතුක භාණ්ඩ සහ අනුවාද පාලනයෙන් පිටත වින්‍යාස කිරීම.

Text ගොනුව ad-hoc fixes අනුව යම් නම්‍යශීලී බවක් ලබා දෙයි. පද්ධති පරිපාලකයෙකුට ඉලක්ක නෝඩයට පුරනය වී වෙනසක් සිදු කර සේවාව නැවත ආරම්භ කළ හැක. මෙය විශාල පද්ධති සඳහා එතරම් හොඳ නොවිය හැකිය. වෙනස පිටුපස කිසිදු හෝඩුවාවක් ඉතිරි නොවේ. වෙනස් කිරීම වෙනත් ඇස් යුගලයකින් සමාලෝචනය නොකෙරේ. වෙනස් වීමට හේතුව කුමක්දැයි සොයා ගැනීම දුෂ්කර විය හැකිය. එය පරීක්ෂා කර නැත. බෙදා හරින ලද පද්ධතියේ දෘෂ්ටිකෝණයෙන් පරිපාලකයෙකුට වෙනත් නෝඩ් එකක වින්‍යාසය යාවත්කාලීන කිරීමට අමතක කළ හැක.

(Btw, අවසානයේදී පෙළ වින්‍යාස ගොනු භාවිතා කිරීම ආරම්භ කිරීමට අවශ්‍ය වන්නේ නම්, අපට එකතු කිරීමට සිදු වන්නේ එයම නිපදවිය හැකි විග්‍රහ කරන්න + වලංගුකාරකය පමණි. Config ටයිප් කරන්න සහ එය පෙළ වින්‍යාස භාවිතා කිරීම ආරම්භ කිරීමට ප්‍රමාණවත් වේ. සම්පාදනය-කාල වින්‍යාසයේ සංකීර්ණත්වය පෙළ-පාදක වින්‍යාසවල සංකීර්ණතාවයට වඩා ටිකක් කුඩා බව මෙයින් පෙන්නුම් කරයි, මන්ද පෙළ-පාදක අනුවාදයේ අපට අමතර කේතයක් අවශ්‍ය වේ.)

යෙදුම් මෙටා පරාමිති බෙදා හැරීම සඳහා මධ්‍යගත යතුරු අගය ගබඩා කිරීම හොඳ යාන්ත්‍රණයකි. මෙහිදී අපි වින්‍යාස අගයන් ලෙස සලකන දේ සහ දත්ත යනු කුමක්ද යන්න ගැන සිතා බැලිය යුතුය. කාර්යයක් ලබා දී ඇත C => A => B අපි සාමාන්‍යයෙන් කලාතුරකින් වෙනස් වන අගයන් ලෙස හඳුන්වමු C "වින්‍යාසය", නිතර දත්ත වෙනස් කරන අතරතුර A - දත්ත පමණක් ඇතුලත් කරන්න. දත්ත වලට වඩා කලින් කාර්යයට වින්‍යාසය සැපයිය යුතුය A. මෙම අදහස අනුව, වින්‍යාස දත්ත පමණක් දත්ත වලින් වෙන්කර හඳුනා ගැනීමට භාවිතා කළ හැකි වෙනස්කම්වල අපේක්ෂිත සංඛ්‍යාතය බව අපට පැවසිය හැකිය. එසේම දත්ත සාමාන්‍යයෙන් එක් මූලාශ්‍රයකින් (පරිශීලකයෙකු) පැමිණෙන අතර වින්‍යාසය වෙනත් මූලාශ්‍රයකින් (පරිපාලක) පැමිණේ. ආරම්භක ක්රියාවලියෙන් පසුව වෙනස් කළ හැකි පරාමිතීන් සමඟ කටයුතු කිරීම යෙදුම් සංකීර්ණත්වය වැඩි කිරීමට හේතු වේ. එවැනි පරාමිති සඳහා අපට ඒවායේ බෙදා හැරීමේ යාන්ත්‍රණය, විග්‍රහ කිරීම සහ වලංගු කිරීම, වැරදි අගයන් හැසිරවීම හැසිරවීමට සිදුවේ. එබැවින්, වැඩසටහන් සංකීර්ණත්වය අඩු කිරීම සඳහා, අපි ධාවන වේලාවේදී වෙනස් කළ හැකි (නැතහොත් ඒවා සම්පූර්ණයෙන්ම ඉවත් කිරීමට පවා) පරාමිති ගණන අඩු කිරීම වඩා හොඳය.

මෙම තනතුරේ ඉදිරිදර්ශනයෙන් අපි ස්ථිතික සහ ගතික පරාමිතීන් අතර වෙනසක් කළ යුතුය. සේවා තර්කයට ධාවන වේලාවේදී සමහර පරාමිතිවල දුර්ලභ වෙනසක් අවශ්‍ය නම්, අපි ඒවා ගතික පරාමිති ලෙස හැඳින්විය හැක. එසේ නොමැතිනම් ඒවා ස්ථිතික වන අතර යෝජිත ප්‍රවේශය භාවිතයෙන් වින්‍යාසගත කළ හැක. ගතික නැවත සකස් කිරීම සඳහා වෙනත් ප්‍රවේශයන් අවශ්‍ය විය හැක. උදාහරණයක් ලෙස, බෙදා හරින ලද පද්ධතියක වෙනම ක්‍රියාවලි නැවත ආරම්භ කිරීමට සමාන ආකාරයකින් නව වින්‍යාස පරාමිතීන් සමඟ පද්ධතියේ කොටස් නැවත ආරම්භ කළ හැක.
(මගේ නිහතමානී අදහස නම් එය පද්ධතියේ සංකීර්ණත්වය වැඩි කරන බැවින් ධාවන කාල නැවත සකස් කිරීමෙන් වැළකී සිටීමයි.
ක්‍රියාවලි නැවත ආරම්භ කිරීම සඳහා OS සහාය මත යැපීම වඩාත් සරල විය හැකිය. කෙසේ වෙතත්, එය සැමවිටම කළ නොහැකි විය හැකිය.)

ස්ථිතික වින්‍යාසය භාවිතා කිරීමේ එක් වැදගත් අංගයක් සමහර විට මිනිසුන් ගතික වින්‍යාසය (වෙනත් හේතු නොමැතිව) සලකා බලයි වින්‍යාස යාවත්කාලීන කිරීමේදී සේවා අක්‍රිය වේ. ඇත්ත වශයෙන්ම, අපට ස්ථිතික වින්‍යාසය සඳහා වෙනස්කම් කිරීමට සිදුවුවහොත්, නව අගයන් ඵලදායී වන පරිදි අපි පද්ධතිය නැවත ආරම්භ කළ යුතුය. අක්‍රිය කාලය සඳහා අවශ්‍යතා විවිධ පද්ධති සඳහා වෙනස් වේ, එබැවින් එය එතරම් තීරණාත්මක නොවිය හැකිය. එය තීරණාත්මක නම්, ඕනෑම පද්ධතියක් නැවත ආරම්භ කිරීම සඳහා අපි කල්තියා සැලසුම් කළ යුතුය. උදාහරණයක් ලෙස, අපට ක්රියාත්මක කළ හැකිය AWS ELB සම්බන්ධතාවය කාන්දු වීම. මෙම අවස්ථාවෙහිදී, අපට පද්ධතිය නැවත ආරම්භ කිරීමට අවශ්‍ය වූ විට, අපි පද්ධතියේ නව අවස්ථාවක් සමාන්තරව ආරම්භ කරමු, පසුව ELB වෙත මාරු කරන්න, පැරණි පද්ධතියට පවතින සම්බන්ධතා සම්පූර්ණ කිරීමට ඉඩ දෙන අතරම.

අනුවාදිත කෞතුක භාණ්ඩයක් ඇතුළත හෝ පිටත වින්‍යාසය තබා ගැනීම ගැන කුමක් කිව හැකිද? කෞතුක වස්තුවක් තුළ වින්‍යාසය තබා ගැනීම යනු බොහෝ අවස්ථාවලදී මෙම වින්‍යාසය අනෙකුත් කෞතුක වස්තු හා සමාන තත්ත්ව සහතික කිරීමේ ක්‍රියාවලිය සමත් වී ඇති බවයි. එබැවින් වින්‍යාසය හොඳ තත්ත්වයේ සහ විශ්වාසදායක බව කෙනෙකුට සහතික විය හැකිය. ඊට පටහැනිව, වෙනම ගොනුවක වින්‍යාස කිරීම යනු එම ගොනුවේ වෙනස්කම් කළේ කවුරුන්ද සහ ඇයිද යන්න පිළිබඳ කිසිදු හෝඩුවාවක් නොමැති බවයි. මෙය වැදගත්ද? බොහෝ නිෂ්පාදන පද්ධති සඳහා ස්ථාවර සහ උසස් තත්ත්වයේ වින්‍යාසයක් තිබීම වඩා හොඳ බව අපි විශ්වාස කරමු.

කෞතුක වස්තුවේ අනුවාදය එය නිර්මාණය කළේ කවදාද, එහි අඩංගු අගයන් මොනවාද, සක්‍රීය / අක්‍රීය කර ඇති විශේෂාංග මොනවාද, වින්‍යාසයේ එක් එක් වෙනස් කිරීම සඳහා වගකිව යුත්තේ කවුරුන්ද යන්න සොයා ගැනීමට ඉඩ සලසයි. කෞතුක වස්තුවක් තුළ වින්‍යාසය තබා ගැනීමට යම් උත්සාහයක් අවශ්‍ය විය හැකි අතර එය සැලසුම් තේරීමක් වේ.

වාසි අවාසි

මෙහිදී අපි යෝජිත ප්‍රවේශයේ වාසි කිහිපයක් ඉස්මතු කිරීමට සහ සමහර අවාසි සාකච්ඡා කිරීමට කැමැත්තෙමු.

වාසි

සම්පූර්ණ බෙදා හරින ලද පද්ධතියක සම්පාදනය කළ හැකි වින්‍යාසයේ විශේෂාංග:

වින්යාසයේ ස්ථිතික පරීක්ෂාව. මෙය ඉහළ මට්ටමේ විශ්වාසයක් ලබා දෙයි, වින්‍යාසය නිවැරදි බව ලබා දී ඇති ආකාරයේ සීමා කිරීම්.
වින්‍යාසයේ පොහොසත් භාෂාව. සාමාන්‍යයෙන් වෙනත් වින්‍යාස ප්‍රවේශයන් බොහෝ විට විචල්‍ය ආදේශනයකට සීමා වේ.
Scala භාවිතයෙන් කෙනෙකුට වින්‍යාසය වඩා හොඳ කිරීමට පුළුල් පරාසයක භාෂා විශේෂාංග භාවිතා කළ හැක. උදාහරණයක් ලෙස, අපට පෙරනිමි අගයන් සැපයීමට ගති ලක්ෂණ භාවිතා කළ හැක, විවිධ විෂය පථය සැකසීමට වස්තූන්, අපට යොමු කළ හැක valබාහිර විෂය පථයේ (DRY) එක් වරක් පමණක් අර්ථ දක්වා ඇත. වචනාර්ථ අනුපිළිවෙලවල් හෝ ඇතැම් පන්තිවල අවස්ථා භාවිතා කළ හැකිය (Seq, Map, ආදිය).
DSL. Scala DSL ලේඛකයින් සඳහා හොඳ සහයෝගයක් ඇත. අවසාන වින්‍යාසය අවම වශයෙන් වසම් පරිශීලකයින්ට කියවිය හැකි වන පරිදි වඩාත් පහසු සහ අවසාන පරිශීලක-හිතකාමී වන වින්‍යාස භාෂාවක් පිහිටුවීමට කෙනෙකුට මෙම විශේෂාංග භාවිතා කළ හැක.
නෝඩ් හරහා අඛණ්ඩතාව සහ සුසංයෝගය. සම්පූර්ණ බෙදා හරින ලද පද්ධතිය සඳහා එකම ස්ථානයක වින්‍යාසය තිබීමේ එක් වාසියක් නම්, සියලුම අගයන් එක් වරක් දැඩි ලෙස අර්ථ දක්වා ඇති අතර පසුව අපට අවශ්‍ය සියලුම ස්ථානවල නැවත භාවිතා කිරීමයි. හැකි සෑම නිවැරදි වින්‍යාසයකම පද්ධතියේ නෝඩ් එකම භාෂාව කතා කරන බව සහතික කරන ආරක්ෂිත වරාය ප්‍රකාශයන් ටයිප් කරන්න. නෝඩ් අතර පැහැදිලි පරායත්තතා ඇති අතර එමඟින් සමහර සේවා සැපයීම අමතක කිරීම අපහසු වේ.
වෙනස්කම්වල උසස් තත්ත්වයේ. සාමාන්‍ය PR ක්‍රියාවලිය හරහා වින්‍යාසය වෙනස් කිරීමේ සමස්ත ප්‍රවේශය වින්‍යාසය තුළ ද උසස් තත්ත්වයේ ප්‍රමිතීන් ස්ථාපිත කරයි.
සමගාමී වින්‍යාස වෙනස්කම්. අපි වින්‍යාසයේ යම් වෙනසක් සිදු කරන විට ස්වයංක්‍රීය යෙදවීම මඟින් සියලුම නෝඩ් යාවත්කාලීන වන බව සහතික කරයි.
යෙදුම් සරල කිරීම. යෙදුමට වින්‍යාසය විග්‍රහ කිරීමට සහ වලංගු කිරීමට සහ වැරදි වින්‍යාස අගයන් හැසිරවීමට අවශ්‍ය නොවේ. මෙය සමස්ත යෙදුම සරල කරයි. (සමහර සංකීර්ණතා වැඩි වීමක් වින්‍යාසය තුළම ඇත, නමුත් එය ආරක්ෂාව සඳහා දැනුවත් වෙළඳාමකි.) සාමාන්‍ය වින්‍යාසය වෙත ආපසු යාම ඉතා සරලයි - නැතිවූ කෑලි එකතු කරන්න. සම්පාදනය කරන ලද වින්‍යාසය සමඟ ආරම්භ කිරීම පහසු වන අතර අමතර කොටස් ක්‍රියාත්මක කිරීම පසු කාලයකට කල් දමන්න.
අනුවාදිත වින්‍යාසය. වින්‍යාස වෙනස්කම් එකම සංවර්ධන ක්‍රියාවලියක් අනුගමනය කරන නිසා, එහි ප්‍රතිඵලයක් ලෙස අපට අද්විතීය අනුවාදයක් සහිත කෞතුක වස්තුවක් ලැබේ. අවශ්‍ය නම් වින්‍යාසය නැවත මාරු කිරීමට එය අපට ඉඩ සලසයි. වසරකට පෙර භාවිතා කළ වින්‍යාසයක් පවා අපට යෙදවිය හැකි අතර එය හරියටම ක්‍රියා කරයි. ස්ථාවර වින්‍යාසය බෙදා හරින ලද පද්ධතියේ පුරෝකථනය කිරීමේ හැකියාව සහ විශ්වසනීයත්වය වැඩි දියුණු කරයි. වින්‍යාසය සම්පාදනය කරන වේලාවේදී සවි කර ඇති අතර නිෂ්පාදන පද්ධතියකට පහසුවෙන් බාධා කළ නොහැක.
මොඩියුලරිටි. යෝජිත රාමුව මොඩියුලර් වන අතර මොඩියුල විවිධ ආකාරවලින් ඒකාබද්ධ කළ හැකිය
විවිධ වින්‍යාසයන් සඳහා සහය දක්වන්න (සැකසීම්/පිරිසැලසුම්). විශේෂයෙන්ම, කුඩා පරිමාණයේ තනි නෝඩ් පිරිසැලසුමක් සහ විශාල පරිමාණයේ බහු නෝඩ් සැකසුමක් තිබිය හැකිය. බහු නිෂ්පාදන පිරිසැලසුම් තිබීම සාධාරණයි.
පරීක්ෂා කිරීම. පරීක්ෂණ අරමුණු සඳහා කෙනෙකුට ව්‍යාජ සේවාවක් ක්‍රියාත්මක කළ හැකි අතර එය වර්ගයක් ආරක්ෂිත ආකාරයකින් යැපීම ලෙස භාවිතා කළ හැකිය. උපහාස මගින් ප්‍රතිස්ථාපනය කරන ලද විවිධ කොටස් සහිත විවිධ පරීක්ෂණ පිරිසැලසුම් කිහිපයක් එකවර පවත්වා ගත හැක.
ඒකාබද්ධතා පරීක්ෂණය. සමහර විට බෙදා හරින ලද පද්ධතිවල ඒකාබද්ධතා පරීක්ෂණ ධාවනය කිරීමට අපහසු වේ. සම්පූර්ණ බෙදා හරින ලද පද්ධතියේ ආරක්ෂිත වින්‍යාසය ටයිප් කිරීමට විස්තර කර ඇති ප්‍රවේශය භාවිතා කරමින්, අපට සියලුම බෙදා හරින ලද කොටස් තනි සේවාදායකයක පාලනය කළ හැකි ආකාරයෙන් ධාවනය කළ හැකිය. තත්වය අනුකරණය කිරීම පහසුය
එක් සේවාවක් නොමැති විට.

අවාසි

සම්පාදනය කරන ලද වින්‍යාස කිරීමේ ප්‍රවේශය “සාමාන්‍ය” වින්‍යාසයට වඩා වෙනස් වන අතර එය සියලු අවශ්‍යතා සඳහා නොගැලපේ. සම්පාදනය කරන ලද වින්‍යාසයේ අවාසි කිහිපයක් මෙන්න:

ස්ථිතික වින්යාසය. එය සියලුම යෙදුම් සඳහා සුදුසු නොවිය හැක. සමහර අවස්ථාවල දී සියලු ආරක්ෂක පියවරයන් මඟ හරිමින් නිෂ්පාදනයේ වින්යාසය ඉක්මනින් සවි කිරීම අවශ්ය වේ. මෙම ප්රවේශය වඩාත් අපහසු වේ. වින්‍යාසයේ යම් වෙනසක් සිදු කිරීමෙන් පසු සම්පාදනය සහ නැවත යෙදවීම අවශ්‍ය වේ. මෙය ලක්ෂණය සහ බර යන දෙකම වේ.
වින්යාස උත්පාදනය. කිසියම් ස්වයංක්‍රීය මෙවලමක් මඟින් වින්‍යාසය ජනනය කරන විට මෙම ප්‍රවේශයට පසු සම්පාදනය අවශ්‍ය වේ (එය අසාර්ථක විය හැක). මෙම අතිරේක පියවර ගොඩනැගීමේ පද්ධතියට ඒකාබද්ධ කිරීමට අමතර වෑයමක් අවශ්‍ය විය හැකිය.
උපකරණ. පෙළ-පාදක වින්‍යාසයන් මත රඳා පවතින මෙවලම් ඕනෑ තරම් අද භාවිතයේ ඇත. ඒවායින් සමහරක්
වින්‍යාසය සම්පාදනය කරන විට අදාළ නොවේ.
ආකල්පමය වෙනසක් අවශ්‍යයි. සංවර්ධකයින් සහ DevOps පෙළ වින්‍යාස ගොනු පිළිබඳව හුරුපුරුදුය. වින්‍යාසය සම්පාදනය කිරීමේ අදහස ඔවුන්ට අමුතු දෙයක් ලෙස පෙනෙනු ඇත.
සම්පාදනය කළ හැකි වින්‍යාසය හඳුන්වා දීමට පෙර උසස් තත්ත්වයේ මෘදුකාංග සංවර්ධන ක්‍රියාවලියක් අවශ්‍ය වේ.

ක්රියාත්මක කරන ලද උදාහරණයේ යම් සීමාවන් තිබේ:

අපි නෝඩ් ක්‍රියාත්මක කිරීම මගින් ඉල්ලා නොසිටින අමතර වින්‍යාසයක් සපයන්නේ නම්, නොපවතින ක්‍රියාත්මක කිරීම හඳුනා ගැනීමට සම්පාදකය අපට උදව් නොකරනු ඇත. භාවිතා කිරීමෙන් මෙය විසඳා ගත හැකිය HList හෝ ගති ලක්ෂණ සහ කේක් රටාව වෙනුවට නෝඩ් වින්‍යාසය සඳහා ADTs (නඩු පන්ති).
අපට වින්‍යාස ගොනුවේ බොයිලේරු තහඩුවක් සැපයිය යුතුය: (package, import, object ප්රකාශන;
override defපෙරනිමි අගයන් ඇති පරාමිති සඳහා s). මෙය ඩීඑස්එල් භාවිතයෙන් අර්ධ වශයෙන් ආමන්ත්‍රණය කළ හැක.
මෙම ලිපියෙන් අපි සමාන නෝඩ් පොකුරු ගතික ප්‍රතිසංවිධානය ආවරණය නොකරමු.

නිගමනය

මෙම ලිපියෙන් අපි වින්‍යාසය සෘජුවම ප්‍රභව කේතයේ ආරක්ෂිත ආකාරයකින් නිරූපණය කිරීමේ අදහස සාකච්ඡා කර ඇත්තෙමු. ප්‍රවේශය xml- සහ අනෙකුත් පෙළ-පාදක වින්‍යාස සඳහා ප්‍රතිස්ථාපනයක් ලෙස බොහෝ යෙදුම්වල භාවිතා කළ හැක. අපගේ උදාහරණය Scala හි ක්‍රියාත්මක කර ඇතත්, එය වෙනත් සම්පාදනය කළ හැකි භාෂාවලටද පරිවර්තනය කළ හැකිය (Kotlin, C#, Swift, ආදිය). කෙනෙකුට මෙම ප්‍රවේශය නව ව්‍යාපෘතියක උත්සාහ කළ හැකි අතර, එය හොඳින් නොගැලපේ නම්, පැරණි ක්‍රමයට මාරු වන්න.

ඇත්ත වශයෙන්ම, සම්පාදනය කළ හැකි වින්‍යාසය සඳහා උසස් තත්ත්වයේ සංවර්ධන ක්‍රියාවලියක් අවශ්‍ය වේ. ආපසු එය සමානව උසස් තත්ත්වයේ ශක්තිමත් වින්‍යාසයක් ලබා දීමට පොරොන්දු වේ.

මෙම ප්රවේශය විවිධ ආකාරවලින් දීර්ඝ කළ හැකිය:

කෙනෙකුට වින්‍යාසය වලංගු කිරීම සිදු කිරීමට මැක්‍රෝ භාවිතා කළ හැකි අතර කිසියම් ව්‍යාපාර-තර්කක බාධාවන් අසාර්ථක වූ විට සම්පාදනය කිරීමේදී අසාර්ථක විය හැක.
වසම්-පරිශීලක-හිතකාමී ආකාරයෙන් වින්‍යාසය නියෝජනය කිරීමට DSL ක්‍රියාත්මක කළ හැක.
ස්වයංක්‍රීය වින්‍යාස ගැලපුම් සමඟ ගතික සම්පත් කළමනාකරණය. උදාහරණයක් ලෙස, අපි පොකුරු නෝඩ් ගණන සකස් කරන විට අපට අවශ්‍ය විය හැකිය (1) නෝඩ් තරමක් වෙනස් කළ වින්‍යාසයක් ලබා ගැනීමට; (2) නව නෝඩ් තොරතුරු ලබා ගැනීමට පොකුරු කළමනාකරු.

ස්තූතියි

එය වඩාත් පැහැදිලි කිරීමට මට උපකාර කළ මෙම සටහනේ කෙටුම්පත පිළිබඳ ආනුභාව සම්පන්න ප්‍රතිපෝෂණ ලබා දීම ගැන මම Andrey Saksonov, Pavel Popov, Anton Nehaev ට ස්තූති කිරීමට කැමතියි.

මූලාශ්රය: www.habr.com