د توزیع شوي سیسټم تنظیم کول

زه غواړم تاسو ته د ویشل شوي سیسټم تنظیم کولو سره د کار کولو لپاره یو په زړه پورې میکانیزم ووایم. ترتیب په مستقیم ډول د خوندي ډولونو په کارولو سره په جوړه شوې ژبه (Scala) کې ښودل کیږي. دا پوسټ د داسې ترتیب یوه بیلګه وړاندې کوي او د ټولیز پراختیا پروسې کې د ترتیب شوي ترتیب پلي کولو مختلف اړخونو باندې بحث کوي.

د توزیع شوي سیسټم تنظیم کول

(انګلیسي)

پېژندنه

د باور وړ توزیع شوي سیسټم رامینځته کول پدې معنی دي چې ټول نوډونه د نورو نوډونو سره همغږي شوي سم ترتیب کاروي. د DevOps ټیکنالوژي (terraform، ansible یا ورته یو څه) معمولا په اتوماتيک ډول د ترتیب کولو فایلونو رامینځته کولو لپاره کارول کیږي (اکثرا د هر نوډ لپاره ځانګړي). موږ دا هم غواړو ډاډ ترلاسه کړو چې ټول ارتباطي نوډونه ورته پروتوکولونه کاروي (د ورته نسخې په شمول). که نه نو، زموږ په ویشل شوي سیسټم کې به بې اتفاقي رامینځته شي. د 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-bit انټیجرونه دي. د تالیف شوي ترتیب لپاره، د اصالح شوي کتابتون کارول لازمي ندي، مګر دا د ترتیب کونکي وړتیا ته وده ورکوي ترڅو ترتیب وګوري.

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

(سانتي متر. سرچینهپه کوم کې چې نور خدمات پلي کیږي - ایکو خدمت, echo مراجعه
и د ژوند کنټرولونکي.)

نوډ یو څیز دی چې کولی شي ډیری خدمات پیل کړي (د سرچینو لړۍ پیل د کیک نمونې لخوا تضمین شوی):

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. بډایه ترتیب ژبه. په عموم ډول، د ترتیب کولو نور میتودونه په ډیری کې د تار متغیر بدیل پورې محدود دي. کله چې سکالا وکاروئ، ستاسو د تشکیلاتو د ښه کولو لپاره د ژبې پراخه ځانګړتیاوې شتون لري. د مثال په توګه موږ کولی شو وکاروو
    د ډیفالټ ارزښتونو لپاره ځانګړتیاوې، د ګروپ پیرامیټونو لپاره د شیانو په کارولو سره، موږ کولی شو د تړلو په ساحه کې یوازې یو ځل اعلان شوي وال (DRY) ته مراجعه وکړو. تاسو کولی شئ هر ډول ټولګي په مستقیم ډول د ترتیب دننه تنظیم کړئ (Seq, Map، دودیز ټولګي).
  3. DSL. سکالا د ژبې یو شمیر ځانګړتیاوې لري چې د 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 یا متن فایلونو پراساس د دودیز ترتیب کولو میتودونو بدیل په توګه کارول کیدی شي. که څه هم زموږ مثال په سکالا کې پلي کیږي، ورته نظرونه نورو تالیف شویو ژبو ته لیږدول کیدی شي (لکه کوټلین، C#، Swift، ...). تاسو کولی شئ دا طریقه په لاندې پروژو کې هڅه وکړئ، او که دا کار ونه کړي، د متن فایل ته لاړ شئ، ورک شوي برخې اضافه کړئ.

په طبیعي توګه، یو ترتیب شوی ترتیب د لوړ کیفیت پراختیا پروسې ته اړتیا لري. په بدل کې، د تشکیلاتو لوړ کیفیت او اعتبار ډاډمن کیږي.

د پام وړ طریقه پراخه کیدی شي:

  1. تاسو کولی شئ د تالیف وخت چک کولو لپاره میکرو وکاروئ.
  2. تاسو کولی شئ DSL پلي کړئ ترڅو ترتیب په داسې طریقه وړاندې کړئ چې د پای کاروونکو ته د لاسرسي وړ وي.
  3. تاسو کولی شئ د اتوماتیک ترتیب تنظیم کولو سره د متحرک سرچینو مدیریت پلي کړئ. د مثال په توګه، په کلستر کې د نوډونو شمیر بدلولو ته اړتیا لري (1) هر نوډ یو څه توپیر لري؛ (2) د کلستر مدیر د نوي نوډونو په اړه معلومات ترلاسه کړل.

اعترافونه

زه غواړم د اندری ساکسونوف، پاول پاپوف او انتون نیکایوف څخه د مقالې د مسودې په اړه د رغنده نیوکې لپاره مننه وکړم.

سرچینه: www.habr.com

Add a comment