Sigana mah puncak hype pikeun microservices aya di tukangeun urang. Kami henteu deui maca tulisan sababaraha kali saminggu "Kumaha kuring mindahkeun monolit kuring ka 150 jasa." Ayeuna kuring ngupingkeun pikiran anu langkung umum: "Kuring henteu resep monolit, kuring ngan ukur paduli efisiensi." Urang malah niténan sababaraha migrasi . Nalika mindahkeun tina hiji aplikasi ageung ka sababaraha jasa anu langkung alit, anjeun kedah ngabéréskeun sababaraha masalah énggal. Hayu urang daptar aranjeunna sakedap-gancang.
Setting: ti kimia dasar nepi ka mékanika kuantum
Nyetél pangkalan data dasar sareng aplikasi kalayan prosés latar tukang mangrupikeun prosés anu cukup lugas. Kuring nyebarkeun readme on Github - sarta mindeng dina sajam, sababaraha jam paling, sagalana jalan jeung kuring ngamimitian proyek anyar. Nambahkeun sareng ngajalankeun kode, sahenteuna pikeun lingkungan awal, dilakukeun dina dinten kahiji. Tapi lamun urang usaha kana microservices, waktos peluncuran awal skyrockets. Leres, ayeuna urang gaduh Docker kalayan orkestra sareng gugusan mesin K8, tapi pikeun programer novice sadayana ieu langkung rumit. Pikeun seueur juniors, ieu mangrupikeun beban anu leres-leres mangrupikeun komplikasi anu teu perlu.
Sistim nu teu gampang ngartos
Hayu urang difokuskeun SMP urang sakedap. Kalayan aplikasi monolithic, upami aya kasalahan, éta gampang pikeun ngalacak sareng langsung ngaléngkah ka debugging. Ayeuna kami ngagaduhan jasa anu ngobrol sareng jasa sanés anu ngantri hiji hal dina beus pesen anu ngolah jasa anu sanés-teras aya kasalahan. Urang kudu nunda sakabéh potongan ieu babarengan pikeun pamustunganana manggihan yén Service A ngajalankeun versi 11, sarta Service E geus ngantosan versi 12. Ieu pisan béda ti log konsolidasi baku kuring: kudu make terminal interaktif / debugger leumpang. ngaliwatan prosés step by step. Debugging jeung pamahaman geus inherently jadi leuwih hese.
Upami éta henteu tiasa di-debug, panginten urang bakal nguji aranjeunna
Integrasi kontinyu sareng pangwangunan kontinyu ayeuna janten lumrah. Kaseueuran aplikasi énggal anu kuring tingali sacara otomatis nyiptakeun sareng ngajalankeun tés sareng unggal rilis énggal sareng ngabutuhkeun tés pikeun dilaksanakeun sareng diulas sateuacan pendaptaran. Ieu mangrupikeun prosés anu saé anu henteu kedah ditinggalkeun sareng parantos janten pergeseran ageung pikeun seueur perusahaan. Tapi ayeuna, pikeun leres-leres nguji jasa éta, kuring kedah narik versi lengkep tina aplikasi kuring. Inget yen insinyur anyar jeung K8 klaster 150 jasa? Nya, ayeuna urang bakal ngajarkeun sistem CI kami kumaha carana ngadamel sadaya sistem ieu pikeun pariksa yén sadayana leres-leres jalanna. Ieu sigana teuing usaha, jadi urang ngan bakal nguji unggal bagian dina isolasi: Kuring yakin yén spésifikasi kami cukup alus, API beresih, sarta gagalna layanan anu terasing sarta moal mangaruhan batur.
Kabéh compromises boga alesan alus. Leres?
Aya seueur alesan pikeun ngalih ka microservices. Kuring parantos ningali ieu dilakukeun pikeun kalenturan anu langkung ageung, pikeun skala tim, pikeun pagelaran, pikeun nyayogikeun kelestarian anu langkung saé. Tapi dina kanyataanana, urang geus invested dekade dina parabot jeung prakték pikeun ngembangkeun monoliths nu terus mekar. Kuring damel sareng profésional dina téknologi anu béda. Urang biasana ngobrol ngeunaan skala sabab ngajalankeun kana wates hiji titik database Postgres tunggal. Kalolobaan paguneman ngeunaan .
Tapi kuring sok resep diajar ngeunaan arsitektur na. Dina tahap naon transisi ka microservices aranjeunna dina? Éta pikaresepeun pikeun ningali langkung seueur insinyur anu nyarios yén aranjeunna resep kana aplikasi monolitik na. Loba jalma bakal nguntungkeun tina microservices, sarta kauntungan bakal outweigh nu nabrak dina jalur migrasi. Tapi sacara pribadi, punten pasihan abdi aplikasi monolithic kuring, tempat di pantai - sareng kuring bagja pisan.
sumber: www.habr.com