Sigurado akong nangyari na ito sa iyo: sinimulan mo ang isang proyekto na puno ng sigasig, nagtayo ka ng isang monolito dahil ito ay mabilis i-deploy At lahat ay dumadaloy. Sa una ay kahanga-hanga; ang mga tawag sa pagitan ng mga function ay agaran at hindi mo napapakomplikado ang mga bagay sa network. Ngunit darating ang punto na ang code ay lumalaki nang husto na ang anumang maliit na pagbabago ay nagiging isang bangungot ng mga dependency at ang pag-deploy ay mukhang isang suicide mission.
Kapag ang codebase ay nagiging mahirap pamahalaan at ang mga oras ng paghahatid ay tumataas nang husto, ang malaking tanong ay lumilitaw: paano tayo makakalabas dito nang hindi nasisira ang lahat? Ang paglipat sa isang microservices o feature module architecture ay hindi lamang tungkol sa pagbabago kung saan matatagpuan ang code, kundi tungkol sa pagbibigay ng ganap na pagbabago ng kaisipan upang makakuha ng scalability at operational liksi.
Ang pader ng monolito: Bakit pa ito iiwan?
Ang isang mahusay na pagkakagawa ng monolito ay kayang tumagal nang malaki, ngunit mayroon itong mga limitasyon. Ang pangunahing problema ay Nakadikit na lahat.Kung gusto mo lang palakihin ang payments module dahil may mga benta, kailangan mong kopyahin ang buong application, na mag-aaksaya ng memory at CPU sa mga bahaging hindi ginagamit ng iba. Bukod pa rito, ang natitira sa iyo ay nakatali sa isang teknolohiyaKung gusto mong subukan ang isang bagong wika para sa isang partikular na functionality, kakailanganin mong isulat muli ang buong proyekto.
Bukod pa rito, mabagal at mapanganib na mga pag-deployDahil ang anumang error sa isang sulok ng code ay maaaring magpabagsak sa buong platform, ang pangamba sa pag-deploy ay nagiging totoong totoo. Nagsisimulang magkagulo ang mga team dahil sa mga conflict sa bersyon, at ang teknikal na utang Ito ay naiipon hanggang sa ang sistema ay maging matigas at mabagal na umunlad.
Mga ruta ng migrasyon: Mga estratehiya at padron
Huwag basta-basta sumubok ng "Big Bang" na pamamaraan (muling pagsusulat ng lahat mula sa simula), dahil ito ay magiging sanhi ng kapahamakan at labis na gastos. Sa isip, dapat mong gawin ito. unti-unting pinuputol ang bato sa pamamagitan ng mga taktikang ito:
- Disenyong Pinapatakbo ng Domain (DDD): Ang susi ay ang pagtukoy sa mga kontekstong pinaghihiwalayHuwag hatiin ayon sa mga teknikal na layer, kundi ayon sa mga domain ng negosyo (halimbawa: mga user, order, pagsingil).
- Modular na Monolito: Bago paghiwa-hiwalayin ang mga serbisyo sa iba't ibang server, muling ayusin ang code sa loob. Gumawa ng mga mahusay na natukoy na module sa loob ng parehong deployment upang linisin ang lugar bago ang huling pagtalon.
- Disenyo ng Strangler Fig (Strangler Fig): Ito ang star method. Binubuo ito ng paglikha ng mga bagong serbisyo sa paligid ng monolith. Unti-unti, ang bagong functionality Unti-unti nitong binabalot ang lumang sistema. hanggang sa tuluyang mawala ang monolito.
- Parallel Run: Para sa mga ayaw sumugal, ang pattern na ito ay nagbibigay-daan sa paglulunsad ng microservice kasama ng monolith. Kinokontrol pa rin ng lumang sistema ang kasalukuyang sistema, ngunit pinoproseso ng bago ang parehong impormasyon at Ang mga resulta ay inihambing para matiyak na magkakasya ang lahat bago gawin ang huling paglipat.
- Sangay ayon sa Abstraksyon: Mainam kapag ang isang tungkulin ay lubhang nakabaon. Lumilikha ka ng isang abstraction layer (interface) na ginagamit ng code. Habang tumatakbo pa rin ang sistema, ipapatupad mo ang bagong serbisyo sa likod ng interface na iyon at pagkatapos ay babaguhin ang daloy ng data.
Ang Palaisipan ng Database
Ang pagdadala ng code sa mga microservice ay madali kumpara sa paghiwalayin ang datosSa isang monolith, mayroon kang iisang higanteng database; sa mga microservice, dapat pamahalaan ng bawat serbisyo ang sarili nitong data. Narito ang ilang mga paraan upang lapitan ito:
Kung hindi mo ma-access ang kasalukuyang database, maaari mong gamitin ang Mga View ng Database para makita lamang ng bawat serbisyo ang kailangan nito, bagama't mayroon itong problema na kadalasan ay read-only ang mga ito. Ang isa pang pagpipilian ay ang Serbisyo sa Pagbabalot ng Databasena karaniwang lumilikha ng isang maliit na serbisyo na bumabalot sa database at naglalantad ng isang API, na nagbibigay sa iyo ng oras upang ilipat ang mga scheme nang hindi nasisira ang kliyente.
Para sa mas kumplikadong mga kaso, ang pattern Database bilang isang Interface ng Serbisyo Pinaghihiwalay nito ang mga pagbasa mula sa mga pagsulat, na lumilikha ng isang panlabas na database para lamang sa mga query at isang panloob para sa serbisyo, na naka-synchronize gamit ang isang mapping engine. Kung naghahanap ka ng unti-unting paglipat ng data, ang Manunulat ng Pagsubaybay Pinapayagan nito ang pagsulat sa bagong database habang pinapanatili ang luma bilang pangunahing mapagkukunan, unti-unting inililipat ang mga mamimili.
Kalidad at Kaligtasan: Ang panangga ng sistema
Kapag mayroon kang sampung serbisyo sa halip na isa, tumataas ang posibilidad na may magkamali. Hindi mo kayang bayaran iyon. mga shortcut sa pagsubokMahalagang ipatupad ang isang multi-layered na iskema ng AQA: mula sa pagsubok ng yunit gamit ang JUnit o PyTest, mula sa pagsubok ng kontrata gamit ang Pact upang matiyak na ang mga serbisyo ay hindi ipinapaalam sa iba't ibang wika, hanggang sa pagsubok ng pagkarga gamit ang JMeter upang makita kung saan nagka-crash ang sistema.
Kapag nagde-deploy, kalimutan ang pamamaraang "click and pray". Gamitin Mga Paglabas ng Canary Para subukan ang feature sa 5% ng mga user at tingnan kung may anumang bug. O mas mabuti pa, ang paglulunsad Asul/BerdeMayroon kang dalawang magkaparehong kapaligiran; kung ang berdeng bersyon ay hindi gumana, babalik ka sa asul na bersyon sa loob ng isang segundo nang hindi napapansin ng gumagamit. Ang paggamit ng Mga Flag ng Tampok Mahalaga rin ito para sa pag-activate o pag-deactivate ng mga function sa real time nang hindi kinakailangang muling i-deploy ang code.
Operabilidad at Patuloy na Pag-optimize
Kapag lumipat ka na, hindi natatapos ang trabaho. Kailangan mo kabuuang kakayahang maobserbahanAng mga tool tulad ng Prometheus, Grafana, o ang ELK Stack ay mahalaga para sa pagsubaybay sa mga log at metrics sa real time, kaya hindi mo lang malalaman na nag-crash ang system dahil tinawagan ka ng isang customer.
Huwag kalimutan ang pagbawi ng kalamidadMagpatupad ng mga incremental backup at geo-redundant storage. Kung sakaling mabigo ang isang data center, dapat ay kayanin ng sistema ang isang awtomatikong failover tungo sa isang ligtas na backup upang hindi matigil ang negosyo.
Ang landas tungo sa modularisasyon ay isang maraton na nangangailangan masusing pagpaplano at pragmatismoAng pinakamahalagang bagay ay iwasan ang tukso ng labis na pag-engineer at tandaan na hindi lahat ng bagay ay kailangang maging isang microservice; kung minsan, ang isang mahusay na modulated na monolith ang pinakaepektibong solusyon. Sa huli, ito ay tungkol sa pagpili ng tool na pinakaangkop sa negosyo, palaging inuuna ang katatagan ng sistema at kakayahang ulitin nang walang takot na maantala ang produksyon.