Sazinieties ar mums, lai saņemtu personalizētu FinMV piedāvājumu, kas pielāgots jūsu vajadzībām.
Jūsu uzņēmuma tehniskajam direktoram, plānojot finanšu platformas palaišanu, būs jāizvēlas projekta arhitektūras variants. Kādas arhitektūras iespējas viņam ir pieejamas un kuru labāk izvēlēties?
Jaunai investīciju platformai ir viena komanda, viena izvietošana un viena datubāze. Izplatītas sistēmas izmaksas šajā posmā pilnībā aiziet uz papildu izdevumiem: tīkla izsaukumiem tur, kur pietiktu ar funkcijas izsaukumu, galu galā panāktu konsekvenci tur, kur pietiktu ar transakciju, un ekspluatācijas slodzi, kurai nav cilvēku.
Tāpēc pēc noklusējuma realizācija ir modulāra: onboarding, piedāvājumi, investīcijas, maksājumi, dokumenti, apkalpošana un pārskati pastāv aiz skaidrām robežām vienā izvietojamā sistēmā. Modulāru to padara nevis mapju struktūra, bet tas, ka katram modulim ir savs līgums, savi dati un savi testi.
Modulis kļūst par atsevišķu servisu, ja tam ir konkrēts pamatojums, un šie pamatojumi ir biznesa, nevis modes:
Tā kā robežas un līgumi jau pastāv, servisa izdalīšana ir plānota darbība, nevis pārrakstīšana. Tieši tas ir mērķis: iespēja paliek atvērta un lēta.
Darbs, kam nav jābloķē lietotājs — norēķinu saskaņošana, dokumentu ģenerēšana, pakalpojumu sniedzēju atgriezeniskie izsaukumi, pārskati — notiek caur rindām. Ziņojumu brokeri, piemēram, RabbitMQ vai Kafka, parādās tad, kad to attaisno slodze vai integrāciju topoloģija, nevis pēc noklusējuma. PostgreSQL paliek ierakstu sistēma; Redis tiek izmantots tur, kur tiešām nepieciešams ātrs kešs vai koordinācija.
Mēs nepārdodam monolītu un nepārdodam mikropakalpojumus. Abi ir atbildes uz jautājumiem, kas vēl nav uzdoti. Mēs arī neveidojam izplatītu sistēmu tikai tāpēc, lai izskatītos solīdi: arhitektūras teātris ir dārgi ekspluatēt un grūti nodot tālāk.
Arhitektūra tiek izvēlēta atbilstoši jūsu mērogam, regulatīvajām saistībām, integrācijām un komandas lielumam, kas to ekspluatēs, — un tā tiek projektēta tā, lai mainītos līdz ar tām.
