Septemba 19 huko Moscow mkutano wa kwanza wa mada HUG (Highload++ User Group), ambao ulijitolea kwa huduma ndogo. Kulikuwa na wasilisho "Huduma Ndogo za Uendeshaji: Mambo ya Ukubwa, Hata Ikiwa Una Kubernetes," ambapo tulishiriki uzoefu mkubwa wa Flant katika miradi ya uendeshaji na usanifu wa huduma ndogo. Kwanza kabisa, itakuwa muhimu kwa watengenezaji wote ambao wanafikiria kutumia mbinu hii katika mradi wao wa sasa au wa baadaye.
Kuanzisha (Dakika 50, taarifa zaidi kuliko makala), pamoja na dondoo kuu kutoka kwa fomu ya maandishi.
NB: Video na uwasilishaji pia zinapatikana mwishoni mwa chapisho hili.
Utangulizi
Kawaida hadithi nzuri huwa na mwanzo, njama kuu na azimio. Ripoti hii ni kama utangulizi, na ya kusikitisha kwa hilo. Pia ni muhimu kutambua kwamba hutoa mtazamo wa nje wa microservices. Uendeshaji.
Nitaanza na grafu hii, ambayo mwandishi wake (mnamo 2015) Martin Fowler:
Inaonyesha jinsi, katika kesi ya maombi ya monolithic ambayo hufikia thamani fulani, tija huanza kupungua. Microservices ni tofauti kwa kuwa tija ya awali nao ni ya chini, lakini kadiri ugumu unavyoongezeka, uharibifu wa ufanisi hauonekani sana kwao.
Nitaongeza kwenye grafu hii kwa kesi ya kutumia Kubernetes:
Kwa nini programu iliyo na huduma ndogo ni bora? Kwa sababu usanifu kama huo unaweka mbele mahitaji makubwa ya usanifu, ambayo kwa upande wake yanafunikwa kikamilifu na uwezo wa Kubernetes. Kwa upande mwingine, baadhi ya utendaji huu utakuwa na manufaa kwa monolith, hasa kwa sababu monolith ya kawaida leo sio monolith hasa (maelezo yatakuwa baadaye katika ripoti).
Kama unaweza kuona, grafu ya mwisho (wakati programu zote mbili za monolithic na microservice ziko kwenye miundombinu na Kubernetes) sio tofauti sana na ile ya asili. Ifuatayo tutazungumza juu ya programu zinazoendeshwa kwa kutumia Kubernetes.
Huduma ndogo ndogo zinazofaa na zenye madhara
Na hapa kuna wazo kuu:
Ni nini kawaida usanifu wa huduma ndogo? Inapaswa kukuletea manufaa halisi, kuongeza ufanisi wako wa kazi. Ikiwa tunarudi kwenye grafu, hii hapa:
Ukimwita muhimu, basi upande wa pili wa grafu kutakuwa na madhara microservices (huingilia kazi):
Kurudi kwa "wazo kuu": je, niamini uzoefu wangu hata kidogo? Tangu mwanzo wa mwaka huu nimeangalia miradi 85. Sio wote walikuwa microservices (karibu theluthi hadi nusu yao walikuwa na usanifu huo), lakini hii bado ni idadi kubwa. Sisi (kampuni ya Flant) kama wauzaji wa nje tunaweza kuona aina mbalimbali za maombi yaliyotengenezwa katika makampuni madogo (yenye watengenezaji 5) na katika makubwa (~ watengenezaji 500). Faida ya ziada ni kwamba tunaona maombi haya yakiishi na kubadilika kwa miaka mingi.
Kwa nini huduma ndogo?
Kwa swali kuhusu faida za microservices kuna kutoka kwa Martin Fowler aliyetajwa tayari:
- mipaka ya wazi ya modularity;
- kupelekwa kwa kujitegemea;
- uhuru wa kuchagua teknolojia.
Nimezungumza sana na wasanifu wa programu na watengenezaji na kuuliza kwa nini wanahitaji huduma ndogo. Na nilifanya orodha yangu ya matarajio yao. Hiki ndicho kilichotokea:
Ikiwa tutaelezea baadhi ya vidokezo "katika hisia," basi:
- mipaka ya wazi ya moduli: hapa tuna monolith ya kutisha, na sasa kila kitu kitapangwa vizuri katika hazina za Git, ambazo kila kitu kiko "kwenye rafu", joto na laini hazichanganyiki;
- uhuru wa kupeleka: tutaweza kusambaza huduma kwa kujitegemea ili maendeleo yaende haraka (chapisha vipengele vipya sambamba);
- uhuru wa maendeleo: tunaweza kutoa huduma ndogo hii kwa timu/msanidi programu mmoja, na ile kwa nyingine, shukrani ambayo tunaweza kukuza haraka;
- Π±ΠΎkuegemea zaidi: ikiwa uharibifu wa sehemu hutokea (microservice moja kati ya 20 huanguka), basi kifungo kimoja tu kitaacha kufanya kazi, na mfumo kwa ujumla utaendelea kufanya kazi.
Usanifu wa kawaida (madhara) wa huduma ndogo
Kuelezea kwa nini ukweli sio kile tunachotarajia, nitawasilisha pamoja picha ya usanifu wa huduma ndogo kulingana na uzoefu kutoka kwa miradi mingi tofauti.
Mfano unaweza kuwa duka dhahania la mtandaoni ambalo litashindana na Amazon au angalau OZON. Usanifu wake wa huduma ndogo unaonekana kama hii:
Kwa mchanganyiko wa sababu, huduma hizi ndogo zimeandikwa kwenye majukwaa tofauti:
Kwa kuwa kila huduma ndogo lazima iwe na uhuru, wengi wao wanahitaji hifadhidata yao wenyewe na kashe. Usanifu wa mwisho ni kama ifuatavyo.
Matokeo yake ni yapi?
Fowler ana hii pia - kuhusu "malipo" kwa kutumia huduma ndogo:
Na tutaona ikiwa matarajio yetu yalitimizwa.
Futa mipaka ya moduli...
Lakini ni huduma ndogo ngapi tunahitaji kurekebisha?ili kuleta mabadiliko? Tunaweza hata kujua jinsi kila kitu kinavyofanya kazi bila tracer iliyosambazwa (baada ya yote, ombi lolote linashughulikiwa na nusu ya huduma ndogo)?
Kuna mfano"", na hapa ikawa donge la uchafu lililosambazwa. Ili kuthibitisha hili, hapa kuna takriban kielelezo cha jinsi maombi yanavyoenda:
Uhuru wa usambazaji...
Kitaalam, imepatikana: tunaweza kusambaza kila huduma ndogo tofauti. Lakini katika mazoezi unahitaji kuzingatia kwamba daima hutoka huduma ndogo ndogo, na tunahitaji kuzingatia utaratibu wa usambazaji wao. Kwa njia nzuri, kwa ujumla tunahitaji kujaribu katika mzunguko tofauti kama tunasambaza toleo kwa mpangilio sahihi.
Uhuru wa kuchagua teknolojia...
Yeye ni. Kumbuka tu kwamba uhuru mara nyingi unapakana na uasi. Ni muhimu sana hapa sio kuchagua teknolojia tu "kucheza" nao.
Uhuru wa maendeleo...
Jinsi ya kutengeneza kitanzi cha majaribio kwa programu nzima (iliyo na vifaa vingi)? Lakini bado unahitaji kuiweka hadi sasa. Yote hii inaongoza kwa ukweli kwamba idadi halisi ya mizunguko ya mtihani, ambayo kimsingi tunaweza kuwa nayo, inageuka kuwa ndogo.
Vipi kuhusu kupeleka haya yote ndani ya nchi? .. Inatokea kwamba mara nyingi msanidi hufanya kazi yake kwa kujitegemea, lakini "kwa random", kwa sababu analazimika kusubiri mpaka mzunguko uwe huru kwa ajili ya kupima.
Upimaji tofauti...
Ndio, lakini ni mdogo katika eneo la DBMS inayotumiwa. Katika mfano uliopewa wa usanifu, Cassandra haitakuwa na shida, lakini MySQL na PostgreSQL zitakuwa.
ΠΠΎkuegemea zaidi...
Sio tu kutofaulu kwa huduma ndogo katika hali halisi mara nyingi huvunja utendaji sahihi wa mfumo mzima, lakini pia kuna shida mpya: kufanya kila microservice kustahimili makosa ni ngumu sana. Kwa sababu microservices hutumia teknolojia tofauti (memcache, Redis, nk), kwa kila mmoja unahitaji kufikiri kupitia kila kitu na kutekeleza, ambayo, bila shaka, inawezekana, lakini inahitaji rasilimali kubwa.
Upimaji wa mzigo...
Hii ni nzuri sana.
"Wepesi" wa huduma ndogo ...
Hatuna kubwa tu mtandao juu (maombi ya DNS yanazidishwa, n.k.), lakini pia kutokana na hoja nyingi tulizoanzisha kuiga data (cache za duka), ambayo imesababisha kiasi kikubwa cha hifadhi.
Na haya ndio matokeo ya kukidhi matarajio yetu:
Lakini si hivyo tu!
Kwa sababu:
- Uwezekano mkubwa zaidi tutahitaji basi ya ujumbe.
- Jinsi ya kufanya nakala rudufu kwa wakati unaofaa kwa wakati? Wa pekee halisi chaguo ni kuzima trafiki kwa hili. Lakini jinsi ya kufanya hivyo katika uzalishaji?
- Ikiwa tunazungumza juu ya kusaidia mikoa kadhaa, basi kuandaa uendelevu katika kila moja yao ni kazi kubwa sana.
- Tatizo la kufanya mabadiliko ya kati hutokea. Kwa mfano, ikiwa tunahitaji kusasisha toleo la PHP, tutahitaji kujitolea kwa kila hazina (na kuna kadhaa).
- Ukuaji wa utata wa kiutendaji ni, mbali na, wa kielelezo.
Nini cha kufanya na haya yote?
Anza na maombi ya monolithic. Uzoefu wa Fowler kwamba karibu programu zote za huduma ndogo zilizofaulu zilianza kama monolith ambayo ikawa kubwa sana na ikavunjwa. Wakati huo huo, karibu mifumo yote iliyojengwa kama microservices tangu mwanzo mapema au baadaye ilipata matatizo makubwa.
Wazo lingine la thamani ni kwamba ili mradi ulio na usanifu wa huduma ndogo ufanikiwe, lazima ujue vizuri na eneo la somo, na jinsi ya kutengeneza huduma ndogo ndogo. Na njia bora ya kujifunza eneo la somo ni kufanya monolith.
Lakini vipi ikiwa tayari tuko katika hali hii?
Hatua ya kwanza ya kutatua tatizo lolote ni kukubaliana nalo na kuelewa kwamba ni tatizo, ambalo hatutaki kuteseka tena.
Ikiwa, katika kesi ya monolith iliyokua (wakati tumekosa fursa ya kununua rasilimali za ziada), tunaikata, basi katika kesi hii hadithi tofauti inatokea: wakati huduma ndogo ndogo hazisaidii tena, lakini zinazuia - kata ziada na kupanua!
Kwa mfano, kwa picha ya pamoja iliyojadiliwa hapo juu ...
Ondoa huduma ndogo zinazotiliwa shaka zaidi:
Changanya huduma ndogo ndogo zote zinazohusika na uzalishaji wa mbele:
... kwenye huduma ndogo ndogo, iliyoandikwa kwa moja (ya kisasa na ya kawaida, kama unavyofikiria mwenyewe) lugha/mfumo:
Itakuwa na ORM moja (DBMS moja) na kwanza maombi kadhaa:
... lakini kwa ujumla unaweza kuhamisha mengi zaidi huko, kupata matokeo yafuatayo:
Zaidi ya hayo, katika Kubernetes tunaendesha haya yote katika matukio tofauti, ambayo ina maana kwamba bado tunaweza kupima mzigo na kupima tofauti.
Kufupisha
Angalia picha kubwa zaidi. Mara nyingi, shida hizi zote na huduma ndogo huibuka kwa sababu mtu alichukua kazi yake, lakini alitaka "kucheza na huduma ndogo".
Katika neno "microservices" sehemu ya "micro" haina maana.. Wao ni "micro" tu kwa sababu ni ndogo kuliko monolith kubwa. Lakini usiwafikirie kama kitu kidogo.
Na kwa wazo la mwisho, wacha turudi kwenye chati asili:
Barua iliyoandikwa juu yake (juu kulia) inajitokeza kwa ukweli kwamba ustadi wa timu inayofanya mradi wako ni wa msingi kila wakati - watachukua jukumu muhimu katika chaguo lako kati ya huduma ndogo na monolith. Ikiwa timu haina ustadi wa kutosha, lakini inaanza kutengeneza huduma ndogo, hadithi hakika itakuwa mbaya.
Video na slaidi
Video kutoka kwa hotuba (~ dakika 50; kwa bahati mbaya, haitoi hisia nyingi za wageni, ambazo ziliamua kwa kiasi kikubwa hali ya ripoti, lakini ndivyo ilivyo):
Uwasilishaji wa ripoti:
PS
Ripoti zingine kwenye blogi yetu:
- «» (Dmitry Stolyarov; Mei 28, 2018 katika RootConf);
- «» (Dmitry Stolyarov; Novemba 7, 2017 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 katika RootConf);
- «» (Dmitry Stolyarov; Novemba 8, 2016 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Mei 31, 2016 katika RootConf).
Unaweza pia kupendezwa na machapisho yafuatayo:
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com