ورهايل نظام جي مرتب ڪيل ترتيب

هن پوسٽ ۾ اسان حصيداري ڪرڻ چاهيون ٿا هڪ دلچسپ طريقي سان ڊيل ڪرڻ جو هڪ ورهايل سسٽم جي ترتيب سان.
ٺاھ جوڙ سڌي طرح اسڪالا ٻولي ۾ ھڪڙي قسم جي محفوظ انداز ۾ پيش ڪئي وئي آھي. هڪ مثال تي عملدرآمد تفصيل سان بيان ڪيو ويو آهي. پروپوزل جي مختلف حصن تي بحث ڪيو ويو آهي، بشمول مجموعي ترقي جي عمل تي اثر.

(روسي ۾)

تعارف

مضبوط ورهايل سسٽم ٺاهڻ جي ضرورت آهي سڀني نوڊس تي صحيح ۽ مربوط ترتيب جي استعمال جي. هڪ عام حل استعمال ڪرڻ آهي متن جي ترتيب جي وضاحت (ٽرافارم، جوابي يا هڪجهڙائي واري شيءِ) ۽ خودڪار ٺاهيل ترتيب واري فائلون (اڪثر - هر نوڊ / ڪردار لاءِ وقف ٿيل). اسان پڻ استعمال ڪرڻ چاهيون ٿا ساڳيون نسخن جا ساڳيا پروٽوڪول هر ڪميونيڪيشن نوڊس تي (ٻي صورت ۾ اسان غير مطابقت جي مسئلن جو تجربو ڪنداسين). JVM دنيا ۾ هن جو مطلب آهي ته گهٽ ۾ گهٽ پيغام رسائيندڙ لائبريري سڀني ڪميونيڪيشن نوڊس تي ساڳيو نسخو هجڻ گهرجي.

سسٽم کي جانچڻ بابت ڇا؟ يقينن، اسان کي انضمام ٽيسٽ تي اچڻ کان اڳ سڀني اجزاء لاء يونٽ ٽيسٽ هجڻ گهرجي. رن ٽائم تي ٽيسٽ جا نتيجا ڪڍڻ لاءِ، اسان کي پڪ ڪرڻ گهرجي ته سڀني لائبريرين جا ورجن رن ٽائم ۽ ٽيسٽنگ ماحول ۾ هڪجهڙا رکيا وڃن.

جڏهن انٽيگريشن ٽيسٽ هلائي رهيا آهن، اهو اڪثر آسان آهي ته سڀني نوڊس تي ساڳيو ڪلاس پاٿ هجي. اسان کي صرف پڪ ڪرڻ جي ضرورت آهي ته ساڳي طبقي جو رستو استعمال ڪيو ويندو آهي. (ممڪن آهي ته مختلف نوڊس تي مختلف ڪلاس پاٿ استعمال ڪرڻ، پر هن ترتيب جي نمائندگي ڪرڻ ۽ ان کي صحيح طرح سان ترتيب ڏيڻ وڌيڪ مشڪل آهي.) تنهنڪري شين کي سادو رکڻ لاءِ اسان سڀني نوڊس تي صرف هڪجهڙا ڪلاس پاٿ سمجهنداسين.

ٺاھ جوڙ سافٽ ويئر سان گڏ ترقي ڪري ٿو. اسان عام طور تي مختلف قسم جي سڃاڻپ ڪرڻ لاء نسخن کي استعمال ڪندا آهيون
سافٽ ويئر جي ارتقاء جا مرحلا. اهو مناسب لڳي ٿو ورزن مينيجمينٽ جي ترتيب هيٺ ترتيب ڏيڻ ۽ ڪجهه ليبلن سان مختلف ترتيبن جي نشاندهي ڪرڻ. جيڪڏهن پيداوار ۾ صرف هڪ ترتيب آهي، اسان هڪ سڃاڻپ ڪندڙ طور استعمال ڪري سگهون ٿا. ڪڏهن ڪڏهن اسان وٽ ڪيترائي پيداوار ماحول هوندا. ۽ هر ماحول لاءِ اسان کي ترتيب جي الڳ شاخ جي ضرورت پوندي. تنهن ڪري ترتيبن کي شاخ ۽ ورزن سان ليبل ڪري سگهجي ٿو مختلف ترتيبن کي منفرد طور سڃاڻڻ لاءِ. هر برانچ ليبل ۽ ورزن ورهايل نوڊس، بندرگاهن، خارجي وسيلن، هر نوڊ تي ڪلاس پاٿ لائبريري ورزن جي هڪ واحد ميلاپ سان ملندڙ جلندڙ آهي. هتي اسان صرف هڪ شاخ کي ڍڪينداسين ۽ ٽن حصن جي ڊيسيمل ورزن (1.2.3) ذريعي ترتيبن جي سڃاڻپ ڪنداسين، ساڳئي طرح ٻين نموني وانگر.

جديد ماحول ۾ ڪنفيگريشن فائلن کي دستي طور تبديل نه ڪيو ويو آهي. عام طور تي اسان ٺاهيندا آهيون
ترتيب ڏيڻ واري وقت تي فائلون ترتيب ڏيو ۽ انهن کي ڪڏهن به نه ڇڪيو بعد ۾ تنهن ڪري ڪو پڇي سگهي ٿو ته اسان اڃا تائين ترتيب واري فائلن لاءِ ٽيڪسٽ فارميٽ ڇو استعمال ڪريون ٿا؟ هڪ قابل عمل اختيار اهو آهي ته ترتيب کي ترتيب ڏيڻ واري يونٽ جي اندر رکڻ ۽ مرتب ڪرڻ واري وقت جي ترتيب جي تصديق مان فائدو حاصل ڪرڻ.

هن تحرير ۾ اسين مرتب ڪيل آرٽيڪل ۾ ترتيب کي برقرار رکڻ جي خيال کي جانچ ڪنداسين.

ترتيب ڏيڻ واري ترتيب

هن حصي ۾ اسين جامد ترتيب جي هڪ مثال تي بحث ڪنداسين. ٻه سادي خدمتون - گونج سروس ۽ گونج سروس جو ڪلائنٽ ترتيب ۽ لاڳو ڪيو پيو وڃي. پوءِ ٻنهي خدمتن سان گڏ ٻه مختلف ورهايل نظام فوري طور تي آهن. ھڪڙي ھڪڙي ھڪڙي نوڊ جي ٺاھ جوڙ لاء آھي ۽ ٻيو ھڪڙو ٻن نوڊس جي جوڙجڪ لاء.

هڪ عام ورهايل نظام چند نوڊس تي مشتمل آهي. نوڊس جي سڃاڻپ ٿي سگھي ٿي ڪجھ قسم استعمال ڪندي:

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

يا بس

case class NodeId(hostName: String)

يا اڃا به

object Singleton
type NodeId = Singleton.type

اهي نوڊس مختلف ڪردار ادا ڪن ٿا، ڪجهه خدمتون هلائين ٿا ۽ TCP/HTTP ڪنيڪشن ذريعي ٻين نوڊس سان رابطو ڪرڻ جي قابل هجن.

TCP ڪنيڪشن لاءِ گهٽ ۾ گهٽ هڪ پورٽ نمبر گهربل آهي. اسان پڻ پڪ ڪرڻ چاهيون ٿا ته ڪلائنٽ ۽ سرور ساڳيا پروٽوڪول ڳالهائي رهيا آهن. نوڊس جي وچ ۾ ڪنيڪشن کي ماڊل ڪرڻ لاءِ اچو ته هيٺين طبقي جو اعلان ڪريون:

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

جتي Port صرف هڪ آهي Int اجازت ڏنل حد اندر:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

سڌريل قسم

ڏسو بهتر بڻيل لائبريري. مختصر ۾، اهو ٻين قسمن جي گڏ ڪرڻ جي وقت جي پابنديون شامل ڪرڻ جي اجازت ڏئي ٿو. هن معاملي ۾ Int صرف 16-bit قدرن جي اجازت آھي جيڪا پورٽ نمبر جي نمائندگي ڪري سگھي ٿي. ھن لئبرري کي استعمال ڪرڻ جي ڪا ضرورت نه آھي ھن ترتيب واري انداز لاءِ. اهو لڳي ٿو ته اهو بلڪل مناسب آهي.

HTTP (REST) ​​لاءِ اسان کي شايد خدمت جي رستي جي ضرورت پوندي:

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

پريت جو قسم

تاليف دوران پروٽوڪول کي سڃاڻڻ لاءِ اسين استعمال ڪري رهيا آهيون اسڪالا فيچر جو اعلان ڪرڻ واري قسم جو دليل Protocol جيڪو ڪلاس ۾ استعمال نٿو ٿئي. اهو هڪ سڏيو ويندو آهي پريتم جو قسم. رن ٽائم تي اسان کي گهٽ ۾ گهٽ پروٽوڪول سڃاڻپ ڪندڙ جي مثال جي ضرورت آهي، ان ڪري اسان ان کي ذخيرو نٿا ڪريون. تاليف دوران هن پريتم جو قسم اضافي قسم جي حفاظت ڏئي ٿو. اسان غلط پروٽوڪول سان پورٽ پاس نٿا ڪري سگھون.

سڀ کان وڏي پيماني تي استعمال ٿيندڙ پروٽوڪولز مان هڪ REST API آهي Json serialization سان:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

جتي RequestMessage پيغامن جو بنيادي قسم آھي جيڪو ڪلائنٽ سرور ڏانھن موڪلي سگھي ٿو ۽ ResponseMessage سرور کان جوابي پيغام آهي. يقينن، اسان ٻين پروٽوڪول وضاحتون ٺاهي سگهون ٿا جيڪي رابطي واري پروٽوڪول کي گهربل درستگي سان بيان ڪن ٿيون.

هن پوسٽ جي مقصدن لاءِ اسان پروٽوڪول جو هڪ آسان ورزن استعمال ڪنداسين:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

هن پروٽوڪول ۾ درخواست جو پيغام url ۾ شامل ڪيو ويو آهي ۽ جوابي پيغام کي سادي اسٽرنگ طور واپس ڪيو ويو آهي.

خدمت جي تشڪيل کي بيان ڪري سگهجي ٿو خدمت جو نالو، بندرگاهن جو مجموعو ۽ ڪجهه انحصار. اسڪالا ۾ انهن سڀني عنصرن جي نمائندگي ڪرڻ جا ڪجھ ممڪن طريقا آهن (مثال طور، HList، الجبرائي ڊيٽا جا قسم). هن پوسٽ جي مقصدن لاءِ اسان ڪيڪ جو نمونو استعمال ڪنداسين ۽ گڏيل ٽڪرن (ماڊيول) کي خاصيتن جي طور تي پيش ڪنداسين. (ڪيڪ جو نمونو هن ترتيب ڏيڻ واري ترتيب واري طريقي جي گهرج نه آهي. اهو صرف هڪ خيال جو ممڪن عمل آهي.)

انحصار کي ڪيڪ پيٽرن کي استعمال ڪندي نمائندگي ڪري سگھجي ٿو ٻين نوڊس جي آخري پوائنٽ جي طور تي:

  type EchoProtocol[A] = SimpleHttpGetRest[A, A]

  trait EchoConfig[A] extends ServiceConfig {
    def portNumber: PortNumber = 8081
    def echoPort: PortWithPrefix[EchoProtocol[A]] = PortWithPrefix[EchoProtocol[A]](portNumber, "echo")
    def echoService: HttpSimpleGetEndPoint[NodeId, EchoProtocol[A]] = providedSimpleService(echoPort)
  }

گونج سروس کي صرف هڪ پورٽ ترتيب ڏيڻ جي ضرورت آهي. ۽ اسان اعلان ڪريون ٿا ته هي پورٽ گونج پروٽوڪول کي سپورٽ ڪري ٿو. ياد رکو ته اسان کي هن وقت ڪنهن خاص پورٽ جي وضاحت ڪرڻ جي ضرورت ناهي، ڇاڪاڻ ته خاصيت جي اجازت ڏئي ٿي خلاصي طريقن جي بيانن کي. جيڪڏهن اسان تجريدي طريقا استعمال ڪندا آهيون، مرتب ڪندڙ کي ترتيب ڏيڻ واري مثال ۾ عمل درآمد جي ضرورت پوندي. هتي اسان مهيا ڪيو آهي عملدرآمد (8081) ۽ ان کي ڊفالٽ قدر طور استعمال ڪيو ويندو جيڪڏھن اسان ان کي ڪنڪريٽ ٺاھ جوڙ ۾ ڇڏي ڏيون.

اسان گونج سروس ڪلائنٽ جي تشڪيل ۾ انحصار جو اعلان ڪري سگھون ٿا:

  trait EchoClientConfig[A] {
    def testMessage: String = "test"
    def pollInterval: FiniteDuration
    def echoServiceDependency: HttpSimpleGetEndPoint[_, EchoProtocol[A]]
  }

انحصار ساڳئي قسم جي آهي echoService. خاص طور تي، اهو ساڳيو پروٽوڪول گهرندو آهي. انهيء ڪري، اسان پڪ ڪري سگهون ٿا ته جيڪڏهن اسان انهن ٻن انحصار کي ڳنڍيندا آهيون ته اهي صحيح ڪم ڪندا.

خدمتن تي عملدرآمد

ھڪڙي خدمت کي شروع ڪرڻ ۽ شاندار طور تي بند ڪرڻ لاء ھڪڙي فنڪشن جي ضرورت آھي. (هڪ خدمت کي بند ڪرڻ جي صلاحيت جانچ لاءِ نازڪ آهي.) ٻيهر ڏنل ترتيب لاءِ اهڙي فنڪشن کي بيان ڪرڻ جا ڪجهه آپشن آهن (مثال طور، اسان قسم جا ڪلاس استعمال ڪري سگهون ٿا). هن پوسٽ لاءِ اسان ٻيهر استعمال ڪنداسين ڪيڪ جو نمونو. اسان استعمال ڪندي خدمت جي نمائندگي ڪري سگھون ٿا cats.Resource جيڪو اڳ ۾ ئي بريڪٽنگ ۽ وسيلا جاري ڪري ٿو. ھڪڙو وسيلو حاصل ڪرڻ لاءِ اسان کي ھڪڙي ترتيب ڏيڻ گھرجي ۽ ڪجھ رن ٽائم جي حوالي سان. تنهنڪري خدمت جي شروعاتي فنڪشن هن طرح نظر اچي سگهي ٿي:

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

جتي

• Config - ترتيب جو قسم جيڪو هن سروس اسٽارٽر طرفان گهربل آهي
• AddressResolver - هڪ رن ٽائم اعتراض جيڪو ٻين نوڊس جا حقيقي پتا حاصل ڪرڻ جي صلاحيت رکي ٿو (تفصيل لاءِ پڙهو).

ٻين قسمن مان اچي ٿو cats:

• F[_] - اثر جو قسم (سڀ کان آسان صورت ۾ F[A] صرف ٿي سگهي ٿو () => A. هن پوسٽ ۾ اسان استعمال ڪنداسين cats.IO.)
• Reader[A,B] - هڪ فنڪشن لاء گهٽ يا گهٽ هڪ مترادف آهي A => B
• cats.Resource - حاصل ڪرڻ ۽ ڇڏڻ جا طريقا آھن
• Timer - سمهڻ جي اجازت ڏئي ٿو / وقت ماپڻ
• ContextShift - اينالاگ جو ExecutionContext
• Applicative - اثر ۾ افعال جو لفافي (تقريبا هڪ مونڊ) (اسان آخرڪار ان کي ڪنهن ٻئي سان تبديل ڪري سگهون ٿا)

ھن انٽرفيس کي استعمال ڪندي اسين ڪجھ خدمتون لاڳو ڪري سگھون ٿا. مثال طور، هڪ خدمت جيڪا ڪجھ به نه ڪندي:

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config <: Any
    def resource(...): ResourceReader[F, Config, Unit] =
      Reader(_ => Resource.pure[F, Unit](()))
  }

(ڏسو سورس ڪوڊ ٻين خدمتن جي نفاذ لاءِ - گونج سروس,
گونج ڪلائنٽ ۽ حياتياتي سنڀاليندڙ.)

ھڪڙو نوڊ ھڪڙو اعتراض آھي جيڪو ڪجھ خدمتون ھلائيندو آھي (وسيلن جو سلسلو شروع ڪرڻ ڪيڪ پيٽرن پاران چالو ڪيو ويو آھي):

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

نوٽ ڪريو ته نوڊ ۾ اسان ٺاھ جوڙ جو صحيح قسم بيان ڪريون ٿا جيڪو ھن نوڊ کي گھربل آھي. ڪمپلر اسان کي نا مناسب قسم سان اعتراض (ڪيڪ) ٺاهڻ جي اجازت نه ڏيندو، ڇاڪاڻ ته هر خدمت جي خاصيت تي پابندي جو اعلان ڪري ٿو. Config قسم. انهي سان گڏ اسان مڪمل ترتيب ڏيڻ کان سواء نوڊ شروع ڪرڻ جي قابل نه هوندا.

نوڊ ايڊريس قرارداد

ڪنيڪشن قائم ڪرڻ لاءِ اسان کي هر نوڊ لاءِ حقيقي ميزبان ايڊريس جي ضرورت آهي. اهو شايد بعد ۾ معلوم ٿئي ٿو ترتيب جي ٻين حصن کان. انهيء ڪري، اسان کي ضرورت آهي هڪ ميپنگ مهيا ڪرڻ لاء نوڊ id ۽ ان جي حقيقي پتي جي وچ ۾. هي نقشو هڪ فنڪشن آهي:

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

اهڙي فنڪشن کي لاڳو ڪرڻ لاء ڪجھ ممڪن طريقا آهن.

1. جيڪڏهن اسان ڊيپلائيمينٽ کان اڳ اصل ايڊريس ڄاڻون ٿا، نوڊ هوسٽ انسٽنٽيشن جي دوران، پوءِ اسان اصل ايڊريس سان اسڪالا ڪوڊ ٺاهي سگھون ٿا ۽ ان کان پوءِ بلڊ کي هلائي سگهون ٿا (جيڪو ڪمپائل ٽائيم چيڪ ڪري ٿو ۽ پوءِ انٽيگريشن ٽيسٽ سوٽ هلائي ٿو). انهي صورت ۾ اسان جي نقشي سازي جو ڪم جامد طور سڃاتو وڃي ٿو ۽ انهي کي آسان بڻائي سگهجي ٿو جهڙوڪ a Map[NodeId, NodeAddress].
2. ڪڏهن ڪڏهن اسان اصل ايڊريس حاصل ڪندا آهيون صرف هڪ پوئين نقطي تي جڏهن نوڊ اصل ۾ شروع ٿئي ٿو، يا اسان وٽ نوڊس جا ايڊريس نه آهن جيڪي اڃا شروع نه ڪيا ويا آهن. انهي صورت ۾ اسان وٽ شايد هڪ دريافت جي خدمت آهي جيڪا ٻين سڀني نوڊس کان اڳ شروع ڪئي وئي آهي ۽ هر نوڊ انهي خدمت ۾ ان جي ايڊريس کي اشتهار ڏئي سگهي ٿو ۽ انحصار جي رڪنيت حاصل ڪري سگهي ٿي.
3. جيڪڏهن اسان ترميم ڪري سگهون ٿا /etc/hosts، اسان اڳواٽ مقرر ڪيل ميزبان نالا استعمال ڪري سگھون ٿا (جهڙوڪ my-project-main-node ۽ echo-backend) ۽ صرف هن نالو سان ڳنڍيو ip ايڊريس جي مقرري وقت تي.

هن پوسٽ ۾ اسان انهن ڪيسن کي وڌيڪ تفصيل سان نه ڍڪيندا آهيون. حقيقت ۾ اسان جي رانديڪن جي مثال ۾ سڀني نوڊس کي ساڳيو IP پتو هوندو. 127.0.0.1.

هن پوسٽ ۾ اسين ٻه ورهايل سسٽم جي ترتيب تي غور ڪنداسين:

1. سنگل نوڊ ترتيب، جتي سڀئي خدمتون اڪيلو نوڊ تي رکيل آهن.
2. ٻه نوڊ ترتيب، جتي خدمت ۽ ڪلائنٽ مختلف نوڊس تي آهن.

جي تشڪيل 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 وقفو گذري ٿو.

خدمت جي عملن ۽ ترتيبن جو ساڳيو سيٽ ٻن الڳ نوڊس سان سسٽم جي ترتيب ٺاهڻ لاءِ استعمال ٿي سگھي ٿو. اسان کي صرف ٺاهڻ جي ضرورت آهي ٻه الڳ نوڊ ترتيب مناسب خدمتن سان گڏ:

ٻن نوڊس جي ٺاھ جوڙ

  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، جڏهن ته گونج ڪلائنٽ ختم ٿي ويندي ترتيب ڏنل محدود مدت کان پوءِ. ڏسو شروعاتي ايپليڪيشن تفصيل لاء.

مجموعي ترقي جي عمل

اچو ته ڏسون ته هي طريقو ڪيئن بدلجي ٿو اسان جي ترتيب سان ڪم ڪرڻ جو طريقو.

ڪوڊ جي طور تي ٺاھ جوڙ مرتب ڪيو ويندو ۽ ھڪڙي نموني ٺاھيو ويندو. اهو مناسب لڳي ٿو ترتيب واري نموني کي ٻين ڪوڊ جي نمونن کان الڳ ڪرڻ. گهڻو ڪري اسان وٽ هڪ ئي ڪوڊ جي بنياد تي ترتيبن جي ڪثرت آهي. ۽ يقينا، اسان وٽ مختلف ترتيبن جي شاخن جا ڪيترائي نسخا هوندا. هڪ ترتيب ۾ اسان لائبريرين جا خاص ورجن چونڊي سگھون ٿا ۽ اهو برقرار رهندو جڏهن به اسان هن ترتيب کي ترتيب ڏيون ٿا.

ھڪڙي ٺاھ جوڙ تبديلي ڪوڊ تبديلي ٿي. تنهن ڪري اهو ساڳيو معيار کي يقيني بڻائڻ جي عمل سان ڍڪڻ گهرجي:

ٽڪيٽ -> پي آر -> جائزو -> ضم -> مسلسل انضمام -> مسلسل تعیناتي

هن طريقي جا هيٺيان نتيجا آهن:

1. ترتيب هڪ خاص سسٽم جي مثال لاءِ هموار آهي. اهو لڳي ٿو ته نوڊس جي وچ ۾ غلط ڪنيڪشن جو ڪو طريقو ناهي.
2. اهو صرف هڪ نوڊ ۾ ترتيب ڏيڻ کي تبديل ڪرڻ آسان ناهي. لاگ ان ٿيڻ ۽ ڪجھ ٽيڪسٽ فائلن کي تبديل ڪرڻ غير معقول لڳي ٿو. تنهن ڪري ترتيب وار ڊرافٽ گهٽ ممڪن ٿي سگهي ٿو.
3. ننڍي جوڙجڪ تبديليون ڪرڻ آسان نه آهن.
4. گھڻا ٺاھ جوڙ تبديليون ساڳئي ترقي جي عمل جي پيروي ڪندا، ۽ اھو ڪجھ جائزو پاس ڪندو.

ڇا اسان کي پيداوار جي جوڙجڪ لاءِ الڳ مخزن جي ضرورت آھي؟ پيداوار جي جوڙجڪ ۾ حساس معلومات شامل ٿي سگھي ٿي جيڪا اسان ڪيترن ئي ماڻهن جي پهچ کان ٻاهر رکڻ چاهيندا. تنهن ڪري اهو ٿي سگهي ٿو هڪ الڳ مخزن کي محدود رسائي سان رکڻ جي قابل هجي جنهن ۾ پيداوار جي ترتيب شامل هوندي. اسان ڪنفيگريشن کي ٻن حصن ۾ ورهائي سگھون ٿا - ھڪڙو جنھن ۾ پيداوار جا سڀ کان کليل پيرا ميٽر آھن ۽ ٻيو جنھن ۾ ٺاھ جوڙ جو ڳجھو حصو آھي. اهو سڀ کان وڌيڪ ڊولپرز تائين رسائي کي قابل بڻائيندو پيٽرولر جي وڏي اڪثريت تائين جڏهن ته واقعي حساس شين تائين رسائي کي محدود ڪندي. ڊفالٽ پيٽرولر جي قدرن سان وچولي خاصيتن کي استعمال ڪندي هن کي پورو ڪرڻ آسان آهي.

تبديليون

اچو ته ڏسون تجويز ڪيل طريقي جا فائدا ۽ نقصان ٻين ترتيبن جي انتظام جي ٽيڪنالاجي جي مقابلي ۾.

سڀ کان پهريان، اسان ترتيب ڏيارڻ جي تجويز ڪيل طريقن جي مختلف پهلوئن لاءِ ڪجھ متبادل فهرست ڏينداسين:

1. ٽارگيٽ مشين تي متن فائل.
2. مرڪزي اهم-قدر اسٽوريج (جهڙوڪ etcd/zookeeper).
3. ذيلي پروسيس اجزاء جيڪي ٻيهر ترتيب ڏئي سگھجن ٿيون / ٻيهر شروع ٿيڻ واري عمل کي ٻيهر شروع ڪرڻ کان سواء.
4. آرٽيڪل ۽ ورزن ڪنٽرول کان ٻاهر جي ترتيب.

ٽيڪسٽ فائل ايڊهاڪ فيڪس جي لحاظ کان ڪجهه لچڪدار ڏئي ٿي. هڪ سسٽم جو منتظم ٽارگيٽ نوڊ ۾ لاگ ان ڪري سگهي ٿو، تبديلي آڻي سگهي ٿو ۽ صرف خدمت کي ٻيهر شروع ڪري سگهي ٿو. اهو ٿي سگهي ٿو وڏو سسٽم لاء سٺو نه آهي. تبديليءَ جو ڪو به نشان نه بچيو آهي. تبديليءَ جو جائزو ڪنهن ٻئي جوڙ جي اکين سان نه آهي. اهو معلوم ڪرڻ ڏکيو ٿي سگهي ٿو ته تبديلي جو سبب ڇا آهي. اهو آزمائشي نه ڪيو ويو آهي. ورهايل سسٽم جي نقطه نظر کان هڪ منتظم صرف هڪ ٻئي نوڊس ۾ ترتيبن کي تازه ڪاري ڪرڻ وساري سگهي ٿو.

(Btw، جيڪڏهن آخرڪار ٽيڪسٽ config فائلن کي استعمال ڪرڻ شروع ڪرڻ جي ضرورت پوندي، اسان کي صرف parser + validator شامل ڪرڻو پوندو جيڪو ساڳيو پيدا ڪري سگهي ٿو. Config ٽائيپ ڪريو ۽ اهو ڪافي هوندو ته متن جي ترتيبن کي استعمال ڪرڻ شروع ڪرڻ لاءِ. اهو پڻ ظاهر ڪري ٿو ته مرتب وقت جي ترتيب جي پيچيدگي ٿورو ننڍڙو آهي متن جي بنياد تي ترتيب جي پيچيدگي، ڇاڪاڻ ته متن تي ٻڌل ورزن ۾ اسان کي ڪجهه اضافي ڪوڊ جي ضرورت آهي.)

سينٽرلائزڊ ڪي-ويليو اسٽوريج ايپليڪيشن ميٽا پيرا ميٽرز کي ورهائڻ لاءِ هڪ سٺو ميکانيزم آهي. هتي اسان کي سوچڻ جي ضرورت آهي ته اسان ڇا سمجهون ٿا ترتيب جي قيمتن ۽ صرف ڊيٽا ڇا آهي. هڪ فنڪشن ڏنو C => A => B اسان عام طور تي گهٽ ۾ گهٽ تبديل ٿيندڙ قدر سڏين ٿا C "ترتيب"، جڏهن ته اڪثر تبديل ٿيل ڊيٽا A - صرف ان پٽ ڊيٽا. ڊيٽا کان پهريان فنڪشن کي ترتيب ڏيڻ گهرجي A. هن خيال کي ڏنو ويو ته اسان اهو چئي سگهون ٿا ته اها تبديلين جي متوقع تعدد آهي جيڪا صرف ڊيٽا کان ترتيب واري ڊيٽا کي فرق ڪرڻ لاء استعمال ٿي سگهي ٿي. پڻ ڊيٽا عام طور تي ھڪڙي ذريعن (صارف) کان ايندي آھي ۽ ترتيب ھڪڙي مختلف ذريعن (منتظم) کان ايندي آھي. پيٽرول سان ڊيل ڪرڻ جيڪي تبديل ٿي سگھن ٿيون شروعاتي عمل کان پوءِ ايپليڪيشن پيچيدگي ۾ اضافو ٿي سگھي ٿو. اهڙن پيرا ميٽرن لاءِ اسان کي انهن جي ترسيل ميڪانيزم کي سنڀالڻو پوندو، پارس ڪرڻ ۽ تصديق ڪرڻ، غلط قدرن کي سنڀالڻ. ان ڪري، پروگرام جي پيچيدگي کي گھٽائڻ لاءِ، اسان بھترين پيرا ميٽرن جو تعداد گھٽائي سگھون ٿا جيڪي رن ٽائم تي تبديل ٿي سگھن ٿيون (يا انھن کي مڪمل طور تي ختم ڪري سگھون ٿا).

ھن پوسٽ جي نقطي نظر کان اسان کي جامد ۽ متحرڪ پيٽرولر جي وچ ۾ فرق ڪرڻ گھرجي. جيڪڏهن خدمت جي منطق کي رن ٽائم تي ڪجهه پيٽرولر جي نادر تبديلي جي ضرورت آهي، ته پوء اسان انهن کي متحرڪ پيٽرولر سڏي سگهون ٿا. ٻي صورت ۾ اهي جامد آهن ۽ تجويز ڪيل طريقي سان ترتيب ڏئي سگهجن ٿيون. متحرڪ بحاليءَ لاءِ ٻين طريقن جي ضرورت ٿي سگھي ٿي. مثال طور، سسٽم جا حصا نئين ترتيب واري پيٽرولن سان ٻيهر شروع ٿي سگھن ٿا ساڳي طرح ورهايل سسٽم جي الڳ عمل کي ٻيهر شروع ڪرڻ لاءِ.
(منهنجي عاجز راءِ آهي ته رن ٽائم جي ٻيهر ترتيب کان پاسو ڪجي ڇاڪاڻ ته اهو سسٽم جي پيچيدگي کي وڌائي ٿو.
اهو وڌيڪ سڌو ٿي سگهي ٿو صرف او ايس سپورٽ تي ڀروسو ڪرڻ جي عمل کي ٻيهر شروع ڪرڻ. جيتوڻيڪ، اهو هميشه ممڪن ناهي.)

جامد ترتيب استعمال ڪرڻ جو هڪ اهم پاسو جيڪو ڪڏهن ڪڏهن ماڻهن کي متحرڪ ترتيب ڏيڻ تي غور ڪندو آهي (ٻين سببن کان سواءِ) ترتيب جي تازه ڪاري دوران سروس بند وقت آهي. درحقيقت، جيڪڏهن اسان کي جامد ترتيبن ۾ تبديليون آڻڻيون آهن، اسان کي سسٽم کي ٻيهر شروع ڪرڻو پوندو ته جيئن نيون قيمتون اثرائتو ٿي سگهن. وقت جي ضرورتن لاءِ مختلف سسٽم مختلف آهن، تنهنڪري اهو شايد نازڪ نه هجي. جيڪڏهن اهو نازڪ آهي، ته پوءِ اسان کي ڪنهن به سسٽم جي ٻيهر شروع ٿيڻ لاءِ اڳڀرائي ڪرڻي پوندي. مثال طور، اسان لاڳو ڪري سگهون ٿا AWS ELB ڪنيڪشن ڊريننگ. هن منظر ۾ جڏهن به اسان کي سسٽم کي ٻيهر شروع ڪرڻ جي ضرورت آهي، اسان متوازي طور تي سسٽم جو هڪ نئون مثال شروع ڪندا آهيون، پوء ان ۾ ELB کي تبديل ڪريو، جڏهن ته پراڻي سسٽم کي موجوده ڪنيڪشن کي مڪمل ڪرڻ جي اجازت ڏيو.

نسخي واري نموني اندر يا ٻاهر جي ترتيب کي برقرار رکڻ بابت ڇا؟ ھڪڙي نموني جي اندر ٺاھ جوڙ کي رکڻ جو مطلب آھي اڪثر ڪيسن ۾ اھو آھي ته ھي ٺاھ جوڙ ٻين نمونن وانگر ھڪڙي معيار جي ضمانت واري عمل کي پاس ڪري چڪو آھي. تنهنڪري هڪ پڪ ٿي سگهي ٿي ته ترتيب سٺي معيار ۽ قابل اعتماد آهي. ان جي ابتڙ هڪ الڳ فائل ۾ ترتيب ڏيڻ جو مطلب اهو آهي ته ان فائل ۾ ڪنهن ۽ ڇو تبديليون ڪيون آهن ان جو ڪوبه نشان نه آهي. ڇا هي اهم آهي؟ اسان يقين رکون ٿا ته اڪثر پيداوار سسٽم لاء اهو بهتر آهي ته مستحڪم ۽ اعلي معيار جي جوڙجڪ.

آرٽيڪل جو نسخو اهو معلوم ڪرڻ جي اجازت ڏئي ٿو جڏهن اهو ٺاهيو ويو، ان ۾ ڪهڙا قدر شامل آهن، ڪهڙيون خاصيتون فعال / غير فعال آهن، جيڪو ترتيب ۾ هر تبديلي ڪرڻ جو ذميوار هو. اهو ٿي سگھي ٿو ته ڪجهه ڪوشش جي ضرورت هجي ترتيب جي اندر ترتيب کي برقرار رکڻ لاءِ ۽ اهو ٺاهڻ لاءِ هڪ ڊزائن جو انتخاب آهي.

نفعو ۽ نقصان

هتي اسان ڪجهه فائدن کي اجاگر ڪرڻ ۽ تجويز ڪيل طريقي جي ڪجهه نقصانن تي بحث ڪرڻ چاهيندا.

فائدن

مڪمل ورهايل سسٽم جي مرتب ڪيل ترتيب جون خاصيتون:

1. ٺاھ جوڙ جي جامد چيڪ. اهو هڪ اعلي سطحي اعتماد ڏئي ٿو، ته ترتيب ڏنل قسم جي رڪاوٽون صحيح آهي.
2. ترتيب جي وڏي ٻولي. عام طور تي ٻين ٺاھ جوڙ جا طريقا سڀ کان وڌيڪ متغير متبادل تائين محدود آھن.
   اسڪالا استعمال ڪندي ڪو به ٻولي جي خصوصيتن جي وسيع رينج کي استعمال ڪري سگھي ٿو ترتيب کي بهتر بڻائڻ لاءِ. مثال طور، اسين ڊفالٽ قدر مهيا ڪرڻ لاءِ خاصيتون استعمال ڪري سگھون ٿا، مختلف دائري کي مقرر ڪرڻ لاءِ شيون، اسان حوالو ڪري سگھون ٿا vals صرف هڪ ڀيرو ٻاهرئين دائري ۾ بيان ڪيو ويو آهي (DRY). اهو لفظي ترتيبن کي استعمال ڪرڻ ممڪن آهي، يا ڪجهه خاص طبقن جا مثال (Seq, Mapوغيره.
3. ڊي ايس ايل. اسڪالا کي ڊي ايس ايل اديبن لاءِ مهذب سپورٽ آهي. ڪو به ماڻهو انهن خاصيتن کي استعمال ڪري سگهي ٿو هڪ ترتيب واري ٻولي قائم ڪرڻ لاءِ جيڪا وڌيڪ آسان ۽ آخري صارف دوست هجي، انهي ڪري ته حتمي ترتيب گهٽ ۾ گهٽ ڊومين استعمال ڪندڙن طرفان پڙهي سگهجي ٿي.
4. نوڊس جي وچ ۾ سالميت ۽ مطابقت. ھڪڙي جڳھ تي پوري ورهايل سسٽم لاءِ ٺاھ جوڙ ڪرڻ جو ھڪڙو فائدو اھو آھي ته سڀئي قدر ھڪ ڀيرو سختي سان بيان ڪيا ويا آھن ۽ پوءِ انھن سڀني هنڌن تي ٻيهر استعمال ڪيو وڃي ٿو جتي اسان کي انھن جي ضرورت آھي. پڻ ٽائيپ ڪريو محفوظ بندرگاھ بيانن کي يقيني بڻايو وڃي ته سڀني ممڪن صحيح ترتيبن ۾ سسٽم جا نوڊس ساڳي ٻولي ڳالھائيندا. نوڊس جي وچ ۾ واضح انحصار آهن جيڪي ڪجهه خدمتون مهيا ڪرڻ کي وسارڻ ڏکيو بڻائي ٿو.
5. تبديلين جي اعلي معيار. عام PR عمل جي ذريعي ترتيب ڏيڻ واري تبديلين کي پاس ڪرڻ جو مجموعي طريقو پڻ معيار جي اعلي معيار کي ترتيب ڏئي ٿو.
6. ساڳئي وقت ٺاھ جوڙ ۾ تبديليون. جڏهن به اسان ترتيب ۾ ڪا به تبديلي آڻيندا آهيون خودڪار ترتيب ڏيڻ يقيني بڻائي ٿي ته سڀئي نوڊس اپڊيٽ ٿي رهيا آهن.
7. ايپليڪيشن کي آسان ڪرڻ. ائپليڪيشن کي پارس ڪرڻ جي ضرورت نه آهي ۽ ترتيب جي تصديق ڪرڻ ۽ غلط ترتيب جي قيمتن کي سنڀالڻ. هي مجموعي ايپليڪيشن کي آسان بڻائي ٿو. (ڪجهه پيچيدگيءَ جو واڌارو خود ترتيب ۾ آهي، پر اهو حفاظت جي حوالي سان هڪ شعوري واپار آهي.) عام تشڪيل ڏانهن موٽڻ بلڪل سادو آهي - صرف گم ٿيل ٽڪر شامل ڪريو. مرتب ڪيل ترتيب سان شروع ڪرڻ ۽ اضافي ٽڪرن جي عمل کي ڪجهه دير تائين ملتوي ڪرڻ آسان آهي.
8. ورجن ترتيب. انهي حقيقت جي ڪري ته ترتيب جي تبديلين ساڳئي ترقي جي عمل جي پيروي ڪندا آهن، نتيجي ۾ اسان هڪ منفرد نسخي سان هڪ نموني حاصل ڪندا آهيون. اهو اسان کي اجازت ڏئي ٿو ته ترتيب کي واپس تبديل ڪرڻ جي ضرورت هجي. اسان هڪ ترتيب ترتيب ڏئي سگهون ٿا جيڪو هڪ سال اڳ استعمال ڪيو ويو هو ۽ اهو ساڳيو طريقي سان ڪم ڪندو. مستحڪم ترتيب ورهايل نظام جي اڳڪٿي ۽ اعتبار کي بهتر بڻائي ٿي. ترتيب ڏنل وقت تي مقرر ڪئي وئي آهي ۽ آساني سان پيداوار واري نظام تي خراب نه ٿي ڪري سگھجي.
9. ماڊلرٽي. تجويز ڪيل فريم ورڪ ماڊلر آهي ۽ ماڊلز کي مختلف طريقن سان گڏ ڪري سگهجي ٿو
   مختلف ترتيبن جي حمايت ڪريو (سيٽ اپ / ترتيب). خاص طور تي، اهو ممڪن آهي ته ننڍي پيماني تي واحد نوڊ ترتيب ۽ وڏي پيماني تي ملٽي نوڊ سيٽنگ. اهو مناسب آهي ته ڪيترن ئي پيداوار جي ترتيب سان.
10. جاچڻ. جانچ جي مقصدن لاءِ، ھڪڙو ٺٺولي سروس لاڳو ڪري سگھي ٿو ۽ ان کي ھڪڙي قسم جي محفوظ طريقي سان انحصار طور استعمال ڪري سگھي ٿو. ڪجھ مختلف ٽيسٽنگ لي آئوٽ مختلف حصن سان گڏ ٺٺوليون تبديل ڪري سگھجن ٿيون.
11. انضمام جي جاچ. ڪڏهن ڪڏهن ورهايل نظامن ۾ انٽيگريشن ٽيسٽ هلائڻ ڏکيو هوندو آهي. مڪمل ورهايل سسٽم جي محفوظ ترتيب کي ٽائپ ڪرڻ لاء بيان ڪيل طريقي سان استعمال ڪندي، اسان سڀني ورهايل حصن کي ھڪڙي سرور تي ڪنٽرول طريقي سان هلائي سگھون ٿا. صورتحال کي نقل ڪرڻ آسان آهي
    جڏهن خدمتن مان هڪ دستياب ناهي.

وڌڻ

مرتب ڪيل ٺاھ جوڙ جو طريقو "عام" ترتيب کان مختلف آھي ۽ اھو شايد سڀني ضرورتن کي پورو نٿو ڪري. هتي مرتب ڪيل ترتيب جا ڪجهه نقصان آهن:

1. جامد ترتيب. اهو شايد سڀني ايپليڪيشنن لاء مناسب نه هجي. ڪجهه حالتن ۾، سڀني حفاظتي قدمن کي ختم ڪندي پيداوار ۾ ترتيبن کي جلدي کي درست ڪرڻ جي ضرورت آهي. اهو طريقو وڌيڪ ڏکيو بڻائي ٿو. ترتيب ۾ ڪا به تبديلي ڪرڻ کان پوءِ ترتيب ڏيڻ ۽ ٻيهر ترتيب ڏيڻ جي ضرورت آهي. هي ٻئي خاصيت ۽ بوجھ آهي.
2. ٺاھ جوڙ جي نسل. جڏهن ترتيب ڪجهه آٽوميشن ٽول ذريعي ٺاهي وئي آهي ته هن طريقي کي بعد ۾ گڏ ڪرڻ جي ضرورت آهي (جيڪو ناڪام ٿي سگهي ٿو). هن اضافي قدم کي تعميراتي نظام ۾ ضم ڪرڻ لاءِ اضافي ڪوشش جي ضرورت ٿي سگھي ٿي.
3. اوزار. اڄڪلهه استعمال ۾ ڪافي اوزار موجود آهن جيڪي متن تي ٻڌل ترتيبن تي ڀاڙين ٿا. انهن مان ڪجھ
   لاڳو نه ٿيندو جڏهن ترتيب ترتيب ڏني وئي آهي.
4. ذهنيت ۾ تبديلي جي ضرورت آهي. ڊولپر ۽ DevOps متن جي ترتيب واري فائلن سان واقف آهن. ترتيب ترتيب ڏيڻ جو خيال انهن لاءِ عجيب لڳي سگھي ٿو.
5. مرتب ڪرڻ واري ترتيب کي متعارف ڪرائڻ کان پهريان هڪ اعليٰ معيار جي سافٽ ويئر ڊولپمينٽ جي عمل جي ضرورت آهي.

لاڳو ٿيل مثال جون ڪجهه حدون آهن:

1. جيڪڏهن اسان اضافي config مهيا ڪندا آهيون جيڪا نوڊ پليپشن طرفان گهربل نه آهي، ڪمپلر اسان کي غير حاضر عمل درآمد کي ڳولڻ ۾ مدد نه ڪندو. اهو استعمال ڪندي حل ڪري سگهجي ٿو HList يا ADTs (ڪيس ڪلاس) نوڊ جي ترتيب لاءِ خاصيتن ۽ ڪيڪ پيٽرن جي بدران.
2. اسان کي ترتيب ڏيڻ واري فائل ۾ ڪجهه بوائلر پليٽ مهيا ڪرڻو پوندو: (package, import, object بيان
   override defجي پيرا ميٽرن لاءِ جيڪي ڊفالٽ قدر آھن). اهو ٿي سگهي ٿو جزوي طور تي ڊي ايس ايل استعمال ڪندي خطاب ڪيو.
3. هن پوسٽ ۾ اسان هڪجهڙا نوڊس جي ڪلستر جي متحرڪ ٻيهر ترتيب ڏيڻ جو احاطو نه ڪندا آهيون.

ٿڪل

هن پوسٽ ۾ اسان بحث ڪيو آهي تشڪيل جي نمائندگي ڪرڻ جي خيال کي سڌو ذريعو ڪوڊ ۾ هڪ قسم جي محفوظ طريقي سان. اهو طريقو ڪيترن ئي ايپليڪيشنن ۾ xml- ۽ ٻين متن تي ٻڌل ترتيبن جي متبادل طور استعمال ڪري سگهجي ٿو. ان جي باوجود اسان جو مثال اسڪالا ۾ لاڳو ڪيو ويو آهي، اهو پڻ ٻين مرتب ڪيل ٻولين ۾ ترجمو ڪري سگهجي ٿو (جهڙوڪ ڪوٽلن، سي #، سوفٽ، وغيره). هڪ نئين منصوبي ۾ هن طريقي جي ڪوشش ڪري سگهي ٿي، ۽، صورت ۾ اهو صحيح نه آهي، پراڻي طريقي سان تبديل ڪريو.

يقينا، ترتيب ڏيڻ واري ترتيب کي اعلي معيار جي ترقي جي عمل جي ضرورت آهي. واپسي ۾ اهو واعدو ڪيو ته برابر اعلي معيار جي مضبوط جوڙجڪ مهيا ڪرڻ.

اهو طريقو مختلف طريقن سان وڌايو وڃي ٿو:

1. ھڪڙي ٺاھڻ جي تصديق ڪرڻ لاءِ ميڪرو استعمال ڪري سگھي ٿو ۽ ڪنھن ڪاروباري-منطق جي رڪاوٽن جي ناڪامي جي صورت ۾ مرتب وقت تي ناڪام ٿي سگھي ٿو.
2. ڊومين-استعمال ڪندڙ-دوست طريقي سان ترتيب ڏيڻ جي نمائندگي ڪرڻ لاءِ DSL لاڳو ٿي سگھي ٿو.
3. متحرڪ وسيلن جو انتظام خودڪار ترتيب جي ترتيبن سان. مثال طور، جڏهن اسان ڪلسٽر نوڊس جي تعداد کي ترتيب ڏيون ٿا ته اسان چاهيون ٿا (1) نوڊس کي ٿوري تبديل ٿيل ترتيب حاصل ڪرڻ لاءِ؛ (2) نئين نوڊس جي معلومات حاصل ڪرڻ لاءِ ڪلسٽر مئنيجر.

مهرباني

مان چوڻ چاهيان ٿو ته توهان جي مهرباني Andrey Saksonov، Pavel Popov، Anton Nehaev جي هن پوسٽ جي مسودي تي متاثر ڪندڙ موٽ ڏيڻ لاءِ جنهن مون کي ان کي واضح ڪرڻ ۾ مدد ڪئي.

جو ذريعو: www.habr.com