🥇 একটি বিতরণ করা সিস্টেমের সংকলনযোগ্য কনফিগারেশন

এই পোস্টে আমরা একটি ডিস্ট্রিবিউটেড সিস্টেমের কনফিগারেশনের সাথে ডিল করার একটি আকর্ষণীয় উপায় শেয়ার করতে চাই।
কনফিগারেশনটি সরাসরি স্কালা ভাষায় টাইপ নিরাপদ পদ্ধতিতে উপস্থাপন করা হয়। একটি উদাহরণ বাস্তবায়ন বিস্তারিত বর্ণনা করা হয়েছে. সার্বিক উন্নয়ন প্রক্রিয়ায় প্রভাব বিস্তারসহ প্রস্তাবের বিভিন্ন দিক নিয়ে আলোচনা করা হয়েছে।

(রাশিয়ান মধ্যে)

ভূমিকা

শক্তিশালী বিতরণ সিস্টেম তৈরি করার জন্য সমস্ত নোডে সঠিক এবং সুসংগত কনফিগারেশন ব্যবহার করা প্রয়োজন। একটি সাধারণ সমাধান হল একটি পাঠ্য স্থাপনার বর্ণনা (টেরাফর্ম, উত্তরযোগ্য বা একই রকম) এবং স্বয়ংক্রিয়ভাবে তৈরি কনফিগারেশন ফাইল (প্রায়শই — প্রতিটি নোড/রোলের জন্য নিবেদিত) ব্যবহার করা। আমরা প্রতিটি যোগাযোগ নোডগুলিতে একই সংস্করণের একই প্রোটোকল ব্যবহার করতে চাই (অন্যথায় আমরা অসঙ্গতি সমস্যাগুলি অনুভব করব)। 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-বিট মান থাকতে দেওয়া হয় যা পোর্ট নম্বর উপস্থাপন করতে পারে। এই কনফিগারেশন পদ্ধতির জন্য এই লাইব্রেরি ব্যবহার করার কোন প্রয়োজন নেই। এটা শুধু খুব ভাল মাপসই মনে হয়.

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]

এই প্রোটোকলের অনুরোধ বার্তাটি 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 প্রকার এছাড়াও আমরা সম্পূর্ণ কনফিগারেশন প্রদান না করে নোড শুরু করতে সক্ষম হব না।

নোড ঠিকানা রেজোলিউশন

একটি সংযোগ স্থাপন করার জন্য আমাদের প্রতিটি নোডের জন্য একটি বাস্তব হোস্ট ঠিকানা প্রয়োজন। এটি কনফিগারেশনের অন্যান্য অংশের তুলনায় পরে জানা যাবে। সুতরাং, নোড আইডি এবং এটির আসল ঠিকানার মধ্যে একটি ম্যাপিং সরবরাহ করার জন্য আমাদের একটি উপায় দরকার। এই ম্যাপিং একটি ফাংশন:

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

এই ধরনের একটি ফাংশন বাস্তবায়ন করার জন্য কয়েকটি সম্ভাব্য উপায় আছে।

যদি আমরা নোড হোস্ট ইনস্ট্যান্টেশনের সময়, স্থাপনার আগে প্রকৃত ঠিকানাগুলি জানি, তাহলে আমরা প্রকৃত ঠিকানাগুলির সাথে স্কালা কোড তৈরি করতে পারি এবং পরে বিল্ডটি চালাতে পারি (যা কম্পাইল টাইম চেক করে এবং তারপরে ইন্টিগ্রেশন টেস্ট স্যুট চালায়)। এই ক্ষেত্রে আমাদের ম্যাপিং ফাংশন স্থিরভাবে পরিচিত এবং একটি মত কিছু সরলীকৃত করা যেতে পারে Map[NodeId, NodeAddress].
কখনও কখনও আমরা প্রকৃত ঠিকানাগুলি শুধুমাত্র পরবর্তী সময়ে প্রাপ্ত করি যখন নোডটি আসলে শুরু হয়, অথবা আমাদের কাছে নোডের ঠিকানা নেই যা এখনও শুরু হয়নি। এই ক্ষেত্রে আমাদের একটি আবিষ্কার পরিষেবা থাকতে পারে যা অন্য সমস্ত নোডের আগে শুরু হয় এবং প্রতিটি নোড সেই পরিষেবাতে তার ঠিকানার বিজ্ঞাপন দিতে পারে এবং নির্ভরতার সদস্যতা নিতে পারে।
আমরা যদি সংশোধন করতে পারি /etc/hosts, আমরা পূর্বনির্ধারিত হোস্ট নাম ব্যবহার করতে পারি (যেমন my-project-main-node এবং echo-backend) এবং স্থাপনার সময় আইপি ঠিকানার সাথে এই নামটি যুক্ত করুন।

এই পোস্টে আমরা এই মামলাগুলিকে আরও বিশদে কভার করি না। আসলে আমাদের খেলনা উদাহরণে সমস্ত নোডের একই আইপি ঠিকানা থাকবে — 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"
  }

আমরা নির্ভরতা নির্দিষ্ট কিভাবে দেখুন. আমরা বর্তমান নোডের নির্ভরতা হিসাবে অন্যান্য নোডের প্রদত্ত পরিষেবা উল্লেখ করি। নির্ভরতার ধরনটি পরীক্ষা করা হয়েছে কারণ এতে ফ্যান্টম টাইপ রয়েছে যা প্রোটোকল বর্ণনা করে। এবং রানটাইমে আমরা সঠিক নোড আইডি থাকবে। এটি প্রস্তাবিত কনফিগারেশন পদ্ধতির একটি গুরুত্বপূর্ণ দিক। এটি আমাদের শুধুমাত্র একবার পোর্ট সেট করার ক্ষমতা প্রদান করে এবং নিশ্চিত করুন যে আমরা সঠিক পোর্টটি উল্লেখ করছি।

দুটি নোড বাস্তবায়ন

এই কনফিগারেশনের জন্য আমরা ঠিক একই পরিষেবা বাস্তবায়ন ব্যবহার করি। কোনো পরিবর্তন নেই। যাইহোক, আমরা দুটি ভিন্ন নোড বাস্তবায়ন তৈরি করি যার মধ্যে বিভিন্ন সেট পরিষেবা রয়েছে:

  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).
সাবপ্রসেস উপাদান যা পুনরায় কনফিগার/পুনঃসূচনা প্রক্রিয়া পুনরায় আরম্ভ না করেই করা যেতে পারে।
আর্টিফ্যাক্ট এবং সংস্করণ নিয়ন্ত্রণের বাইরে কনফিগারেশন।

টেক্সট ফাইল অ্যাড-হক ফিক্সের ক্ষেত্রে কিছু নমনীয়তা দেয়। একটি সিস্টেমের প্রশাসক লক্ষ্য নোডে লগইন করতে পারেন, একটি পরিবর্তন করতে পারেন এবং কেবল পরিষেবাটি পুনরায় চালু করতে পারেন। এটি বড় সিস্টেমের জন্য ভাল নাও হতে পারে। পরিবর্তনের পিছনে কোন চিহ্ন বাকি নেই। পরিবর্তন অন্য জোড়া চোখ দ্বারা পর্যালোচনা করা হয় না. পরিবর্তনের কারণ কী তা খুঁজে বের করা কঠিন হতে পারে। এটা পরীক্ষা করা হয়নি. বিতরণ করা সিস্টেমের দৃষ্টিকোণ থেকে একজন প্রশাসক অন্য নোডগুলির একটিতে কনফিগারেশন আপডেট করতে ভুলে যেতে পারেন।

(বিটিডব্লিউ, যদি শেষ পর্যন্ত টেক্সট কনফিগ ফাইলগুলি ব্যবহার করা শুরু করার প্রয়োজন হয়, তবে আমাদের শুধুমাত্র পার্সার + ভ্যালিডেটর যোগ করতে হবে যা একই উত্পাদন করতে পারে Config টাইপ করুন এবং এটি টেক্সট কনফিগারেশন ব্যবহার শুরু করার জন্য যথেষ্ট হবে। এটি আরও দেখায় যে কম্পাইল-টাইম কনফিগারেশনের জটিলতা টেক্সট-ভিত্তিক কনফিগারেশনের জটিলতা থেকে একটু কম, কারণ পাঠ্য-ভিত্তিক সংস্করণে আমাদের কিছু অতিরিক্ত কোডের প্রয়োজন।)

কেন্দ্রীভূত কী-মান সঞ্চয়স্থান অ্যাপ্লিকেশন মেটা প্যারামিটার বিতরণের জন্য একটি ভাল প্রক্রিয়া। এখানে আমাদের চিন্তা করা দরকার যে আমরা কনফিগারেশন মান হিসাবে বিবেচনা করি এবং কেবলমাত্র ডেটা কী। একটি ফাংশন দেওয়া C => A => B আমরা সাধারণত কদাচিৎ পরিবর্তনশীল মানকে বলি C "কনফিগারেশন", যখন ঘন ঘন ডেটা পরিবর্তন করা হয় A - শুধু ইনপুট তথ্য. ডেটার চেয়ে আগে ফাংশনে কনফিগারেশন প্রদান করা উচিত A. এই ধারণাটি দেওয়া হলে আমরা বলতে পারি যে এটি পরিবর্তনের প্রত্যাশিত ফ্রিকোয়েন্সি যা কেবলমাত্র ডেটা থেকে কনফিগারেশন ডেটাকে আলাদা করতে ব্যবহার করা যেতে পারে। এছাড়াও ডেটা সাধারণত একটি উত্স (ব্যবহারকারী) থেকে আসে এবং কনফিগারেশন একটি ভিন্ন উত্স (অ্যাডমিন) থেকে আসে। প্রাথমিক প্রক্রিয়ার পরে পরিবর্তন করা যেতে পারে এমন প্যারামিটারগুলির সাথে মোকাবিলা করার ফলে অ্যাপ্লিকেশন জটিলতা বৃদ্ধি পায়। এই ধরনের প্যারামিটারের জন্য আমাদের তাদের ডেলিভারি মেকানিজম, পার্সিং এবং যাচাইকরণ, ভুল মানগুলি পরিচালনা করতে হবে। তাই, প্রোগ্রামের জটিলতা কমানোর জন্য, আমরা রানটাইমে পরিবর্তিত হতে পারে এমন প্যারামিটারের সংখ্যা কমিয়ে আনতে চাই (অথবা সম্পূর্ণরূপে বাদ দিয়েও)।

এই পোস্টের দৃষ্টিকোণ থেকে আমাদের স্ট্যাটিক এবং ডাইনামিক প্যারামিটারের মধ্যে পার্থক্য করা উচিত। যদি সার্ভিস লজিকের জন্য রানটাইমে কিছু প্যারামিটারের বিরল পরিবর্তনের প্রয়োজন হয়, তাহলে আমরা সেগুলিকে ডাইনামিক প্যারামিটার বলতে পারি। অন্যথায় তারা স্থির এবং প্রস্তাবিত পদ্ধতি ব্যবহার করে কনফিগার করা যেতে পারে। গতিশীল পুনর্বিন্যাস করার জন্য অন্যান্য পদ্ধতির প্রয়োজন হতে পারে। উদাহরণস্বরূপ, সিস্টেমের কিছু অংশ নতুন কনফিগারেশন পরামিতিগুলির সাথে একটি বিতরণ করা সিস্টেমের পৃথক প্রক্রিয়া পুনরায় চালু করার অনুরূপভাবে পুনরায় চালু করা যেতে পারে।
(আমার বিনীত মতামত হল রানটাইম পুনর্বিন্যাস এড়াতে কারণ এটি সিস্টেমের জটিলতা বাড়ায়।
এটি পুনরায় চালু করার প্রক্রিয়াগুলির OS সমর্থনের উপর নির্ভর করা আরও সোজা হতে পারে। যদিও, এটা সবসময় সম্ভব নাও হতে পারে।)

স্ট্যাটিক কনফিগারেশন ব্যবহারের একটি গুরুত্বপূর্ণ দিক যা কখনও কখনও মানুষকে গতিশীল কনফিগারেশন বিবেচনা করে (অন্যান্য কারণ ছাড়া) কনফিগারেশন আপডেটের সময় পরিষেবা ডাউনটাইম। প্রকৃতপক্ষে, যদি আমাদের স্ট্যাটিক কনফিগারেশনে পরিবর্তন করতে হয়, আমাদের সিস্টেমটি পুনরায় চালু করতে হবে যাতে নতুন মান কার্যকর হয়। ডাউনটাইমের প্রয়োজনীয়তা বিভিন্ন সিস্টেমের জন্য পরিবর্তিত হয়, তাই এটি এতটা সমালোচনামূলক নাও হতে পারে। যদি এটি সমালোচনামূলক হয়, তবে আমাদের যে কোনও সিস্টেম পুনরায় চালু করার জন্য আগে থেকে পরিকল্পনা করতে হবে। উদাহরণস্বরূপ, আমরা বাস্তবায়ন করতে পারে AWS ELB সংযোগ নিষ্কাশন. এই পরিস্থিতিতে যখনই আমাদের সিস্টেমটি পুনরায় চালু করার প্রয়োজন হয়, আমরা সমান্তরালভাবে সিস্টেমের একটি নতুন দৃষ্টান্ত শুরু করি, তারপরে এটিতে ELB স্যুইচ করি, পুরানো সিস্টেমটিকে বিদ্যমান সংযোগগুলি সম্পূর্ণ করতে দিয়ে৷

সংস্করণযুক্ত শিল্পকর্মের ভিতরে বা বাইরে কনফিগারেশন রাখার বিষয়ে কী? একটি আর্টিফ্যাক্টের ভিতরে কনফিগারেশন রাখার অর্থ হল বেশিরভাগ ক্ষেত্রে এই কনফিগারেশনটি অন্যান্য আর্টিফ্যাক্টের মতো একই গুণমান নিশ্চিতকরণ প্রক্রিয়াটি পাস করেছে। সুতরাং কেউ নিশ্চিত হতে পারে যে কনফিগারেশনটি ভাল মানের এবং বিশ্বস্ত। বিপরীতে একটি পৃথক ফাইলে কনফিগারেশনের অর্থ হল যে ফাইলটিতে কে এবং কেন পরিবর্তন করেছে তার কোনও চিহ্ন নেই। এই গুরুত্বপূর্ণ? আমরা বিশ্বাস করি যে বেশিরভাগ উত্পাদন সিস্টেমের জন্য স্থিতিশীল এবং উচ্চ মানের কনফিগারেশন থাকা ভাল।

আর্টিফ্যাক্টের সংস্করণটি এটি কখন তৈরি করা হয়েছিল, এতে কী কী মান রয়েছে, কী বৈশিষ্ট্যগুলি সক্ষম/অক্ষম করা হয়েছে, কনফিগারেশনে প্রতিটি পরিবর্তন করার জন্য কারা দায়ী ছিল তা খুঁজে বের করার অনুমতি দেয়। একটি আর্টিফ্যাক্টের ভিতরে কনফিগারেশন রাখার জন্য কিছু প্রচেষ্টার প্রয়োজন হতে পারে এবং এটি তৈরি করা একটি ডিজাইন পছন্দ।

পেশাদাররা এবং কনস

এখানে আমরা কিছু সুবিধা তুলে ধরতে চাই এবং প্রস্তাবিত পদ্ধতির কিছু অসুবিধা নিয়ে আলোচনা করতে চাই।

উপকারিতা

একটি সম্পূর্ণ বিতরণ করা সিস্টেমের সংকলনযোগ্য কনফিগারেশনের বৈশিষ্ট্য:

কনফিগারেশন স্ট্যাটিক চেক. এটি একটি উচ্চ স্তরের আত্মবিশ্বাস দেয়, যে কনফিগারেশন সঠিক প্রদত্ত ধরনের সীমাবদ্ধতা।
কনফিগারেশন সমৃদ্ধ ভাষা. সাধারণত অন্যান্য কনফিগারেশন পদ্ধতিগুলি সর্বাধিক পরিবর্তনশীল প্রতিস্থাপনের মধ্যে সীমাবদ্ধ।
স্কালা ব্যবহার করে কনফিগারেশন আরও ভাল করার জন্য ভাষা বৈশিষ্ট্যগুলির একটি বিস্তৃত পরিসর ব্যবহার করা যেতে পারে। উদাহরণস্বরূপ, আমরা ডিফল্ট মান প্রদানের জন্য বৈশিষ্ট্য ব্যবহার করতে পারি, বিভিন্ন স্কোপ সেট করার জন্য বস্তু, আমরা উল্লেখ করতে পারি vals শুধুমাত্র একবার বাইরের সুযোগে (DRY) সংজ্ঞায়িত করা হয়েছে। আক্ষরিক ক্রম, বা নির্দিষ্ট শ্রেণীর উদাহরণ ব্যবহার করা সম্ভব (Seq, Map, ইত্যাদি)।
ডিএসএল। স্কালার ডিএসএল লেখকদের জন্য উপযুক্ত সমর্থন রয়েছে। কেউ এই বৈশিষ্ট্যগুলি ব্যবহার করে একটি কনফিগারেশন ভাষা প্রতিষ্ঠা করতে পারে যা আরও সুবিধাজনক এবং শেষ-ব্যবহারকারী বন্ধুত্বপূর্ণ, যাতে চূড়ান্ত কনফিগারেশনটি অন্তত ডোমেন ব্যবহারকারীদের দ্বারা পাঠযোগ্য হয়।
নোড জুড়ে অখণ্ডতা এবং সমন্বয়। পুরো বিতরণ সিস্টেমের জন্য এক জায়গায় কনফিগারেশন করার সুবিধাগুলির মধ্যে একটি হল যে সমস্ত মানগুলি একবার কঠোরভাবে সংজ্ঞায়িত করা হয় এবং তারপরে আমাদের প্রয়োজন যেখানে সেগুলি সমস্ত জায়গায় পুনরায় ব্যবহার করা হয়। এছাড়াও টাইপ নিরাপদ পোর্ট ঘোষণা নিশ্চিত করে যে সমস্ত সম্ভাব্য সঠিক কনফিগারেশনে সিস্টেমের নোডগুলি একই ভাষায় কথা বলবে। নোডগুলির মধ্যে স্পষ্ট নির্ভরতা রয়েছে যা কিছু পরিষেবা প্রদান করতে ভুলে যাওয়া কঠিন করে তোলে।
পরিবর্তনের উচ্চ মানের. সাধারণ PR প্রক্রিয়ার মাধ্যমে কনফিগারেশন পরিবর্তনের সামগ্রিক পদ্ধতি কনফিগারেশনেও মানের উচ্চ মান স্থাপন করে।
একযোগে কনফিগারেশন পরিবর্তন. যখনই আমরা কনফিগারেশনে কোনো পরিবর্তন করি স্বয়ংক্রিয় স্থাপনা নিশ্চিত করে যে সমস্ত নোড আপডেট করা হচ্ছে।
অ্যাপ্লিকেশন সরলীকরণ। অ্যাপ্লিকেশনটির কনফিগারেশন পার্স এবং যাচাই করার এবং ভুল কনফিগারেশন মানগুলি পরিচালনা করার দরকার নেই। এটি সামগ্রিক অ্যাপ্লিকেশনটিকে সহজ করে তোলে। (কিছু জটিলতা বৃদ্ধি কনফিগারেশন নিজেই, কিন্তু এটি নিরাপত্তার প্রতি একটি সচেতন ট্রেড-অফ।) এটি সাধারণ কনফিগারেশনে ফিরে আসা বেশ সহজ - শুধু অনুপস্থিত টুকরা যোগ করুন। সংকলিত কনফিগারেশনের সাথে শুরু করা এবং অতিরিক্ত অংশগুলির বাস্তবায়ন পরবর্তী সময়ে স্থগিত করা সহজ।
সংস্করণযুক্ত কনফিগারেশন। কনফিগারেশন পরিবর্তনগুলি একই বিকাশ প্রক্রিয়া অনুসরণ করে, ফলস্বরূপ আমরা অনন্য সংস্করণ সহ একটি আর্টিফ্যাক্ট পাই। প্রয়োজনে এটি আমাদের কনফিগারেশনটি আবার পরিবর্তন করতে দেয়। এমনকি আমরা একটি কনফিগারেশন স্থাপন করতে পারি যা এক বছর আগে ব্যবহৃত হয়েছিল এবং এটি ঠিক একইভাবে কাজ করবে। স্থিতিশীল কনফিগারেশন বিতরণ সিস্টেমের পূর্বাভাস এবং নির্ভরযোগ্যতা উন্নত করে। কনফিগারেশনটি কম্পাইলের সময় স্থির করা হয় এবং একটি উত্পাদন সিস্টেমে সহজে টেম্পার করা যায় না।
মডুলারিটি। প্রস্তাবিত কাঠামোটি মডুলার এবং মডিউলগুলিকে বিভিন্ন উপায়ে একত্রিত করা যেতে পারে
বিভিন্ন কনফিগারেশন (সেটআপ/লেআউট) সমর্থন করে। বিশেষ করে, একটি ছোট স্কেল একক নোড লেআউট এবং একটি বড় স্কেল মাল্টি নোড সেটিং করা সম্ভব। একাধিক প্রোডাকশন লেআউট থাকা যুক্তিসঙ্গত।
পরীক্ষামূলক. পরীক্ষার উদ্দেশ্যে কেউ একটি উপহাস পরিষেবা বাস্তবায়ন করতে পারে এবং এটিকে একটি প্রকার নিরাপদ উপায়ে নির্ভরতা হিসাবে ব্যবহার করতে পারে। মক দ্বারা প্রতিস্থাপিত বিভিন্ন অংশ সহ কয়েকটি ভিন্ন টেস্টিং লেআউট একই সাথে বজায় রাখা যেতে পারে।
ইন্টিগ্রেশন টেস্টিং. কখনও কখনও বিতরণ করা সিস্টেমে ইন্টিগ্রেশন পরীক্ষা চালানো কঠিন। সম্পূর্ণ বিতরণ করা সিস্টেমের নিরাপদ কনফিগারেশন টাইপ করার জন্য বর্ণিত পদ্ধতি ব্যবহার করে, আমরা একটি একক সার্ভারে সমস্ত বিতরণ করা অংশগুলি নিয়ন্ত্রণযোগ্য উপায়ে চালাতে পারি। পরিস্থিতি অনুকরণ করা সহজ
যখন পরিষেবাগুলির একটি অনুপলব্ধ হয়ে যায়।

অসুবিধা সমূহ

সংকলিত কনফিগারেশন পদ্ধতিটি "স্বাভাবিক" কনফিগারেশন থেকে আলাদা এবং এটি সমস্ত প্রয়োজনের সাথে নাও মিলতে পারে। এখানে সংকলিত কনফিগারেশনের কিছু অসুবিধা রয়েছে:

স্ট্যাটিক কনফিগারেশন। এটা সব অ্যাপ্লিকেশনের জন্য উপযুক্ত নাও হতে পারে. কিছু ক্ষেত্রে, সমস্ত সুরক্ষা ব্যবস্থা বাদ দিয়ে উত্পাদনে কনফিগারেশনটি দ্রুত ঠিক করার প্রয়োজন রয়েছে। এই পদ্ধতিটি আরও কঠিন করে তোলে। কনফিগারেশনে কোন পরিবর্তন করার পরে সংকলন এবং পুনঃনিয়োগ প্রয়োজন। এটি বৈশিষ্ট্য এবং বোঝা উভয়ই।
কনফিগারেশন প্রজন্ম। যখন কিছু অটোমেশন টুল দ্বারা config তৈরি করা হয় তখন এই পদ্ধতির জন্য পরবর্তী সংকলন প্রয়োজন (যা ব্যর্থ হতে পারে)। বিল্ড সিস্টেমে এই অতিরিক্ত পদক্ষেপকে সংহত করার জন্য অতিরিক্ত প্রচেষ্টার প্রয়োজন হতে পারে।
যন্ত্র। বর্তমানে প্রচুর টুল ব্যবহার করা হচ্ছে যা টেক্সট-ভিত্তিক কনফিগারেশনের উপর নির্ভর করে। তাদের মধ্যে কিছু
কনফিগারেশন কম্পাইল করা হলে প্রযোজ্য হবে না।
মানসিকতার পরিবর্তন দরকার। বিকাশকারী এবং DevOps পাঠ্য কনফিগারেশন ফাইলগুলির সাথে পরিচিত৷ কনফিগারেশন কম্পাইল করার ধারণা তাদের কাছে অদ্ভুত লাগতে পারে।
সংকলনযোগ্য কনফিগারেশন প্রবর্তনের আগে একটি উচ্চ মানের সফ্টওয়্যার বিকাশ প্রক্রিয়া প্রয়োজন।

বাস্তবায়িত উদাহরণের কিছু সীমাবদ্ধতা রয়েছে:

যদি আমরা অতিরিক্ত কনফিগারেশন প্রদান করি যা নোড বাস্তবায়নের দ্বারা দাবি করা হয় না, তাহলে কম্পাইলার অনুপস্থিত বাস্তবায়ন সনাক্ত করতে আমাদের সাহায্য করবে না। এটি ব্যবহার করে সমাধান করা যেতে পারে HList বা বৈশিষ্ট্য এবং কেক প্যাটার্নের পরিবর্তে নোড কনফিগারেশনের জন্য ADTs (কেস ক্লাস)।
আমাদের কনফিগার ফাইলে কিছু বয়লারপ্লেট প্রদান করতে হবে: (package, import, object ঘোষণাপত্র
override defডিফল্ট মান আছে এমন প্যারামিটারগুলির জন্য)। এটি একটি DSL ব্যবহার করে আংশিকভাবে সম্বোধন করা যেতে পারে।
এই পোস্টে আমরা অনুরূপ নোডের ক্লাস্টারগুলির গতিশীল পুনর্বিন্যাস কভার করি না।

উপসংহার

এই পোস্টে আমরা একটি টাইপ নিরাপদ উপায়ে সোর্স কোডে সরাসরি কনফিগারেশনের প্রতিনিধিত্ব করার ধারণা নিয়ে আলোচনা করেছি। পদ্ধতিটি xml- এবং অন্যান্য পাঠ্য-ভিত্তিক কনফিগারেশনের প্রতিস্থাপন হিসাবে অনেক অ্যাপ্লিকেশনে ব্যবহার করা যেতে পারে। যদিও আমাদের উদাহরণ স্কালাতে প্রয়োগ করা হয়েছে, এটি অন্যান্য সংকলনযোগ্য ভাষায়ও অনুবাদ করা যেতে পারে (যেমন কোটলিন, সি#, সুইফট, ইত্যাদি)। কেউ একটি নতুন প্রকল্পে এই পদ্ধতির চেষ্টা করতে পারে এবং যদি এটি ভালভাবে ফিট না হয় তবে পুরানো পদ্ধতিতে স্যুইচ করুন।

অবশ্যই, কম্পাইলযোগ্য কনফিগারেশনের জন্য উচ্চ মানের উন্নয়ন প্রক্রিয়া প্রয়োজন। বিনিময়ে এটি সমান উচ্চ মানের শক্তিশালী কনফিগারেশন প্রদানের প্রতিশ্রুতি দেয়।

এই পদ্ধতি বিভিন্ন উপায়ে প্রসারিত করা যেতে পারে:

কনফিগারেশনের বৈধতা সঞ্চালনের জন্য কেউ ম্যাক্রো ব্যবহার করতে পারে এবং কোনো ব্যবসা-যুক্তিগত সীমাবদ্ধতার ব্যর্থতার ক্ষেত্রে কম্পাইলের সময় ব্যর্থ হতে পারে।
একটি DSL একটি ডোমেন-ব্যবহারকারী-বান্ধব উপায়ে কনফিগারেশন প্রতিনিধিত্ব করার জন্য প্রয়োগ করা যেতে পারে।
স্বয়ংক্রিয় কনফিগারেশন সমন্বয় সহ গতিশীল সম্পদ ব্যবস্থাপনা। উদাহরণস্বরূপ, যখন আমরা ক্লাস্টার নোডের সংখ্যা সামঞ্জস্য করি তখন আমরা চাই (1) নোডগুলি সামান্য পরিবর্তিত কনফিগারেশন পেতে; (2) নতুন নোডের তথ্য পেতে ক্লাস্টার ম্যানেজার।

ধন্যবাদ

আমি এই পোস্টের খসড়া সম্পর্কে অনুপ্রেরণামূলক প্রতিক্রিয়া দেওয়ার জন্য আন্দ্রে সাকসোনভ, পাভেল পপভ, আন্তন নেহায়েভকে ধন্যবাদ জানাতে চাই যা আমাকে এটি পরিষ্কার করতে সাহায্য করেছে।

উত্স: www.habr.com

একটি বিতরণ সিস্টেমের সংকলনযোগ্য কনফিগারেশন