🥇 Veavakirina berhevkirî ya pergalek belavkirî

Di vê postê de em dixwazin rêyek balkêş a mijûlbûna bi veavakirina pergalek belavkirî re parve bikin.
Veavakirin rasterast bi zimanê Scala bi rengek ewledar tê temsîl kirin. Mînakek pêkanîn bi hûrgulî tête diyar kirin. Gelek aliyên pêşniyarê têne nîqaş kirin, di nav de bandora li ser pêvajoya pêşveçûnê ya giştî.

(bi rûsî)

Pêşkêş

Avakirina pergalên belavbûyî yên bi hêz hewce dike ku li ser hemî girêkan konfigurasyona rast û hevgirtî bikar bînin. Çareseriyek tîpîk ev e ku meriv ravek danûstendina nivîsê bikar bîne (terraform, ansible an tiştek wekî hev) û pelên vesazkirinê bixweber têne hilberandin (bi gelemperî - ji bo her girêk / rolê veqetandî). Di heman demê de em dixwazin heman protokolên heman guhertoyan li ser her girêka ragihandinê bikar bînin (nexwe em ê pirsgirêkên nelihevkirinê biceribînin). Di cîhana JVM de ev tê vê wateyê ku bi kêmanî pirtûkxaneya peyamberê divê li ser hemî girêkên ragihandinê heman guhertoyê be.

Li ser ceribandina pergalê çi ye? Bê guman, berî ku em werin ceribandinên entegrasyonê, divê em ji bo hemî pêkhateyan testên yekîneyê hebin. Ji bo ku em bikaribin encamên testê li ser dema xebitandinê derxînin, divê em pê ewle bin ku guhertoyên hemî pirtûkxaneyan hem di dema xebitandinê û hem jî di hawîrdorên ceribandinê de wekhev têne girtin.

Dema ku ceribandinên entegrasyonê dimeşînin, bi gelemperî pir hêsan e ku meriv li ser hemî girêkan heman polê hebe. Em tenê hewce ne ku pê ewle bin ku heman polê li ser danînê tê bikar anîn. (Mimkun e ku meriv li ser girêkên cihêreng rêgezên sinifê yên cihê bikar bîne, lê temsîlkirina vê veavakirinê û bi rêkûpêk danîna wê dijwartir e.) Ji ber vê yekê ji bo ku tiştan sade bihêlin, em ê tenê li ser hemî girêkan rêgezên sinifê yeksan bifikirin.

Veavakirin bi nermalavê re bi pêş ve diçe. Em bi gelemperî guhertoyan bikar tînin da ku cûrbecûr nas bikin
qonaxên pêşveçûna nermalavê. Maqûl xuya dike ku meriv veavakirinê di bin rêveberiya guhertoyê de veşêre û bi hin etîketan ve mîhengên cihêreng nas bike. Ger di hilberînê de tenê veavakirinek hebe, dibe ku em guhertoyek yekane wekî nasnameyek bikar bînin. Carinan dibe ku me gelek hawîrdorên hilberînê hebin. Û ji bo her hawîrdorê dibe ku em hewceyê şaxek veavakirinê ya cihêreng bikin. Ji ber vê yekê veavakirin dibe ku bi şax û guhertoyê were binav kirin da ku bi rengek yekta mîhengên cihêreng nas bikin. Her etîket û guhertoyek şaxek bi yekhevek girêkên belavbûyî, port, çavkaniyên derveyî, guhertoyên pirtûkxaneya polê ya li ser her girêkê re têkildar e. Li vir em ê tenê şaxê yekane veşêrin û veavakirinan bi guhertoyek dehek sê pêkhatî (1.2.3) ve nas bikin, bi heman rengî wekî hunerên din.

Di hawîrdorên nûjen de pelên mîhengê êdî bi destan nayên guhertin. Bi gelemperî em hilberînin
pelên mîhengê di dema danînê de û tu carî dest nede wan paşan. Ji ber vê yekê mirov dikare bipirse çima em hîn jî formata nivîsê ji bo pelên veavakirinê bikar tînin? Vebijarkek guncan ev e ku meriv veavakirinê di hundurê yekîneyek berhevokê de bi cîh bike û ji pejirandina veavakirina-dema berhevkirinê sûd werbigire.

Di vê postê de em ê ramana domandina veavakirinê di hunera berhevkirî de lêkolîn bikin.

Veavakirina berhevkirî

Di vê beşê de em ê mînakek veavakirina statîk nîqaş bikin. Du karûbarên hêsan - karûbarê echo û muwekîlê karûbarê echo têne mîheng kirin û bicîh kirin. Dûv re du pergalên cûda yên dabeşkirî yên bi her du karûbaran têne destnîşan kirin. Yek ji bo veavakirina yek girêk û ya din jî ji bo veavakirina du girêkan e.

Pergalek belavkirî ya tîpîk ji çend girêkan pêk tê. Giran dikarin bi karanîna hin celeban bêne nas kirin:

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

an tenê

case class NodeId(hostName: String)

an jî jî

object Singleton
type NodeId = Singleton.type

Van nod rolên cihêreng pêk tînin, hin karûbaran dimeşînin û divê karibin bi girêdanên TCP/HTTP bi girêkên din re têkilî daynin.

Ji bo girêdana TCP bi kêmanî jimareyek portê hewce ye. Em jî dixwazin pê ewle bin ku xerîdar û server heman protokolê diaxivin. Ji bo modela pêwendiyek di navbera girêkan de em çîna jêrîn ragihînin:

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

ko Port tenê ye Int di çarçoveya destûr de:

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

Cûreyên paqijkirî

Dîtin nirxandin pirtûkxane. Bi kurtasî, ew dihêle ku meriv astengiyên dema berhevkirinê li celebên din zêde bike. Di vê rewşê de Int tenê destûr tê dayîn ku nirxên 16-bit hene ku dikarin hejmara portê temsîl bikin. Ji bo vê nêzîkatiya veavakirinê pêdivî bi karanîna vê pirtûkxaneyê tune. Ew tenê pir baş xuya dike.

Ji bo HTTP (REST) dibe ku em rêyek karûbarê jî hewce bikin:

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

Tîpa Phantom

Ji bo ku di dema berhevkirinê de protokolê nas bikin em taybetmendiya Scala ya ragihandina argûmana tîpê bikar tînin Protocol ku di polê de nayê bikaranîn. Ew tê gotin cureyê fantom. Di dema xebitandinê de em kêm kêm hewceyî mînakek nasnameyek protokolê ne, ji ber vê yekê em wê hilnagirin. Di dema berhevkirinê de ev celeb fantom ewlehiya celebek din dide. Em nikarin portê bi protokola nerast derbas bikin.

Yek ji protokolên ku herî zêde tê bikar anîn REST API bi serialîzasyona Json e:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

ko RequestMessage celebê bingehîn ya peyamên ku xerîdar dikare ji serverê re bişîne ye û ResponseMessage peyama bersivê ji serverê ye. Bê guman, em dikarin danasînên protokola din ên ku protokola ragihandinê bi rastbûna xwestinê diyar dikin biafirînin.

Ji bo mebestên vê postê em ê guhertoyek hêsan a protokolê bikar bînin:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

Di vê protokolê de peyama daxwaznameyê li url-ê tê pêvekirin û peyama bersivê wekî rêzika sade tê vegerandin.

Veavakirinek karûbar dikare bi navê karûbar, berhevokek port û hin pêwendiyan were diyar kirin. Çend awayên mimkun hene ku meriv çawa van hemî hêmanan di Scala de temsîl dike (mînak, HList, cureyên daneya cebrî). Ji bo mebestên vê postê em ê Patterna Cake bikar bînin û perçeyên hevgirtî (modul) wekî taybetmendî temsîl bikin. (Nimûneya kekê ji bo vê nêzîkatiya veavakirina berhevkirî ne pêdivî ye. Ew tenê yek pêkanînek gengaz a ramanê ye.)

Girêdayîn dikarin bi karanîna Nimûneya Cake wekî xalên dawiya girêkên din werin destnîşan kirin:

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

Karûbarê Echo tenê pêdivî ye ku portek were mîheng kirin. Û em eşkere dikin ku ev port protokola echo piştgirî dike. Bala xwe bidinê ku em ne hewce ne ku di vê gavê de portek taybetî diyar bikin, ji ber ku taybetmendî destûrê dide daxuyandên rêbazên abstrakt. Ger em rêbazên razber bikar bînin, berhevkar dê di mînakek veavakirinê de bicîhkirinê hewce bike. Li vir me pêkanîna (8081) û ew ê wekî nirxa xwerû were bikar anîn heke em wê di veavakirinek konkret de derbas bikin.

Em dikarin di veavakirina muwekîlê karûbarê echo de pêwendiyek ragihînin:

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

Girêdayîn xwedî heman celebê ye echoService. Bi taybetî jî heman protokolê dixwaze. Ji ber vê yekê, em dikarin pê bawer bin ku ger em van her du girêdanan girêbidin ew ê rast bixebitin.

Xizmetên pêkanîna

Karûbarek pêdivî bi fonksiyonek heye ku dest pê bike û bi dilşewatî were girtin. (Qanûna girtina karûbarek ji bo ceribandinê krîtîk e.) Dîsa çend vebijarkên diyar kirina fonksiyonek wusa ji bo konfigurasyonek diyarkirî hene (mînak, em dikarin çînên tîpan bikar bînin). Ji bo vê postê em ê dîsa Modela Cake bikar bînin. Em dikarin karûbarek bikar bînin temsîl bikin cats.Resource ku jixwe veqetandin û berdana çavkaniyê peyda dike. Ji bo ku em çavkaniyek bi dest bixin divê em mîhengek û hin çarçoveyek dema xebitandinê peyda bikin. Ji ber vê yekê fonksiyona destpêkirina karûbarê dibe ku wiha xuya bike:

  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 - celebê veavakirina ku ji hêla destpêka vê karûbarê ve tê xwestin
AddressResolver - Tiştek dema xebitandinê ya ku jêhatîbûna wergirtina navnîşanên rastîn ên girêkên din heye (ji bo hûrguliyan bixwînin).

cureyên din jê tên cats:

F[_] - celebê bandorê (Di rewşa herî hêsan de F[A] dikare tenê be () => A. Di vê postê de em ê bikar bînin cats.IO.)
Reader[A,B] - kêm-zêde hevwateya fonksiyonê ye A => B
cats.Resource - riyên bidestxistin û berdanê hene
Timer - destûrê dide razanê/pîvana demê
ContextShift - analog ji ExecutionContext
Applicative - pêça fonksiyonên bi bandor (hema hema monad) (dibe ku em di dawiyê de wê bi tiştek din veguherînin)

Bi karanîna vê navberê em dikarin çend karûbaran bicîh bikin. Mînakî, karûbarek ku tiştek nake:

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

(Dîtin Koda Çavkaniyê ji bo pêkanîna karûbarên din - xizmeta echo,
muwekîlê echo û kontrolkerên jiyana.)

Nod tiştek yekane ye ku çend karûbaran dimeşîne (destpêkirina zincîreka çavkaniyan ji hêla Cake Pattern ve tê çalak kirin):

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

Bala xwe bidinê ku di girêkê de em cureya rast a veavakirinê ya ku ji vê girêkê re hewce dike diyar dikin. Berhevkar nahêle ku em objektê (Cake) bi tîpek kêm ava bikin, ji ber ku her taybetmendiyek karûbar li ser Config awa. Di heman demê de em ê nikaribin node dest pê bikin bêyî ku mîhengek bêkêmasî peyda bikin.

Çareserkirina navnîşana nodê

Ji bo ku em têkiliyek saz bikin, ji bo her girêkek navnîşek mêvandarek rastîn hewce dike. Dibe ku ew ji beşên din ên veavakirinê dereng were zanîn. Ji ber vê yekê, ji me re rêyek hewce ye ku nexşeyek di navbera nasnameya nodê û navnîşana wê ya rastîn de peyda bike. Ev nexşe fonksiyonek e:

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

Ji bo pêkanîna fonksiyonek weha çend awayên gengaz hene.

Ger em navnîşanên rastîn berî bicîhkirinê, di dema destpêkirina mêvandarên nodê de zanibin, wê hingê em dikarin koda Scala bi navnîşanên rastîn biafirînin û paşê çêkirinê bimeşînin (ku kontrolên dema berhevkirinê pêk tîne û dûv re koma testa entegrasyonê dimeşîne). Di vê rewşê de fonksiyona me ya nexşeyê bi statîkî tê zanîn û dikare bi tiştek wekî a-yê were hêsan kirin Map[NodeId, NodeAddress].
Carinan em navnîşanên rastîn tenê di demek paşîn de werdigirin dema ku girê bi rastî dest pê dike, an jî navnîşanên girêkên ku hêj nehatine destpêkirin tune ne. Di vê rewşê de dibe ku me karûbarek vedîtinê hebe ku berî hemî girêkên din dest pê kiriye û dibe ku her nodek navnîşana xwe di wê karûbarê de reklam bike û bibe aboneyê girêdanan.
Ger em dikarin biguherînin /etc/hosts, em dikarin navên mêvandar ên pêşwextkirî bikar bînin (wek my-project-main-node û echo-backend) û tenê di dema danînê de vî navî bi navnîşana ip-ê re têkildar bikin.

Di vê postê de em van bûyeran bi hûrgulî venaşêrin. Bi rastî di mînaka pêlîstoka me de hemî girêk dê xwediyê heman navnîşana IP-yê bin - 127.0.0.1.

Di vê postê de em ê du sêwiranên pergalê yên belavkirî bifikirin:

Plansaziya yekane, ku hemî karûbar li ser girêka yekane têne danîn.
Plansaziya du nodê, ku karûbar û xerîdar li ser girêkên cihê ne.

Veavakirina ji bo a yek girêk plansazkirin wiha ye:

Veavakirina yekane

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

Li vir em veavakirinek yekane diafirînin ku hem veavakirina server û hem jî xerîdar dirêj dike. Di heman demê de em kontrolkerek çerxa jiyanê mîheng dikin ku dê bi gelemperî piştî xerîdar û serverê biqede lifetime navber derbas dibe.

Heman komek pêkanîn û veavakirina karûbarê dikare were bikar anîn da ku nexşeya pergalê bi du girêkên cihêreng biafirîne. Em tenê hewce ne ku biafirînin du mîhengên girêk cuda bi karûbarên guncan re:

Veavakirina du girêkan

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

Binêrin ka em çawa girêdayîbûnê diyar dikin. Em karûbarê girêka din a pêşkêşkirî wekî pêwendiya girêka heyî binav dikin. Cûreya girêdayîbûnê tê kontrol kirin ji ber ku ew celebek fantom heye ku protokolê vedibêje. Û di dema xebitandinê de em ê nasnameya nodê ya rast hebe. Ev yek ji aliyên girîng ên nêzîkatiya veavakirina pêşniyarkirî ye. Ew ji me re kapasîteya ku em tenê carekê portê saz bikin û pê ewle bibin ku em porta rast referans dikin.

Pêkanîna du nod

Ji bo vê veavakirinê em tam pêkanînên karûbaran bikar tînin. Ti guhertin tune. Lêbelê, em du pêkanînên nodê yên cihêreng ên ku komek karûbarên cihêreng vedigirin diafirînin:

  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
  }

Nodeya yekem serverê pêk tîne û ew tenê pêdivî bi veavakirina aliyê serverê heye. Nodeya duyemîn xerîdar bicîh tîne û pêdivî bi beşek din a mîhengê heye. Her du girêk hin taybetmendiyên jiyanê hewce dikin. Ji bo mebestên vê girêka karûbarê postê dê jiyanek bêdawî hebe ku dikare were bikar anîn SIGTERM, dema ku muwekîlê echo dê piştî demajoya dawî ya mîhengkirî bi dawî bibe. Binêre serîlêdana destpêkê Ji bo hûragahiyan.

Pêvajoya pêşveçûna giştî

Ka em bibînin ka ev nêzîkatî çawa awayê ku em bi veavakirinê re dixebitin diguhezîne.

Veavakirina wekî kod dê were berhev kirin û hunerek çêbike. Maqûl xuya dike ku hunera mîhengê ji hunerên kodê yên din veqetînin. Bi gelemperî em dikarin li ser heman bingehê kodê gelek mîhengan hebin. Û bê guman, em dikarin gelek guhertoyên şaxên mîhengên cihêreng hebin. Di veavakirinekê de em dikarin guhertoyên taybetî yên pirtûkxaneyan hilbijêrin û her ku em vê veavakirinê bicîh bikin ev ê domdar bimîne.

Guhertinek vesazkirinê dibe guheztina kodê. Ji ber vê yekê divê ew ji hêla heman pêvajoya pêbaweriya kalîteyê ve were vegirtin:

Bilêt -> PR -> vekolîn -> hevgirtin -> entegrasyona domdar -> bicihkirina domdar

Encamên jêrîn ên nêzîkbûnê hene:

Veavakirin ji bo mînakek pergalek taybetî hevgirtî ye. Wusa dixuye ku rêyek tune ku têkiliyek xelet di navbera girêkan de hebe.
Guhertina veavakirinê tenê di yek nodê de ne hêsan e. Têkeve û guhertina hin pelên nivîsê ne maqûl xuya dike. Ji ber vê yekê vekêşana mîhengê kêmtir gengaz dibe.
Guhertinên mîhengê yên piçûk ne hêsan in ku bêne çêkirin.
Piraniya guhertinên mîhengê dê heman pêvajoya pêşkeftinê bişopînin, û ew ê hin vekolînê derbas bike.

Ma ji bo veavakirina hilberînê pêdivî bi depoyek cihê heye? Veavakirina hilberînê dibe ku agahdariya hesas hebe ku em dixwazin ji gelek kesan dûr bixin. Ji ber vê yekê dibe ku hêja ye ku depoyek veqetandî ya bi gihîştina tixûbdar a ku dê veavakirina hilberînê hebe bigire. Dibe ku em veavakirinê li du beşan dabeş bikin - yek ku pîvanên herî vekirî yên hilberînê vedihewîne û ya ku beşa veşartî ya veavakirinê vedihewîne. Ev ê dihêle ku piraniya pêşdebiran bigihîje piraniya parameteran dema ku gihîştina tiştên bi rastî hesas sînordar bike. Bi karanîna taybetmendiyên navîn ên bi nirxên parameterê yên xwerû re hêsan e ku meriv vê yekê pêk bîne.

variations

Werin em erênî û neyînîyên nêzîkatiya pêşniyarkirî li gorî teknîkên rêveberiya mîhengê yên din bibînin.

Berî her tiştî, em ê çend alternatîfan ji aliyên cûda yên awayê pêşniyarkirî yê mijûlbûna bi veavakirinê re navnîş bikin:

Pelê nivîsê li ser makîneya armancê.
Hilberîna nirx-kilît a navendî (wek etcd/zookeeper).
Parçeyên binepêvajoyê yên ku dikarin bêyî destpêkirina pêvajoyê ji nû ve werin mîheng kirin/destpêkirin.
Veavakirina derveyî huner û guhertoya kontrolê.

Pelê nivîsê di warê rastkirinên ad-hoc de hin nermbûnê dide. Rêvebirê pergalê dikare têkeve girêka armancê, guhertinek çêbike û bi tenê karûbarê ji nû ve bide destpêkirin. Dibe ku ev ji bo pergalên mezintir ne baş be. Li pişt guherînê tu şop namîne. Guhertin ji hêla cotek çavên din ve nayê vekolandin. Dibe ku zehmet be ku meriv bibîne ka çi bûye sedema guhertinê. Ew nehatiye ceribandin. Ji perspektîfa pergala belavkirî, rêveberek bi tenê dikare ji bîr bike ku veavakirinê di yek ji girêkên din de nûve bike.

(Btw, heke di dawiyê de hewce be ku dest bi karanîna pelên mîhengê nivîsê bikin, em ê tenê parser + erêkerê ku dikarin heman hilberînê zêde bikin Config binivîsin û ew ê bes be ku hûn dest bi karanîna mîhengên nivîsê bikin. Ev jî nîşan dide ku tevliheviya veavakirina dema berhevkirinê ji tevliheviya mîhengên-based nivîsê piçekî piçûktir e, ji ber ku di guhertoya-based nivîsê de em hewceyê kodek din in.)

Hilberîna key-nirxa navendî mekanîzmayek baş e ji bo belavkirina parametreyên meta serîlêdanê. Li vir pêdivî ye ku em li ser tiştên ku em wekî nirxên vesazkirinê dihesibînin û tenê dane çi ye bifikirin. Fonksiyonek dan C => A => B em bi gelemperî ji nirxên kêm kêm diguherin re dibêjin C "veavakirin", di heman demê de ku gelek caran dane guhertin A - tenê daneyan têxe. Divê veavakirin ji daneyan zûtir ji fonksiyonê re were peyda kirin A. Ji ber vê ramanê em dikarin bibêjin ku ew pirbûna guherînên ku dikare were bikar anîn da ku daneyên vesazkirinê ji tenê daneyan cûda bike, tê hêvî kirin. Di heman demê de dane bi gelemperî ji çavkaniyek (bikarhêner) tê û veavakirin ji çavkaniyek cûda (rêveber) tê. Mijûlbûna bi parametreyên ku piştî pêvajoya destpêkirinê dikare were guheztin dibe sedema zêdebûna tevliheviya serîlêdanê. Ji bo pîvanên weha em ê neçar in ku mekanîzmaya radestkirina wan, parsandin û verastkirin, bi nirxên nerast bi rê ve bibin. Ji ber vê yekê, ji bo ku tevliheviya bernameyê kêm bikin, em ê çêtir e ku hejmara parametreyên ku dikarin di dema xebitandinê de biguhezînin (an jî wan bi tevahî ji holê rakin) kêm bikin.

Ji perspektîfa vê postê divê em cûdahiyek di navbera pîvanên statîk û dînamîkî de bikin. Ger mantiqa karûbar di dema xebitandinê de guheztina hindik a hin pîvanan hewce bike, wê hingê em dikarin ji wan re wekî pîvanên dînamîkî bi nav bikin. Wekî din ew statîk in û dikarin bi karanîna nêzîkatiya pêşniyarkirî werin mîheng kirin. Ji bo veavakirina dînamîk dibe ku nêzîkatiyên din hewce bibin. Mînakî, dibe ku beşên pergalê bi pîvanên veavakirina nû ve bi rengek wekhev ji nû ve destpêkirina pêvajoyên veqetandî yên pergalek belavkirî ji nû ve werin destpêkirin.
(Nêrîna min a dilnizm ev e ku meriv ji nûavakirina dema xebitandinê dûr bixe ji ber ku ew tevliheviya pergalê zêde dike.
Dibe ku hêsantir be ku meriv ji nûve destpêkirina pêvajoyên tenê bi piştgiriya OS-ê ve girêdayî be. Lêbelê, dibe ku ew her gav ne gengaz be.)

Yek aliyek girîng a karanîna veavakirina statîk ku carinan dihêle ku mirov konfigurasyona dînamîkî (bêyî sedemên din) bihesibîne, dema nûvekirina veavakirinê de dema karûbarê domdar e. Bi rastî, heke pêdivî ye ku em di veavakirina statîk de guhertinan bikin, pêdivî ye ku em pergalê ji nû ve bidin destpêkirin da ku nirxên nû bi bandor bibin. Pêdiviyên ji bo demdirêjiyê ji bo pergalên cihêreng diguhezin, ji ber vê yekê dibe ku ew ne ew çend krîtîk be. Ger ew krîtîk be, wê hingê pêdivî ye ku em ji bo ji nû ve destpêkirina pergalê pêş de plan bikin. Ji bo nimûne, em dikarin bicih bikin Têkiliya AWS ELB diherike. Di vê senaryoyê de gava ku em hewce ne ku pergalê ji nû ve bidin destpêkirin, em mînakek nû ya pergalê bi paralel dest pê dikin, dûv re ELB vediguhezînin wê, di heman demê de dihêlin pergala kevn karûbarê girêdanên heyî temam bike.

Li ser girtina veavakirinê di hundurê hunera guhertoya an li derve de çi? Ragirtina veavakirinê di hundurê hunerê de tê vê wateyê ku di pir rewşan de ev veavakirin heman pêvajoya pêbaweriya kalîteyê wekî hunerên din derbas kiriye. Ji ber vê yekê mirov dikare piştrast be ku veavakirin qalîteya baş û pêbawer e. Berevajî veavakirina di pelek cuda de tê vê wateyê ku tu şopên kê û çima di wê pelê de guherandine tune. Ma ev girîng e? Em bawer dikin ku ji bo piraniya pergalên hilberînê çêtir e ku meriv xwedan mîhengek domdar û bilind be.

Guhertoya hunerê dihêle ku meriv fêr bibe kengê ew hatî afirandin, kîjan nirxan dihewîne, kîjan taybetmendî têne çalak kirin/neçalak kirin, kî berpirsiyar e ku her guhertinek di veavakirinê de çêbike. Dibe ku hin hewildan hewce bike ku mîhengê di hundurê hunerê de bihêle û ew bijartinek sêwiranê ye ku were çêkirin.

Pros & Neyra

Li vir em dixwazin hin avantajên xwe ronî bikin û hin dezawantajên nêzîkatiya pêşniyarkirî nîqaş bikin.

Feyda

Taybetmendiyên veavakirina berhevkirî ya pergalek belavbûyî ya bêkêmasî:

Kontrola statîk a veavakirinê. Ev astek pêbaweriyek bilind dide, ku konfigurasyon rast e ku ji hêla cûrbecûr ve girêdayî ye.
Zimanek dewlemend a veavakirinê. Bi gelemperî nêzîkatiyên din ên veavakirinê bi piranî bi veguheztina guhêrbar ve têne sînorkirin.
Bi karanîna Scala meriv dikare cûrbecûr taybetmendiyên zimanî bikar bîne da ku veavakirinê baştir bike. Mînakî, em dikarin taybetmendiyan bikar bînin da ku nirxên xwerû peyda bikin, tiştên ku çarçoveyek cûda destnîşan bikin, em dikarin serî lê bidin. vals tenê carekê di çarçoveya derveyî (DRY) de tê diyarkirin. Mimkun e ku meriv rêzikên wêjeyî, an mînakên hin çînan bikar bîne (Seq, Map, etc.).
DSL. Scala ji bo nivîskarên DSL-ê piştgirîyek maqûl heye. Meriv dikare van taybetmendiyan bikar bîne da ku zimanek veavakirinê saz bike ku rehettir û ji bikarhênerê dawîn re heval e, da ku veavakirina paşîn bi kêmanî ji hêla bikarhênerên domainê ve were xwendin.
Yekbûn û hevrêziya di nav girêkan de. Yek ji feydeyên mîhengê ji bo tevahiya pergala belavbûyî li yek cîhê ev e ku hemî nirx bi hişkî carekê têne destnîşan kirin û dûv re li hemî deverên ku em hewce ne ji nû ve têne bikar anîn. Di heman demê de daxuyaniyên porta ewle binivîsin ku piştrast bikin ku di hemî mîhengên rast ên gengaz de girêkên pergalê dê bi heman zimanî biaxivin. Di navbera girêkan de girêdanên eşkere hene ku ji bîrkirina peydakirina hin karûbaran dijwar dike.
Kalîteya bilind a guhertinan. Nêzîkatiya giştî ya derbaskirina mîhengê di pêvajoya normal PR-ê de diguhezîne standardên bilind ên kalîteyê jî di veavakirinê de saz dike.
Guhertinên veavakirina hevdemî. Dema ku em di veavakirinê de guhertinan çêdikin, bicîhkirina otomatîkî piştrast dike ku hemî girêk têne nûve kirin.
Hêsankirina sepanê. Serlêdan ne hewce ye ku veavakirinê parsek bike û rast bike û nirxên mîhengê yên nerast bi dest bixe. Ev serîlêdana giştî hêsan dike. (Hinek zêdebûna tevliheviyê di veavakirinê de bi xwe ye, lê ew lihevhatinek bi zanebûn ber bi ewlehiyê ve ye.) Vegera veavakirina asayî pir hêsan e - tenê perçeyên winda zêde bikin. Hêsantir e ku meriv bi veavakirina berhevkirî dest pê bike û pêkanîna perçeyên din ji bo hin demên paşîn paşde bixe.
Veavakirina Versiyonkirî. Ji ber ku guheztinên mîhengê heman pêvajoya pêşkeftinê dişopînin, di encamê de em hunerek bi guhertoyek bêhempa distînin. Ew rê dide me ku ger hewce be veavakirinê vegerînin. Tewra em dikarin mîhengek ku salek berê hatî bikar anîn bicîh bikin û ew ê tam bi heman rengî bixebite. Veavakirina stabîl pêşbînbûn û pêbaweriya pergala belavkirî baştir dike. Veavakirin di dema berhevkirinê de tê rast kirin û bi hêsanî nikare li ser pergalek hilberînê were guheztin.
Modularity. Çarçoveya pêşniyarkirî modular e û modul dikarin bi awayên cihêreng werin berhev kirin
veavakirinên cihêreng piştgirî bikin (sazkirin/sazkirin). Bi taybetî, mimkun e ku meriv pîvanek piçûkek yekane û mîhengek pir girêkek mezin hebe. Maqûl e ku meriv gelek layoutên hilberînê hebin.
Testing. Ji bo mebestên ceribandinê meriv dikare karûbarek mockek bicîh bîne û wê wekî pêwendiyek bi rengek ewledar bikar bîne. Çend sêwiranên ceribandinê yên cihêreng ên bi beşên cihêreng ên ku ji hêla tinazên xwe ve hatine veguheztin dikarin bi hevdemî werin domandin.
testkirina entegrasyonê. Carinan di pergalên belavbûyî de meşandina ceribandinên entegrasyonê dijwar e. Bi karanîna nêzîkatiya diyarkirî ji bo nivîsandina veavakirina ewle ya pergala bêkêmasî ya belavkirî, em dikarin hemî beşên belavkirî li ser serverek yekane bi rengek kontrolkirî bimeşînin. Mînakirina rewşê hêsan e
dema ku yek ji karûbaran tune dibe.

dezawantajên

Nêzîkatiya mîhengê ya berhevkirî ji veavakirina "normal" cûda ye û dibe ku ew li gorî hemî hewcedariyan nebe. Li vir çend kêmasiyên konfigurasyona berhevkirî hene:

Veavakirina statîk. Dibe ku ew ji bo hemî serlêdanan ne maqûl be. Di hin rewşan de, pêdivî ye ku zû rastkirina veavakirina di hilberînê de bêyî derbaskirina hemî tedbîrên ewlehiyê. Ev nêzîkatî dijwartir dike. Piştî ku guheztinek di veavakirinê de were çêkirin, berhevkirin û ji nû ve veqetandin hewce ye. Ev hem taybetmendî û hem jî bar e.
nifşê veavakirinê. Dema ku mîheng ji hêla hin amûrek xweseriyê ve tête çêkirin, ev nêzîkatî berhevkirina paşîn hewce dike (ku dibe ku di encamê de têk biçe). Dibe ku ji bo entegrekirina vê gavê zêde di nav pergala avakirinê de hewildanek zêde hewce bike.
Instruments. Gelek amûrên ku îro têne bikar anîn hene ku xwe dispêrin mîhengên-based text. Hin ji wan
dema ku veavakirin were berhev kirin dê neyê sepandin.
Guhertinek di hişmendiyê de hewce ye. Pêşdebir û DevOps bi pelên veavakirina nivîsê nas in. Fikra berhevkirina mîhengê dibe ku ji wan re xerîb xuya bike.
Berî danasîna veavakirina berhevkirî pêvajoyek pêşkeftina nermalava kalîteya bilind hewce ye.

Hin sînorên nimûneya pêkanîn hene:

Ger em konfigurasyona zêde ya ku ji hêla bicîhkirina nodê ve nayê xwestin peyda bikin, berhevkar dê ji me re nebe alîkar ku em pêkanîna neamade bibînin. Ev dikare bi karanîna çareser kirin HList an ADTs (dersên dozê) ji bo veavakirina nodê li şûna taybetmendî û Nimûneya Cake.
Pêdivî ye ku em di pelê mîhengê de hin boilerplate peyda bikin: (package, import, object daxuyaniyên;
override def's ji bo parametreyên ku nirxên xwerû hene). Dibe ku ev bi qismî bi karanîna DSL-ê were çareser kirin.
Di vê postê de em veavakirina dînamîkî ya komikên girêkên mîna hev nagirin.

Xelasî

Di vê postê de me fikra temsîlkirina veavakirinê rasterast di koda çavkaniyê de bi rengek ewledar nîqaş kir. Nêzîkatî dikare di gelek sepanan de wekî şûna xml- û mîhengên din ên li ser nivîsê were bikar anîn. Tevî ku mînaka me di Scala de hatî bicîh kirin, ew dikare ji bo zimanên din ên berhevkirî jî were wergerandin (mîna Kotlin, C#, Swift, hwd.). Mirov dikare vê rêbazê di projeyek nû de biceribîne û heke ew baş li hev neke, berê xwe bide awayê kevn.

Bê guman, veavakirina berhevkirî pêvajoyek pêşkeftina kalîteya bilind hewce dike. Di vegerê de ew soz dide ku mîhengek zexm bi qalîteya wekhev peyda bike.

Ev nêzîkatî dikare bi awayên cûrbecûr were dirêj kirin:

Meriv dikare makroyan bikar bîne da ku verastkirina vesazkirinê pêk bîne û di dema berhevkirinê de di rewşek têkçûnek astengiyên karsaz-mantiqê de têk biçin.
DSL dikare were sepandin da ku veavakirinê bi awayek domen-bikarhêner-heval temsîl bike.
Rêvebiriya çavkaniyê ya dînamîkî bi verastkirinên veavakirina otomatîkî. Mînakî, dema ku em hejmara girêkên komê eyar bikin, dibe ku em bixwazin (1) girêk konfigurasyona piçûk guheztin bistînin; (2) rêveberê komê ku agahdariya girêkên nû bistînin.

Spas

Ez dixwazim spasiyên xwe ji Andrey Saksonov, Pavel Popov, Anton Nehaev re bibêjim ku li ser pêşnûmeya vê postê bertekên îlhamê dan ku alîkariya min kir ku ew zelaltir bikim.

Source: www.habr.com

Veavakirina berhevkirî ya pergalek belavkirî