Микроуслуги: Големината е важна, дури и ако имате Kubernetes

19 септември во Москва се одржа првиот тематски состанок HUG (Highload++ User Group), кој беше посветен на микросервисите. Имаше презентација „Оперативни микроуслуги: Големината е важна, дури и ако имаш Kubernetes“, во која го споделивме големото искуство на Флант во работењето проекти со микросервис архитектура. Пред сè, ќе биде корисно за сите програмери кои размислуваат да го користат овој пристап во нивниот сегашен или иден проект.

Воведување видео од извештајот (50 минути, многу поинформативни од статијата), како и главниот извадок од него во текстуална форма.

Напомена: Видеото и презентацијата се исто така достапни на крајот од овој пост.

Вовед

Обично добрата приказна има почеток, главен заплет и резолуција. Овој извештај е повеќе како увертира, а притоа и трагичен. Исто така, важно е да се напомене дека обезбедува поглед на надворешниот поглед на микросервисите. експлоатација.

Ќе започнам со овој график, чиј автор (во 2015 година) беше Мартин Фаулер:

Тоа покажува како, во случај на монолитна апликација која достигнува одредена вредност, продуктивноста почнува да опаѓа. Микроуслугите се различни по тоа што почетната продуктивност кај нив е помала, но како што се зголемува сложеноста, деградацијата на ефикасноста не е толку забележлива за нив.

Ќе додадам на овој график за случајот со користење на Kubernetes:

Зошто апликацијата со микросервис е подобра? Затоа што таквата архитектура поставува сериозни барања за архитектурата, кои пак се совршено покриени со можностите на Kubernetes. Од друга страна, дел од оваа функционалност ќе биде корисна за монолит, особено затоа што типичниот монолит денес не е баш монолит (деталите ќе бидат подоцна во извештајот).

Како што можете да видите, конечниот график (кога и монолитни и микросервисни апликации се во инфраструктурата со Kubernetes) не се разликува многу од оригиналниот. Следно ќе зборуваме за апликации што се користат со употреба на Kubernetes.

Корисни и штетни микроуслуги

И еве ја главната идеја:

што е нормално микросервис архитектура? Тоа треба да ви донесе вистински придобивки, зголемувајќи ја вашата работна ефикасност. Ако се вратиме на графиконот, еве го:

Ако и се јавиш корисни, тогаш од другата страна на графикот ќе има штетни микросервиси (се меша во работата):

Враќање на „главната идеја“: дали воопшто треба да му верувам на моето искуство? Од почетокот на оваа година гледам 85 проекти. Не беа сите микроуслуги (околу една третина до половина од нив имаа таква архитектура), но ова е сепак голем број. Ние (Flant company) како аутсорсери успеваме да видиме широк спектар на апликации развиени и во мали компании (со 5 програмери) и во големи (~500 програмери). Дополнителна придобивка е што ги гледаме овие апликации во живо и се развиваат со текот на годините.

Зошто микросервисите?

На прашањето за придобивките од микросервисите постои многу конкретен одговор од веќе споменатиот Мартин Фаулер:

1. јасни граници на модуларност;
2. независно распоредување;
3. слобода на избор на технологии.

Зборував многу со софтверски архитекти и развивачи и прашав зошто им требаат микросервиси. И ја направив мојата листа на нивните очекувања. Еве што се случи:

Ако опишеме некои од точките „во сензации“, тогаш:

• јасни граници на модули: овде имаме ужасен монолит, а сега сè ќе биде уредно распоредено во складиштата на Git, во кои сè е „на полиците“, топлото и мекото не се мешаат;
• независност на распоредувањето: ќе можеме самостојно да воведуваме услуги, така што развојот ќе оди побрзо (паралелно објавување нови функции);
• развојна независност: можеме да ја дадеме оваа микроуслуга на еден тим/програмер, а таа на друг, благодарение на што можеме да се развиваме побрзо;
• бопоголема доверливост: ако дојде до делумна деградација (една микроуслуга од 20 паѓа), тогаш само едно копче ќе престане да работи, а системот како целина ќе продолжи да функционира.

Типична (штетна) микросервис архитектура

За да објаснам зошто реалноста не е она што ја очекуваме, ќе презентирам колективен слика на архитектура на микросервис базирана на искуство од многу различни проекти.

Пример би била апстрактна онлајн продавница која ќе се натпреварува со Амазон или барем ОЗОН. Нејзината микросервисна архитектура изгледа вака:

Поради комбинација на причини, овие микроуслуги се напишани на различни платформи:

Бидејќи секој микросервис мора да има автономија, на многу од нив им е потребна сопствена база на податоци и кеш. Конечната архитектура е како што следува:

Кои се нејзините последици?

Фаулер исто така го има ова има статија — за „плаќањето“ за користење на микроуслуги:

И ќе видиме дали нашите очекувања се остварени.

Јасни граници на модули...

Но колку микроуслуги всушност треба да поправиме?да се воведе промената? Можеме ли воопшто да откриеме како функционира сè без дистрибуиран трасер (на крајот на краиштата, секое барање го обработуваат половина од микросервисите)?

Има шема“голема грутка нечистотија“, и тука се покажа дека е дистрибуирана грутка нечистотија. За да го потврдите ова, еве приближна илустрација за тоа како одат барањата:

Независноста на распоредувањето ...

Технички, тоа е постигнато: можеме да ја промовираме секоја микросервис посебно. Но, во пракса треба да се земе предвид дека секогаш се исфрла многу микроуслуги, и треба да го земеме предвид редоследот на нивното пуштање. На добар начин, генерално треба да тестираме во посебно коло дали го пуштаме ослободувањето по правилен редослед.

Слобода за избор на технологија...

Таа е. Само запомнете дека слободата често се граничи со беззаконие. Овде е многу важно да не избирате технологии само за да „играте“ со нив.

Независноста на развојот...

Како да направите тест циклус за целата апликација (со толку многу компоненти)? Но, сепак треба да го одржувате ажуриран. Сето ова води до фактот дека вистинскиот број на тест кола, што во принцип можеме да го содржиме, излегува дека е минимално.

Како да се распореди сето ова локално?... Излегува дека често развивачот ја врши својата работа самостојно, но „по случаен избор“, бидејќи е принуден да чека додека колото не се ослободи за тестирање.

Одделно скалирање...

Да, но тоа е ограничено во областа на користениот DBMS. Во дадениот пример за архитектура, Касандра нема да има проблеми, но ќе има MySQL и PostgreSQL.

Бопоголема доверливост...

Не само што неуспехот на еден микросервис во реалноста често го нарушува правилното функционирање на целиот систем, туку има и нов проблем: да се направи секој микросервис толерантен за грешки е многу тешко. Бидејќи микросервисите користат различни технологии (memcache, Redis, итн.), за секоја треба да размислите низ сè и да го имплементирате, што, се разбира, е можно, но бара огромни ресурси.

Мерливост на оптоварување...

Ова е навистина добро.

„Лесноста“ на микросервисите...

Ние не само што имаме огромни надземни мрежни (барањата за DNS се множат итн.), но и поради многуте подпрашања што ги започнавме реплицираат податоци (кешови за складирање), што доведе до значителна количина на складирање.

И еве го резултатот од исполнувањето на нашите очекувања:

Но, тоа не е се!

Бидејќи:

• Најверојатно ќе ни треба автобус за пораки.
• Како да направите доследна резервна копија во вистинскиот момент на време? Единственото реално опцијата е да го исклучите сообраќајот за ова. Но, како да го направите ова во производството?
• Ако зборуваме за поддршка на неколку региони, тогаш организирањето одржливост во секој од нив е многу трудоинтензивна задача.
• Се појавува проблемот со правење централизирани промени. На пример, ако треба да ја ажурираме верзијата на PHP, ќе треба да се посветиме на секое складиште (а има десетици од нив).
• Растот на оперативната сложеност е ненамерен, експоненцијален.

Што да се прави со сето ова?

Започнете со монолитна апликација. Искуството на Фаулер вели дека скоро сите успешни апликации за микросервис започнале како монолит кој станал преголем и потоа бил скршен. Во исто време, скоро сите системи изградени како микросервис од самиот почеток порано или подоцна доживеаја сериозни проблеми.

Друга вредна мисла е дека за проект со микросервис архитектура да биде успешен, мора да знаете многу добро и предметна област, и како да се направат микроуслуги. И најдобриот начин да се научи предметната област е да се направи монолит.

Но, што ако веќе сме во оваа ситуација?

Првиот чекор кон решавање на секој проблем е да се согласиме со него и да разбереме дека тоа е проблем, дека не сакаме повеќе да страдаме.

Ако, во случај на обраснат монолит (кога немаме можност да купиме дополнителни ресурси за него), го пресечеме, тогаш во овој случај излегува спротивната приказна: кога прекумерните микроуслуги веќе не помагаат, туку го попречуваат - отсечете го вишокот и зголемете!

На пример, за колективната слика дискутирана погоре...

Ослободете се од најсомнителните микроуслуги:

Комбинирајте ги сите микросервиси одговорни за генерирање на предниот дел:

... во еден микросервис, напишан на еден (модерен и нормален, како што и самите мислите) јазик/рамка:

Ќе има еден ORM (еден DBMS) и прво неколку апликации:

... но генерално можете да префрлите многу повеќе таму, добивајќи го следниот резултат:

Покрај тоа, во Kubernetes го извршуваме сето ова во посебни примероци, што значи дека сè уште можеме да го измериме оптоварувањето и да ги скалираме одделно.

За да резимираме

Погледнете ја поголемата слика. Многу често, сите овие проблеми со микросервисите се јавуваат затоа што некој си ја презел задачата, но сакал да „игра со микросервисите“.

Во зборот „микроуслуги“ „микро“ делот е вишок.. Тие се „микро“ само затоа што се помали од огромен монолит. Но, немојте да ги сметате за нешто мало.

И за последно размислување, да се вратиме на оригиналната табела:

Напишана белешка на неа (горе десно) се сведува на фактот дека вештините на тимот што го прави вашиот проект се секогаш примарни — тие ќе играат клучна улога во вашиот избор помеѓу микроуслуги и монолит. Ако тимот нема доволно вештини, но почне да прави микросервиси, приказната дефинитивно ќе биде фатална.

Видеа и слајдови

Видео од говорот (~50 минути; за жал, не ги пренесува многубројните емоции на посетителите, кои во голема мера го определија расположението на репортажата, но вака е):

Презентација на извештајот:

PS

Други извештаи на нашиот блог:

• «Мониторинг и Kubernetes» (Дмитриј Столјаров; 28 мај 2018 година на RootConf);
• «CI/CD Најдобри практики со Kubernetes и GitLab» (Дмитриј Столјаров; 7 ноември 2017 година на HighLoad++);
• «Нашето искуство со Kubernetes во мали проекти» (Дмитриј Столјаров; 6 јуни 2017 година на RootConf);
• «Брзо и практично создаваме Docker слики за CI/CD со помош на дап» (Дмитриј Столјаров; 8 ноември 2016 година на HighLoad++);
• «Практики за континуирана испорака со Docker» (Дмитриј Столјаров; 31 мај 2016 година на RootConf).

Може да ве интересираат и следните публикации:

• «Смртта на лудилото на микросервис во 2018 година";
• «7 најдобри практики за користење контејнери според Google";
• «Статистика од The ​​New Stack за предизвиците при имплементацијата на Kubernetes".

Извор: www.habr.com