🥇د توزیع شوي سیسټم تالیف وړ ترتیب

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

(په روسي ژبه)

پېژندنه

د قوي توزیع شوي سیسټمونو رامینځته کول په ټولو نوډونو کې د سم او همغږي ترتیب کارولو ته اړتیا لري. یو عادي حل دا دی چې د متني ځای په ځای کولو توضیحات وکاروئ (ټرافارم ، ځواب ویونکي یا یو څه ورته) او په اتوماتيک ډول رامینځته شوي تشکیلاتي فایلونه (اکثرا - د هر نوډ / رول لپاره وقف شوي). موږ به هم غواړو چې په هر ارتباطي نوډونو کې د ورته نسخو ورته پروتوکولونه وکاروو (که نه نو موږ به د نه مطابقت مسلې تجربه کړو). په JVM نړۍ کې د دې معنی دا ده چې لږترلږه د پیغام رسولو کتابتون باید د ټولو مخابراتو نوډونو کې ورته نسخه وي.

د سیسټم ازموینې په اړه څه؟ البته، موږ باید د ادغام ازموینې ته د راتلو دمخه د ټولو اجزاوو لپاره د واحد ازموینې ولرو. د دې لپاره چې د رن ټایم په جریان کې د ازموینې پایلې وڅیړئ، موږ باید ډاډ ترلاسه کړو چې د ټولو کتابتونونو نسخې د رن ټایم او ازموینې چاپیریال دواړو کې یو شان ساتل کیږي.

کله چې د ادغام ازموینې پرمخ وړئ، دا ډیری وختونه خورا اسانه وي چې په ټولو نوډونو کې ورته ټولګي ولري. موږ یوازې دې ته اړتیا لرو چې ډاډ ترلاسه کړو چې ورته ټولګي لاره په ګمارلو کې کارول کیږي. (دا ممکنه ده چې په مختلفو نوډونو کې مختلف کلاسپاټونه وکاروئ، مګر دا خورا ستونزمن کار دی چې د دې ترتیب استازیتوب وکړي او په سمه توګه یې ځای په ځای کړي.) نو د دې لپاره چې شیان ساده وساتل شي موږ به یوازې په ټولو نوډونو کې ورته کلاسپاټ په پام کې ونیسو.

تشکیلات د سافټویر سره یوځای وده کوي. موږ معمولا د مختلف پیژندلو لپاره نسخې کاروو
د سافټویر د تکامل مرحلې. دا مناسب ښکاري چې د نسخې مدیریت لاندې ترتیب پوښښ او د ځینې لیبلونو سره مختلف تشکیلات وپیژني. که چیرې په تولید کې یوازې یو ترتیب شتون ولري، موږ ممکن د پیژندونکي په توګه واحد نسخه وکاروو. ځینې وختونه موږ ممکن د تولید ډیری چاپیریال ولرو. او د هر چاپیریال لپاره موږ ممکن د ترتیب جلا څانګې ته اړتیا ولرو. نو تشکیلات ممکن د څانګې او نسخې سره لیبل شي ترڅو په ځانګړي ډول مختلف تشکیلات وپیژني. د هرې څانګې لیبل او نسخه په هر نوډ کې د توزیع شوي نوډونو ، بندرونو ، بهرنۍ سرچینو ، د کلاس پاټ کتابتون نسخو یو واحد ترکیب سره مطابقت لري. دلته به موږ یوازې یوه څانګه تر پوښښ لاندې ونیسو او تشکیلات به د درې برخې لسیزې نسخې (1.2.3) په واسطه وپیژنو، په ورته ډول د نورو آثارو په څیر.

په عصري چاپیریال کې د ترتیب کولو فایلونه نور په لاسي ډول نه بدلیږي. معمولا موږ تولید کوو
د ځای پرځای کولو په وخت کې د config فایلونه او هیڅکله دوی ته لاس مه ورکوئ وروسته نو یو څوک کولی شي پوښتنه وکړي چې ولې موږ لاهم د ترتیب فایلونو لپاره د متن بڼه کاروو؟ یو ګټور اختیار دا دی چې ترتیب د تالیف کولو واحد کې ځای په ځای کړي او د تالیف وخت ترتیب کولو اعتبار څخه ګټه پورته کړي.

پدې پوسټ کې به موږ په تالیف شوي هنري اثار کې د ترتیب ساتلو نظر معاینه کړو.

د تالیف وړ ترتیب

پدې برخه کې به موږ د جامد ترتیب مثال په اړه بحث وکړو. دوه ساده خدمتونه - د ایکو خدمت او د ایکو خدمت پیرودونکي تنظیم او پلي کیږي. بیا د دواړو خدماتو سره دوه مختلف توزیع شوي سیسټمونه سمدلاسه کیږي. یو د یو واحد نوډ ترتیب لپاره دی او بل یې د دوه نوډونو ترتیب لپاره.

یو عادي ویشل شوی سیسټم د څو نوډونو څخه جوړ دی. نوډونه د ځینې ډولونو په کارولو سره پیژندل کیدی شي:

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)

د پریت ډول

د تالیف پرمهال د پروتوکول پیژندلو لپاره موږ د ډول دلیل اعلان کولو سکالا ځانګړتیا کاروو Protocol چې په ټولګي کې نه کارول کیږي. دا ورته ویل کیږي پریت ډول. د چلولو په وخت کې موږ په ندرت سره د پروتوکول پیژندونکي مثال ته اړتیا لرو ، له همدې امله موږ دا نه ساتو. د تالیف په جریان کې دا فینټم ډول اضافي ډول خوندیتوب ورکوي. موږ نشو کولی د غلط پروتوکول سره بندر تیر کړو.

یو له خورا پراخه کارول شوي پروتوکولونو څخه د Json سیریل کولو سره REST API دی:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

هلته RequestMessage د پیغامونو بنسټیز ډول دی چې پیرودونکي کولی شي سرور ته واستوي او ResponseMessage د سرور څخه د ځواب پیغام دی. البته، موږ ممکن نور پروتوکول توضیحات رامینځته کړو چې د مطلوب دقیقیت سره د مخابراتو پروتوکول مشخص کړي.

د دې پوسټ موخو لپاره موږ به د پروتوکول ساده نسخه وکاروو:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

پدې پروتوکول کې د غوښتنې پیغام یو آر ایل ته ضمیمه شوی او د ځواب پیغام د ساده تار په توګه بیرته راستنیږي.

د خدماتو ترتیب د خدماتو نوم، د بندرونو ټولګه او ځینې انحصارونو لخوا تشریح کیدی شي. دلته یو څو ممکنه لارې شتون لري چې څنګه په سکالا کې د دې ټولو عناصرو استازیتوب وکړي (د مثال په توګه، 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](()))
  }

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

نوډ یو واحد شی دی چې یو څو خدمتونه پرمخ وړي (د سرچینو سلسله پیل کول د کیک نمونې لخوا فعال شوي):

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

په یاد ولرئ چې په نوډ کې موږ د ترتیب دقیق ډول مشخص کوو چې د دې نوډ لخوا ورته اړتیا ده. کمپیلر به موږ ته اجازه ورنکړي چې اعتراض (کیک) د ناکافي ډول سره جوړ کړو، ځکه چې د هر خدمت ځانګړتیا په اړه محدودیت اعلانوي. Config ډول همدارنګه موږ به نشو کولی د بشپړ ترتیب چمتو کولو پرته نوډ پیل کړو.

د نوډ پته حل

د پیوستون رامینځته کولو لپاره موږ د هر نوډ لپاره اصلي کوربه پته ته اړتیا لرو. دا ممکن د ترتیب د نورو برخو په پرتله وروسته وپیژندل شي. له همدې امله، موږ د نوډ ID او دا اصلي پته ترمنځ نقشه چمتو کولو لپاره یوې لارې ته اړتیا لرو. دا نقشه کول یو فعالیت دی:

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

د دې ډول فعالیت پلي کولو لپاره یو څو ممکنه لارې شتون لري.

که موږ د ځای پرځای کولو دمخه حقیقي پتې پیژنو ، د نوډ کوربه توب په جریان کې ، نو موږ کولی شو د ریښتیني ادرسونو سره سکالا کوډ رامینځته کړو او وروسته جوړونه پرمخ یوسو (کوم چې د تالیف وخت چیکونه ترسره کوي او بیا د ادغام ازموینې سویټ پرمخ وړي). پدې حالت کې زموږ د نقشې کولو فعالیت په جامد ډول پیژندل کیږي او یو څه ته ساده کیدی شي لکه a Map[NodeId, NodeAddress].
ځینې وختونه موږ ریښتیني پتې یوازې په وروستي وخت کې ترلاسه کوو کله چې نوډ واقعیا پیل شوی وي ، یا موږ د نوډونو پته نلرو چې لا پیل شوي ندي. پدې حالت کې موږ ممکن د کشف خدمت ولرو چې د نورو ټولو نوډونو څخه دمخه پیل شوی وي او هر نوډ ممکن پدې خدمت کې د دې پته اعلان کړي او د انحصاراتو ګډون وکړي.
که موږ ترمیم کولی شو /etc/hosts، موږ کولی شو له مخکې ټاکل شوي کوربه نومونه وکاروو (لکه my-project-main-node او echo-backend) او یوازې دا نوم د ځای پرځای کولو په وخت کې د IP پتې سره شریک کړئ.

پدې پوسټ کې موږ دا قضیې په نورو جزیاتو کې نه پوښو. په حقیقت کې زموږ د لوبو مثال کې ټول نوډونه به ورته IP پته ولري - 127.0.0.1.

پدې پوسټ کې به موږ دوه ویشل شوي سیسټم ترتیبونه په پام کې ونیسو:

د واحد نوډ ترتیب، چیرې چې ټول خدمتونه په واحد نوډ کې ځای پرځای شوي.
دوه نوډ ترتیب، چیرې چې خدمت او پیرودونکي په مختلف نوډونو کې دي.

د یو لپاره ترتیب واحد نوډ ترتیب په لاندې ډول دی:

د واحد نوډ ترتیب

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

وګورئ چې موږ څنګه انحصار مشخص کوو. موږ د نورو نوډ چمتو شوي خدمت د اوسني نوډ انحصار په توګه ذکر کوو. د انحصار ډول چک شوی ځکه چې دا د فینټم ډول لري چې پروتوکول تشریح کوي. او د چلولو په وخت کې به موږ سم نوډ 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، پداسې حال کې چې د اکو مراجع به د تنظیم شوي محدودې مودې وروسته پای ته ورسیږي. وګورئ د سټارټر غوښتنلیک د تفصیلاتو لپاره.

د ټولیز پرمختګ بهیر

راځئ وګورو چې دا طریقه څنګه د ترتیب سره کار کولو لاره بدلوي.

د کوډ په توګه ترتیب به تالیف شي او یو آثار تولید کړي. دا مناسب ښکاري چې د نورو کوډ آثارو څخه د ترتیب کولو آثار جلا کړئ. ډیری وختونه موږ کولی شو په ورته کوډ بیس کې ډیری تشکیلات ولرو. او البته، موږ کولی شو د مختلفو تشکیلاتو څانګو ډیری نسخې ولرو. په یو ترتیب کې موږ کولی شو د کتابتونونو ځانګړي نسخې وټاکو او دا به ثابت پاتې شي کله چې موږ دا ترتیب ځای په ځای کړو.

د ترتیب بدلون د کوډ بدلون بدلیږي. نو دا باید د ورته کیفیت تضمین پروسې لخوا پوښل شي:

ټکټ -> PR -> بیاکتنه -> ضمیمه -> دوامداره ادغام -> دوامداره ګمارنه

د چلند لاندې پایلې شتون لري:

تشکیلات د یو ځانګړي سیسټم مثال لپاره همغږي دي. داسې ښکاري چې د نوډونو تر مینځ د غلط ارتباط لپاره کومه لاره نشته.
یوازې په یوه نوډ کې د تشکیلاتو بدلول اسانه ندي. دا غیر معقول بریښي چې ننوتل او د ځینې متن فایلونو بدلول. نو د تشکیلاتو جریان لږ امکان لري.
کوچني تشکیلات بدلونونه اسانه ندي.
د تشکیلاتو ډیری بدلونونه به د ورته پراختیا پروسې تعقیب کړي، او دا به یو څه بیاکتنه تیر کړي.

ایا موږ د تولید ترتیب لپاره جلا ذخیره ته اړتیا لرو؟ د تولید ترتیب ممکن حساس معلومات ولري چې موږ غواړو د ډیری خلکو له لاسرسي څخه لرې وساتو. نو دا ممکن د محدود لاسرسي سره د جلا ذخیره ساتلو ارزښت ولري چې د تولید ترتیب به پکې وي. موږ ممکن ترتیب په دوه برخو وویشو - یو چې د تولید خورا خلاص پیرامیټونه لري او بل چې د ترتیب پټ برخه لري. دا به ډیری پراختیا کونکو ته د پیرامیټونو لوی اکثریت ته لاسرسی وړ کړي پداسې حال کې چې واقعیا حساس شیانو ته لاسرسی محدودوي. د ډیفالټ پیرامیټر ارزښتونو سره د مینځنۍ ځانګړتیاو په کارولو سره دا ترسره کول اسانه دي.

تغیرات

راځئ چې د نورو ترتیب مدیریت تخنیکونو په پرتله د وړاندیز شوي چلند ګټې او زیانونه وګورو.

تر ټولو لومړی، موږ به د ترتیب سره د معاملې کولو وړاندیز شوي لارې مختلف اړخونو ته یو څو بدیلونه لیست کړو:

د هدف په ماشین کې د متن فایل.
مرکزي شوي کلیدي ارزښت ذخیره (لکه etcd/zookeeper).
د فرعي پروسس برخې چې د پروسې بیا پیل کولو پرته بیا تنظیم شوي / بیا پیل کیدی شي.
د آثارو او نسخو کنټرول بهر ترتیب.

د متن فایل د اډ هاک اصلاحاتو شرایطو کې یو څه انعطاف ورکوي. د سیسټم مدیر کولی شي د هدف نوډ ته ننوځي، بدلون راولي او په ساده ډول خدمت بیا پیل کړي. دا ممکن د لوی سیسټمونو لپاره ښه نه وي. د بدلون څخه هیڅ نښه نه پاتې کیږي. بدلون د بلې جوړې د سترګو لخوا نه کتل کیږي. دا ممکن ستونزمن وي چې معلومه کړي چې د بدلون لامل څه دی. دا ازموینه نه ده شوې. د توزیع شوي سیسټم له لید څخه یو مدیر کولی شي په ساده ډول په یو بل نوډونو کې ترتیب تازه کول هیر کړي.

(Btw، که په نهایت کې د متن ترتیب فایلونو کارولو پیل کولو ته اړتیا وي، موږ به یوازې د پارسر + تاییدونکي اضافه کړو چې کولی شي ورته تولید کړي. Config ټایپ او دا به د متن تشکیلاتو کارولو پیل کولو لپاره کافي وي. دا دا هم ښیې چې د تالیف وخت ترتیب کولو پیچلتیا د متن پراساس تشکیلاتو پیچلتیا یو څه کوچنۍ ده ، ځکه چې د متن پراساس نسخه کې موږ یو څه اضافي کوډ ته اړتیا لرو.)

د مرکزي کلیدي ارزښت ذخیره کول د غوښتنلیک میټا پیرامیټونو ویشلو لپاره یو ښه میکانیزم دی. دلته موږ باید د هغه څه په اړه فکر وکړو چې موږ یې د ترتیب ارزښتونو ته ګورو او یوازې ډاټا څه ده. فعالیت ورکړ C => A => B موږ معمولا په ندرت سره بدلیدونکي ارزښتونه وایو C "تنظیم"، پداسې حال کې چې په مکرر ډول ډاټا بدلیږي A - یوازې ډاټا داخل کړئ. ترتیب باید د معلوماتو څخه دمخه فعالیت ته چمتو شي A. د دې مفکورې په پام کې نیولو سره موږ کولی شو ووایو چې دا د بدلونونو متوقع فریکونسۍ ده چې یوازې د ډیټا څخه د ترتیب ډیټا توپیر کولو لپاره کارول کیدی شي. همدارنګه ډاټا عموما د یوې سرچینې (کاروونکي) څخه راځي او ترتیب د بلې سرچینې (اډمین) څخه راځي. د پیرامیټونو سره معامله کول چې د پیل کولو پروسې وروسته بدل کیدی شي د غوښتنلیک پیچلتیا ډیروالي لامل کیږي. د داسې پیرامیټونو لپاره موږ باید د دوی تحویلي میکانیزم اداره کړو ، پارس کول او تایید کول ، د غلط ارزښتونو اداره کول. له همدې امله، د پروګرام پیچلتیا کمولو لپاره، موږ به د پیرامیټونو شمیر کم کړو چې د چلولو په وخت کې بدلون موندلی شي (یا حتی دوی په بشپړ ډول له منځه یوسي).

د دې پوسټ له نظره موږ باید د جامد او متحرک پیرامیټونو ترمنځ توپیر وکړو. که د خدماتو منطق د چلولو په وخت کې د ځینې پیرامیټونو نادر بدلون ته اړتیا ولري، نو موږ ممکن دوی ته متحرک پیرامیټونه ووایو. که نه نو دوی جامد دي او د وړاندیز شوي طریقې په کارولو سره تنظیم کیدی شي. د متحرک بیا تنظیم کولو لپاره ممکن نورو لارو ته اړتیا وي. د مثال په توګه، د سیسټم برخې ممکن د نوي ترتیب کولو پیرامیټرو سره بیا پیل شي په ورته ډول د ویشل شوي سیسټم جلا پروسې بیا پیل کولو لپاره.
(زما عاجز نظر دا دی چې د وخت له تنظیم کولو څخه مخنیوی وشي ځکه چې دا د سیسټم پیچلتیا زیاتوي.
دا ممکن خورا ساده وي چې یوازې د بیا پیل کولو پروسو د OS ملاتړ باندې تکیه وکړئ. که څه هم، دا ممکن تل ممکن نه وي.)

د جامد ترتیب کارولو یو مهم اړخ چې ځینې وختونه خلک د متحرک تشکیلاتو په اړه فکر کوي (پرته له نورو دلیلونو) د تشکیلاتو تازه کولو پرمهال د خدماتو ځنډول دي. په حقیقت کې، که موږ په جامد ترتیب کې بدلونونه رامنځته کړو، موږ باید سیسټم بیا پیل کړو ترڅو نوي ارزښتونه اغیزمن شي. د ځنډولو اړتیاوې د مختلف سیسټمونو لپاره توپیر لري، نو دا ممکن دومره مهم نه وي. که دا مهم وي، نو موږ باید د هر سیسټم بیا پیل کولو لپاره مخکې پالن وکړو. د مثال په توګه، موږ کولی شو پلي کړو د AWS ELB پیوستون وچول. په دې سناریو کې هرکله چې موږ سیسټم بیا پیلولو ته اړتیا لرو، موږ په موازي ډول د سیسټم نوې بیلګه پیل کوو، بیا یې ELB ته واړوو، پداسې حال کې چې زاړه سیسټم ته اجازه ورکوو چې د موجوده ارتباطاتو خدمت بشپړ کړي.

د نسخه شوي آثارو دننه یا بهر د ترتیب ساتلو په اړه څه؟ د یو هنري اثارو دننه ترتیب ساتل په ډیری قضیو کې پدې معنی دي چې دا ترتیب د نورو هنري اثارو په څیر د کیفیت تضمین پروسې څخه تیر شوی. نو یو څوک شاید ډاډه وي چې ترتیب د ښه کیفیت او باور وړ دی. برعکس په جلا فایل کې ترتیب کول پدې معنی دي چې هیڅ نښې شتون نلري چې چا او ولې پدې فایل کې بدلونونه کړي. ایا دا مهم دی؟ موږ باور لرو چې د ډیری تولید سیسټمونو لپاره دا غوره ده چې باثباته او لوړ کیفیت ترتیب ولرئ.

د هنري اثارو نسخه اجازه ورکوي چې معلومه کړي کله چې دا رامینځته شوی ، کوم ارزښتونه پکې شامل دي ، کوم ځانګړتیاوې فعال / غیر فعال شوي ، څوک چې په ترتیب کې د هر بدلون لپاره مسؤل و. دا ممکن یو څه هڅو ته اړتیا ولري ترڅو د هنري اثارو دننه ترتیب وساتي او دا د ډیزاین انتخاب دی.

مسلکي او شفاهي

دلته موږ غواړو د وړاندیز شوې طریقې ځینې ګټې په ګوته کړو او ځینې زیانونه یې په ګوته کړو.

ګټي

د بشپړ توزیع شوي سیسټم د تالیف وړ تشکیلاتو ځانګړتیاوې:

د ترتیب جامد چک. دا د باور لوړه کچه ورکوي، چې ترتیب د ډول ډول محدودیتونو سره سم دی.
د ترتیب بډایه ژبه. په عموم ډول د ترتیب کولو نورې لارې په ډیری متغیر بدیل پورې محدودې دي.
د سکالا په کارولو سره یو څوک کولی شي د ترتیب غوره کولو لپاره د ژبې پراخه پراخه لړۍ وکاروي. د مثال په توګه، موږ کولی شو د ډیفالټ ارزښتونو چمتو کولو لپاره ځانګړتیاوې وکاروو، د مختلف اندازې ټاکلو لپاره توکي، موږ کولی شو مراجعه وکړو vals یوازې یو ځل په بهرنۍ ساحه (DRY) کې تعریف شوی. دا ممکنه ده چې لفظي ترتیبونه وکاروئ، یا د ځانګړو ټولګیو مثالونه (Seq, Mapاو نور).
DSL. سکالا د DSL لیکوالانو لپاره ښه ملاتړ لري. یو څوک کولی شي دا ځانګړتیاوې د ترتیب کولو ژبه رامینځته کولو لپاره وکاروي چې خورا اسانه او د پای کارونکي دوستانه وي ، نو وروستی ترتیب لږترلږه د ډومین کاروونکو لخوا د لوستلو وړ وي.
په نوډونو کې بشپړتیا او همغږي. په یو ځای کې د ټول ویشل شوي سیسټم لپاره د ترتیب کولو یوه ګټه دا ده چې ټول ارزښتونه یو ځل په کلکه تعریف شوي او بیا په ټولو ځایونو کې بیا کارول کیږي چیرې چې موږ ورته اړتیا لرو. همدارنګه د خوندي بندر اعالمیې ټایپ کړئ ډاډ ترلاسه کړئ چې په ټولو ممکنه سمو ترتیبونو کې د سیسټم نوډونه به ورته ژبه خبرې کوي. د نوډونو تر مینځ واضح انحصار شتون لري کوم چې د ځینې خدماتو چمتو کول هیرول ستونزمن کوي.
د بدلونونو لوړ کیفیت. د عادي PR پروسې له لارې د ترتیب کولو بدلونونو تیرولو عمومي چلند په ترتیب کې هم د کیفیت لوړ معیارونه رامینځته کوي.
په ورته وخت کې د تشکیلاتو بدلون. هرکله چې موږ په ترتیب کې کوم بدلون راوړو اتوماتیک ګمارنه ډاډ ورکوي چې ټول نوډونه تازه کیږي.
د غوښتنلیک ساده کول. غوښتنلیک اړتیا نلري چې تنظیمات تحلیل او تایید کړي او د غلط ترتیب ارزښتونو اداره کړي. دا ټول غوښتنلیک ساده کوي. (د یو څه پیچلتیا زیاتوالی پخپله په ترتیب کې دی، مګر دا د خوندیتوب په لور یو هوښیار تجارت دی.) عادي ترتیب ته راستنیدل خورا ساده دي - یوازې ورک شوي ټوټې اضافه کړئ. د تالیف شوي ترتیب سره پیل کول اسانه دي او د اضافي ټوټو پلي کول ځینې وروسته وختونو ته وځنډول.
نسخه ترتیب. د دې حقیقت له امله چې د تشکیلاتو بدلونونه د ورته پراختیا پروسې تعقیبوي، په پایله کې موږ د ځانګړي نسخې سره هنر ترلاسه کوو. دا موږ ته اجازه راکوي چې د اړتیا په صورت کې ترتیب بیرته بدل کړو. موږ حتی کولی شو یو ترتیب ځای په ځای کړو چې یو کال دمخه کارول شوی و او دا به په ورته ډول کار وکړي. مستحکم ترتیب د توزیع شوي سیسټم وړاندوینې او اعتبار ته وده ورکوي. تشکیلات د تالیف په وخت کې ټاکل شوي او نشي کولی په اسانۍ سره د تولید سیسټم کې لاسوهنه وکړي.
انډول. وړاندیز شوی چوکاټ ماډلر دی او ماډلونه په مختلفو لارو سره یوځای کیدی شي
د مختلف تشکیلاتو ملاتړ کوي (سیټ اپ / ترتیبونه). په ځانګړې توګه، دا ممکنه ده چې د کوچنۍ پیمانه واحد نوډ ترتیب او په لویه پیمانه ملټي نوډ ترتیب ولرئ. دا مناسب دی چې د ډیری تولید ترتیبونه ولرئ.
ازموینه. د ازموینې اهدافو لپاره یو څوک ممکن جعلي خدمت پلي کړي او دا په خوندي ډول د انحصار په توګه وکاروي. یو څو مختلف ازموینې ترتیبونه د مختلف برخو سره د موکس لخوا ځای په ځای شوي په ورته وخت کې ساتل کیدی شي.
د ادغام ازموینه. ځینې وختونه په ویشل شوي سیسټمونو کې د ادغام ازموینې چلول ستونزمن وي. د بشپړ توزیع شوي سیسټم خوندي تنظیم کولو ټایپ کولو لپاره د بیان شوي طریقې په کارولو سره ، موږ کولی شو ټولې توزیع شوي برخې په یو واحد سرور کې د کنټرول وړ لارې پرمخ یوسو. د وضعیت تقلید کول اسانه دي
کله چې یو له خدماتو څخه شتون نلري.

زيانونه

د ترتیب شوي ترتیب کولو طریقه د "نورمال" ترتیب څخه توپیر لري او دا ممکن د ټولو اړتیاو سره سم نه وي. دلته د ترتیب شوي ترتیب ځینې زیانونه دي:

جامد ترتیب. دا ممکن د ټولو غوښتنلیکونو لپاره مناسب نه وي. په ځینو مواردو کې د ټولو خوندیتوب اقداماتو په پام کې نیولو سره په تولید کې د تنظیم کولو ګړندي تنظیم کولو ته اړتیا شتون لري. دا طریقه نوره هم ستونزمنه کوي. تالیف او بیا ځای په ځای کول په ترتیب کې د هر ډول بدلون وروسته اړین دي. دا دواړه ځانګړتیا او بار دی.
د تنظیم کولو نسل. کله چې تشکیل د ځینې اتوماتیک وسیلې لخوا رامینځته کیږي دا طریقه راتلونکي تالیف ته اړتیا لري (کوم چې ممکن په پایله کې ناکام شي). دا ممکن اضافي هڅې ته اړتیا ولري ترڅو دا اضافي ګام د جوړونې سیسټم کې مدغم کړي.
وسایل. نن ورځ په کارونې کې ډیری وسیلې شتون لري چې د متن پراساس تشکیلاتو تکیه کوي. ځینې یې
کله چې ترتیب ترتیب شوی وي د تطبیق وړ نه وي.
په ذهنیت کې بدلون ته اړتیا ده. پراختیا کونکي او DevOps د متن ترتیب کولو فایلونو سره آشنا دي. د ترتیب کولو ترتیب کولو نظر ممکن دوی ته عجیب ښکاري.
د تالیف وړ تشکیلاتو معرفي کولو دمخه د لوړ کیفیت سافټویر پراختیا پروسې ته اړتیا ده.

د پلي شوي مثال ځینې محدودیتونه شتون لري:

که موږ اضافي تشکیل چمتو کړو چې د نوډ پلي کولو لخوا غوښتنه نه کیږي ، کمپیلر به موږ سره د غیر حاضر پلي کیدو په موندلو کې مرسته ونه کړي. دا د کارولو له لارې حل کیدی شي HList یا ADTs (د قضیې ټولګي) د ځانګړتیاو او کیک نمونو پرځای د نوډ ترتیب لپاره.
موږ باید په ترتیب فایل کې یو څه بویلر پلیټ چمتو کړو: (package, import, object اعلامیې
override defد پیرامیټونو لپاره چې اصلي ارزښتونه لري). دا ممکن په جزوي ډول د DSL په کارولو سره حل شي.
پدې پوسټ کې موږ د ورته نوډونو کلسترونو متحرک بیا تنظیم نه پوښو.

پایله

پدې پوسټ کې موږ په مستقیم ډول د سرچینې کوډ کې د ډول خوندي ډول کې د ترتیب نمایندګي کولو مفکورې په اړه بحث کړی. کړنلاره په ډیری غوښتنلیکونو کې د xml- او نورو متن پراساس تشکیلاتو بدلولو په توګه کارول کیدی شي. سره له دې چې زموږ مثال په سکالا کې پلي شوی، دا نورو تالیف وړ ژبو ته هم ژباړل کیدی شي (لکه کوټلین، C#، Swift، او نور). یو څوک کولی شي دا طریقه په یوه نوې پروژه کې هڅه وکړي او که چیرې دا ښه نه وي، زاړه طریقې ته لاړ شئ.

البته، د تالیف وړ ترتیب د لوړ کیفیت پراختیا پروسې ته اړتیا لري. په بدل کې دا ژمنه کوي چې د مساوي لوړ کیفیت قوي ترتیب چمتو کړي.

دا طریقه په مختلفو لارو غزول کیدی شي:

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

مننه

زه غواړم له اندری ساکسونوف، پاول پاپوف، انتون نیهایف څخه مننه وکړم چې د دې پوسټ مسودې په اړه الهام بخښونکي نظرونه راکړل چې ما سره یې د دې په روښانه کولو کې مرسته وکړه.

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