19-р сарын XNUMX-нд Москвад бичил үйлчилгээнд зориулагдсан анхны сэдэвчилсэн уулзалт HUG (Highload++ Хэрэглэгчийн бүлэг). “Микросервисийг ажиллуулах: Хэмжээ нь танд Кубернеттэй байсан ч гэсэн” илтгэл болж, бид Флантын микро үйлчилгээний архитектуртай төслүүдийг ажиллуулах арвин туршлагаас хуваалцсан. Юуны өмнө энэ аргыг одоогийн болон ирээдүйн төсөлдөө ашиглах талаар бодож байгаа бүх хөгжүүлэгчдэд хэрэгтэй болно.
Танилцуулж байна (50 минут, нийтлэлээс хавьгүй илүү мэдээлэлтэй), мөн үүнээс үндсэн ишлэлийг текст хэлбэрээр.
Жич: Энэ нийтлэлийн төгсгөлд видео болон танилцуулгыг авах боломжтой.
Танилцуулга
Ер нь сайн түүх нь эхлэл, гол үйл явдал, шийдэлтэй байдаг. Энэ тайлан нь оршил шиг, бас эмгэнэлтэй. Энэ нь микро үйлчилгээний талаар хөндлөнгийн хүний үзэл бодлыг хангадаг гэдгийг тэмдэглэх нь зүйтэй. мөлжлөг.
Би энэ графикаас эхэлье, зохиогч нь (2015 онд) Мартин Фаулер:
Энэ нь тодорхой үнэ цэнэд хүрсэн цул хэрэглээний тохиолдолд бүтээмж хэрхэн буурч эхэлдгийг харуулж байна. Бичил үйлчилгээнүүд нь тэдгээрийн анхны бүтээмж бага байдгаараа ялгаатай боловч нарийн төвөгтэй байдал нэмэгдэхийн хэрээр үр ашгийн бууралт нь тэдний хувьд тийм ч мэдэгдэхүйц биш юм.
Би Кубернетесийг ашиглах тохиолдолд энэ график дээр нэмэх болно:
Микро үйлчилгээтэй програм яагаад илүү дээр вэ? Учир нь ийм архитектур нь архитектурт ноцтой шаардлага тавьдаг бөгөөд энэ нь эргээд Кубернетесийн чадавхид бүрэн хамрагддаг. Нөгөөтэйгүүр, энэ функцүүдийн зарим нь цул чулуунд ашигтай байх болно, ялангуяа өнөөгийн ердийн цул нь яг цул биш учраас (дэлгэрэнгүйг тайланд дараа нь оруулах болно).
Таны харж байгаагаар эцсийн график (цул болон микро үйлчилгээний програмууд хоёулаа Kubernetes-ийн дэд бүтцэд байх үед) анхны графикаас тийм ч их ялгаатай биш юм. Дараа нь бид Kubernetes ашиглан ажилладаг програмуудын талаар ярих болно.
Ашигтай, хортой бичил үйлчилгээ
Мөн энд гол санаа байна:
Гэж юу вэ хэвийн байна микро үйлчилгээний архитектур? Энэ нь таны ажлын үр ашгийг дээшлүүлж, бодит үр өгөөжийг авчрах ёстой. Хэрэв бид график руу буцаж очвол дараах байдалтай байна.
Хэрэв та түүнийг дуудвал ашигтай, дараа нь графикийн нөгөө талд байх болно хортой бичил үйлчилгээ (ажилд саад учруулдаг):
"Гол санаа" руу буцах нь: Би өөрийн туршлагадаа итгэх ёстой юу? Энэ он гарснаас хойш харлаа 85 төсөл. Тэд бүгдээрээ микро үйлчилгээ биш байсан (тэдгээрийн гуравны нэгээс хагас нь ийм архитектуртай байсан), гэхдээ энэ нь маш их тоо хэвээр байна. Бид (Flant компани) аутсорсингуудын хувьд жижиг компаниудад (5 хөгжүүлэгчтэй) болон том компаниудад (~500 хөгжүүлэгчид) боловсруулсан олон төрлийн програмуудыг харж чаддаг. Нэмэлт давуу тал нь бид эдгээр аппликейшнууд олон жилийн турш амьд, хөгжиж байгааг хардаг явдал юм.
Яагаад микро үйлчилгээ гэж?
Бичил үйлчилгээний ашиг тусын тухай асуулт байна аль хэдийн дурдсан Мартин Фаулераас:
- модульчлэлийн тодорхой хил хязгаар;
- бие даасан байршуулалт;
- технологи сонгох эрх чөлөө.
Би програм хангамжийн архитекторууд болон хөгжүүлэгчидтэй маш их ярилцаж, яагаад бичил үйлчилгээ хэрэгтэй байгааг асуусан. Тэгээд би тэдний хүлээлтийг жагсаасан. Юу болсныг энд харуулав.
Хэрэв бид "мэдрэмж дэх" зарим цэгүүдийг тайлбарлавал:
- модулиудын тодорхой хил хязгаар: энд бидэнд аймшигтай цул байгаа бөгөөд одоо бүх зүйл "тавиур дээр" байгаа, дулаан, зөөлөн нь холилдохгүй Git-ийн агуулахад бүх зүйл эмх цэгцтэй байх болно;
- байршуулалтын бие даасан байдал: бид үйлчилгээгээ бие даан нэвтрүүлэх боломжтой бөгөөд ингэснээр хөгжүүлэлт илүү хурдан явагдана (шинэ функцуудыг зэрэгцүүлэн нийтлэх);
- хөгжлийн бие даасан байдал: бид энэ микро үйлчилгээг нэг баг/хөгжүүлэгчид, нөгөөг нь нөгөөд өгөх боломжтой бөгөөд үүний ачаар бид илүү хурдан хөгжиж чадна;
- боилүү найдвартай байдал: хэрэв хэсэгчилсэн эвдрэл гарвал (20 микро үйлчилгээний нэг нь унавал) зөвхөн нэг товчлуур ажиллахаа больж, систем бүхэлдээ ажиллах болно.
Ердийн (хортой) микро үйлчилгээний архитектур
Бодит байдал яагаад бидний хүлээж байгаа зүйл биш байгааг тайлбарлахын тулд би танилцуулах болно хамтын олон янзын төслийн туршлага дээр үндэслэсэн микро үйлчилгээний архитектурын дүр төрх.
Жишээ нь Amazon эсвэл ядаж OZON-той өрсөлдөх хийсвэр онлайн дэлгүүр байж болно. Түүний микро үйлчилгээний архитектур дараах байдалтай байна.
Олон шалтгааны улмаас эдгээр микро үйлчилгээг өөр өөр платформ дээр бичдэг:
Микро үйлчилгээ бүр бие даасан байх ёстой тул тэдгээрийн олонх нь мэдээллийн сан, кэштэй байх шаардлагатай. Эцсийн архитектур нь дараах байдалтай байна.
Үүний үр дагавар юу вэ?
Фаулерт ч бас ийм зүйл бий - бичил үйлчилгээ ашиглах "төлбөрийн" талаар:
Бидний хүлээлт биелсэн эсэхийг бид харах болно.
Модулиудын хил хязгаарыг арилгах...
Гэсэн хэдий ч Бид үнэндээ хэдэн микро үйлчилгээг засах шаардлагатай вэ?өөрчлөлтийг гаргах уу? Бид бүх зүйл хуваарилагдсан трекергүйгээр хэрхэн ажилладагийг олж мэдэх боломжтой юу (эцэст нь аливаа хүсэлтийг микро үйлчилгээний тал хувь нь боловсруулдаг)?
Загвар бий"", тэгээд энд тархсан бөөн шороо болж хувирав. Үүнийг батлахын тулд хүсэлтүүд хэрхэн явагддагийг ойролцоогоор харуулав:
Байршуулах бие даасан байдал...
Техникийн хувьд ийм үр дүнд хүрсэн: бид микро үйлчилгээ тус бүрийг тусад нь гаргах боломжтой. Гэхдээ практик дээр энэ нь үргэлж гарч ирдэг гэдгийг анхаарч үзэх хэрэгтэй олон микро үйлчилгээ, мөн бид анхааралдаа авах хэрэгтэй тэдгээрийг нэвтрүүлэх дараалал. Сайн арга замаар бид ерөнхийдөө хувилбарыг зөв дарааллаар гаргаж байгаа эсэхийг тусдаа хэлхээнд шалгах хэрэгтэй.
Технологийг сонгох эрх чөлөө...
Тэр бол. Эрх чөлөө нь ихэвчлэн хууль бус байдалтай хиллэдэг гэдгийг санаарай. Зөвхөн тэдэнтэй "тоглох" технологийг сонгохгүй байх нь энд маш чухал юм.
Хөгжлийн бие даасан байдал...
Програмыг бүхэлд нь (маш олон бүрэлдэхүүн хэсэгтэй) туршилтын гогцоо хэрхэн хийх вэ? Гэхдээ та үүнийг байнга шинэчилж байх хэрэгтэй. Энэ бүхэн ийм байдалд хүргэдэг туршилтын хэлхээний бодит тоо, бид үүнийг зарчмын хувьд агуулж болно, хамгийн бага болж хувирдаг.
Энэ бүгдийг орон нутагтаа байршуулбал ямар вэ?.. Хөгжүүлэгч нь ажлаа бие даан хийдэг ч "санамсаргүй байдлаар" хийдэг нь тодорхой болсон, учир нь тэр хэлхээг шалгахад чөлөөтэй болтол хүлээхээс өөр аргагүй болдог.
Тусдаа масштаб...
Тийм ээ, гэхдээ энэ нь ашигласан DBMS-ийн хүрээнд хязгаарлагдмал. Өгөгдсөн архитектурын жишээн дээр Кассандра асуудал гарахгүй, харин MySQL болон PostgreSQL-д асуудал гарах болно.
Боилүү найдвартай ...
Бодит байдал дээр нэг микро үйлчилгээний доголдол нь бүхэл системийн зөв ажиллагааг зөрчихөөс гадна шинэ асуудал гарч ирдэг. Микро үйлчилгээ бүрийг гэмтэлд тэсвэртэй болгох нь маш хэцүү байдаг. Микро үйлчилгээ нь өөр өөр технологи (memcache, Redis гэх мэт) ашигладаг тул хүн бүрийн хувьд та бүх зүйлийг сайтар бодож, хэрэгжүүлэх хэрэгтэй бөгөөд энэ нь мэдээжийн хэрэг боломжтой боловч асар их нөөц шаарддаг.
Ачааллыг хэмжих чадвар...
Энэ үнэхээр сайн байна.
Микро үйлчилгээний "хөнгөн байдал"...
Бид зөвхөн асар том биш сүлжээний нэмэлт зардал (DNS хүсэлтүүд олширч байна гэх мэт), гэхдээ бидний эхлүүлсэн олон дэд асуулгатай холбоотой өгөгдлийг хуулбарлах (дэлгүүрийн кэш), энэ нь ихээхэн хэмжээний хадгалахад хүргэсэн.
Бидний хүлээлтийг хангасны үр дүн энд байна:
Гэхдээ энэ нь бүгд биш юм!
Учир нь:
- Бидэнд мессежийн автобус хэрэгтэй байх магадлалтай.
- Хэрхэн зөв цагтаа тогтмол нөөцлөлт хийх вэ? Цор ганц жинхэнэ Үүний тулд замын хөдөлгөөнийг унтраах сонголт байна. Гэхдээ үүнийг үйлдвэрлэлд яаж хийх вэ?
- Хэрэв бид хэд хэдэн бүс нутгийг дэмжих тухай ярьж байгаа бол тус бүрт тогтвортой байдлыг зохион байгуулах нь маш их хөдөлмөр шаарддаг ажил юм.
- Төвлөрсөн өөрчлөлт хийх асуудал гарч ирдэг. Жишээлбэл, хэрэв бид PHP хувилбарыг шинэчлэх шаардлагатай бол бид репозитор болгонд үүрэг хариуцлага хүлээх шаардлагатай болно (мөн тэдгээрийн олон арван хувилбарууд байдаг).
- Үйл ажиллагааны нарийн төвөгтэй байдлын өсөлт нь гэнэтийн, экспоненциал юм.
Энэ бүхнийг яах вэ?
Цул хэрэглээнээс эхэл. Фоулерын туршлага Бараг бүх амжилттай микро үйлчилгээний програмууд нь цул хэлбэрээр эхэлсэн бөгөөд хэт том болж, дараа нь эвдэрсэн. Үүний зэрэгцээ, анхнаасаа микро үйлчилгээ хэлбэрээр бүтээгдсэн бараг бүх системүүд эрт орой хэзээ нэгэн цагт ноцтой асуудалтай тулгардаг.
Өөр нэг үнэ цэнэтэй санаа бол микро үйлчилгээний архитектур бүхий төслийг амжилттай хэрэгжүүлэхийн тулд та маш сайн мэддэг байх ёстой болон сэдвийн талбар, бичил үйлчилгээг хэрхэн хийх талаар. Мөн тухайн сэдвээр суралцах хамгийн сайн арга бол цул бүтээл хийх явдал юм.
Гэхдээ бид аль хэдийн ийм байдалд орсон бол яах вэ?
Аливаа асуудлыг шийдэх хамгийн эхний алхам бол үүнтэй санал нийлж, энэ нь асуудал гэдгийг ойлгох явдал юм, бид цаашид зовохыг хүсэхгүй байна.
Хэрэв хэт ургасан цул бол (бид нэмэлт нөөц худалдаж авах боломж байхгүй үед) бид үүнийг тасалвал энэ тохиолдолд эсрэгээр нь: хэт их микро үйлчилгээ нь туслахаа больсон, харин саад болох үед - илүүдлийг таслан томруулна!
Жишээлбэл, дээр дурдсан хамтын дүр төрхийн хувьд ...
Хамгийн эргэлзээтэй микро үйлчилгээнүүдээс салах:
Frontend үүсгэх үүрэгтэй бүх микро үйлчилгээг нэгтгэх:
... нэг (орчин үеийн болон таны бодож байгаагаар хэвийн) хэл/хүрээнд бичигдсэн нэг микро үйлчилгээнд:
Энэ нь нэг ORM (нэг DBMS) ба эхлээд хэд хэдэн програмтай байх болно:
... гэхдээ ерөнхийдөө та тэндээс илүү их зүйлийг шилжүүлж, дараах үр дүнг авах боломжтой.
Түүнчлэн, Кубернетес дээр бид энэ бүгдийг тусад нь ажиллуулдаг бөгөөд энэ нь бид ачааллыг хэмжиж, тусад нь масштаблах боломжтой гэсэн үг юм.
Нэгтгэн дүгнэхэд
Том зургийг хар. Ихэнхдээ микро үйлчилгээтэй холбоотой эдгээр бүх асуудал нь хэн нэгэн даалгавраа авсан боловч "микро үйлчилгээтэй тоглохыг" хүссэн учраас үүсдэг.
"Бичил үйлчилгээ" гэсэн үгэнд "бичил" хэсэг нь илүүдэлтэй байна.. Тэдгээр нь асар том цул чулуунаас жижиг учраас л "бичил" юм. Гэхдээ тэднийг жижиг зүйл гэж битгий бодоорой.
Эцэст нь бодохын тулд анхны график руугаа буцъя:
Үүн дээр бичсэн тэмдэглэл (баруун дээд) гэдэгтэй холбоотой Таны төслийг хэрэгжүүлэх багийн ур чадвар үргэлж чухал байдаг - тэд таны микро үйлчилгээ болон цул үйлчилгээг сонгоход чухал үүрэг гүйцэтгэнэ. Хэрэв баг хангалттай ур чадваргүй ч бичил үйлчилгээ хийж эхэлбэл энэ түүх үхэлд хүргэх нь дамжиггүй.
Видео болон слайд
Илтгэлийн видео (~50 минут; харамсалтай нь энэ нь илтгэлийн сэтгэл санааг ихээхэн тодорхойлсон зочдын олон тооны сэтгэл хөдлөлийг илэрхийлэхгүй, гэхдээ ийм байна):
Илтгэлийн танилцуулга:
PS
Манай блог дээрх бусад тайлангууд:
- «» (Дмитрий Столяров; 28 оны 2018-р сарын XNUMX-нд RootConf дээр);
- «» (Дмитрий Столяров; 7 оны 2017-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 6 оны 2017-р сарын XNUMX-нд RootConf дээр);
- «» (Дмитрий Столяров; 8 оны 2016-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 31 оны 2016-р сарын XNUMX-нд RootConf дээр).
Та дараах нийтлэлүүдийг сонирхож магадгүй юм.
- «";
- «";
- «".
Эх сурвалж: www.habr.com