Habari, habr. Kujiandikisha kwa mtiririko mpya wa kozi kumefunguliwa sasa hivi katika OTUS . Katika usiku wa mwanzo wa kozi, nataka kushiriki nawe makala yangu ya asili.
Utangulizi
Uchaguzi wa mtindo wa usanifu ni mojawapo ya maamuzi ya msingi ya kiufundi wakati wa kujenga mfumo wa habari. Katika mfululizo huu wa makala, napendekeza kuchambua mitindo maarufu ya usanifu kwa ajili ya maombi ya ujenzi na kujibu swali la ni wakati gani mtindo wa usanifu unapendekezwa zaidi. Katika mchakato wa uwasilishaji, nitajaribu kuteka mlolongo wa mantiki unaoelezea maendeleo ya mitindo ya usanifu kutoka kwa monoliths hadi microservices.
kidogo ya historia
Ukijaribu kuuliza watengenezaji: "Kwa nini tunahitaji microservices?", Utapata majibu mbalimbali. Utasikia kwamba huduma ndogo huboresha scalability, kufanya msimbo rahisi kuelewa, kuboresha uvumilivu wa makosa, na wakati mwingine utasikia kwamba wao kuruhusu wewe "kusafisha code yako." Wacha tuangalie historia ili kuelewa madhumuni ya kuibuka kwa huduma ndogo.
Kwa kifupi, huduma ndogo katika uelewa wetu wa sasa ziliibuka kama ifuatavyo: mnamo 2011, James Lewis, akichambua kazi ya kampuni mbali mbali, alielekeza umakini kwenye kuibuka kwa muundo mpya wa "programu ndogo", ambayo iliboresha SOA katika suala la kuharakisha upelekaji wa programu. huduma. Baadaye, mnamo 2012, kwenye mkutano wa kilele wa usanifu, muundo huo uliitwa jina la huduma ndogo. Kwa hivyo, lengo la awali la kuanzisha huduma ndogo lilikuwa kuboresha sifa mbaya muda wa soko.
Huduma ndogo ndogo zilikuwa kwenye wimbi la hype mnamo 2015. Kulingana na tafiti zingine, hakuna mkutano mmoja uliokamilika bila ripoti juu ya mada ya huduma ndogo. Zaidi ya hayo, mikutano mingine ilitolewa kwa huduma ndogo tu. Siku hizi, miradi mingi huanza kutumia mtindo huu wa usanifu, na ikiwa mradi una tani za msimbo wa urithi, basi uhamiaji kwa huduma ndogo labda unafanywa kikamilifu.
Licha ya yote hapo juu, idadi ndogo ya watengenezaji bado wanaweza kufafanua dhana ya "microservice". Lakini tutazungumza juu ya hii baadaye kidogo ...
Monolith
Mtindo wa usanifu unaotofautisha microservices ni monolith (au yote kwa moja). Pengine haina maana ya kusema nini monolith ni, kwa hiyo nitaorodhesha mara moja hasara za mtindo huu wa usanifu, ambao ulianzisha maendeleo zaidi ya mitindo ya usanifu: ukubwa, uunganisho, kupelekwa, scalability, kuegemea na rigidity. Hapo chini ninapendekeza kuangalia kila moja ya mapungufu tofauti.
Ukubwa
Monolith ni kubwa sana. Na kwa kawaida huwasiliana na hifadhidata kubwa sana. Programu inakuwa kubwa sana kwa msanidi programu mmoja kuelewa hata kidogo. Ni wale tu ambao wametumia muda mwingi kufanya kazi kwenye kanuni hii wanaweza kufanya kazi vizuri na monolith, wakati waanzia watatumia muda mwingi kujaribu kutambua monolith na hakuna uhakika kwamba wataihesabu. Kawaida, wakati wa kufanya kazi na monolith, daima kuna "masharti" ya juu ambaye anajua monolith zaidi au chini vizuri na hupiga mikono ya watengenezaji wengine wapya ndani ya mwaka na nusu. Kwa kawaida, mwandamizi huyo wa masharti ni hatua moja ya kushindwa, na kuondoka kwake kunaweza kusababisha kifo cha monolith.
Kuunganishwa
Monolith ni "mpira mkubwa wa matope", mabadiliko ambayo yanaweza kusababisha matokeo yasiyotabirika. Kwa kufanya mabadiliko katika sehemu moja, unaweza kuharibu monolith katika sehemu nyingine (sawa "umepiga sikio lako, *@ ikaanguka"). Hii ni kutokana na ukweli kwamba vipengele katika monolith vina ngumu sana na, muhimu zaidi, mahusiano yasiyo ya wazi.
Kupelekwa
Kupeleka monolith, kutokana na mahusiano magumu kati ya vipengele vyake, ni mchakato mrefu na ibada yake mwenyewe. Tamaduni kama hiyo kwa kawaida haijasawazishwa kabisa na hupitishwa βkwa mdomo.β
Scalability
Moduli za monolith zinaweza kuwa na mahitaji ya rasilimali zinazokinzana, zinazohitaji maelewano kufanywa katika suala la maunzi. Fikiria kuwa una monolith inayojumuisha huduma A na B. Huduma A inadai kwa ukubwa wa gari ngumu, na huduma B inadai kwenye RAM. Katika kesi hii, ama mashine ambayo monolith imewekwa lazima isaidie mahitaji ya huduma zote mbili, au utalazimika kuzima kwa mikono moja ya huduma.
Mfano mwingine (zaidi ya kawaida): huduma A ni maarufu zaidi kuliko huduma B, kwa hivyo unataka kuwe na huduma 100 A, na huduma 10 B. Tena, chaguzi mbili: ama tutapeleka monoliths 100 kamili, au kwa zingine basi. huduma B italazimika kuzimwa kwa mikono.
Kuegemea
Kwa kuwa huduma zote ziko pamoja, ikiwa monolith huanguka, basi huduma zote huanguka mara moja. Kwa kweli, hii inaweza kuwa mbaya sana, angalau hakutakuwa na kushindwa kwa sehemu katika mfumo uliosambazwa, lakini kwa upande mwingine, kutokana na mdudu katika utendaji unaotumiwa na 0.001% ya watumiaji, unaweza kupoteza watumiaji wote. ya mfumo wako.
Inertia
Kutokana na ukubwa wa monolith, ni vigumu kubadili teknolojia mpya. Kwa hivyo, kubakiza mwandamizi huyo ni kazi tofauti. Rundo la teknolojia lililochaguliwa mwanzoni mwa mradi linaweza kuwa kizuizi kinachozuia ukuzaji wa bidhaa.
Hitimisho
Wakati ujao tutazungumzia jinsi watu wamejaribu kutatua matatizo haya kwa kuhamia vipengele na SOA.
Soma zaidi:
Chanzo: mapenzi.com