Здраво, јас сум Stanislav Yablonskiy, водечки серверски програмер во Pixonic (MY.GAMES). Микро-услугите се пристап кон развојот на софтвер (првенствено развој на задната страна) каде што функционалноста е поделена на најмалите можни компоненти, од кои секоја работи независно. Микро-услугите се многу популарни во денешно време, но нивната употреба воведува значителна надмоќ во однос на мрежата, меморијата и процесорот. Секој повик се претвора во потреба за серијализација, испраќање и примање на податоци преку мрежата.Покрај тоа, повеќе не е можно да се користат класични бази на податоци трансакции, што доведува до или дистрибуирани трансакции или евентуална конзистентност. Дистрибуираните трансакции се бавни и скапи, додека евентуалната конзистентност значи дека резултатите од операциите може да не се појават веднаш, а податоците може да бидат привремено неконзистентни. Користењето на микро-услуги ги тера програмерите да пишуваат повеќе код во секоја индивидуална услуга поради тешкотиите при пристапот до веќе напишаната логика од други услуги.Понекогаш е тешко да се повторно користи постоечкиот код, или можеби дури и не знаете дека постои - бидејќи другите луѓе може да работат на поинаков проект. Микро-услуги на врвот Деби над главата Дебагирањето станува многу потешко со микро-услуги. Редовниот дебагирач е речиси бескорисен во такви услови, бидејќи не можете да ги дебагирате сите услуги одеднаш. Ова значи дека ви е потребна посебна средина во која работи не само услугата што се дебагира, туку и сите нејзини зависности (други услуги, бази на податоци, редови, итн.). HTTP на врвот HTTP протоколот има многу вградена функционалност. Поддржува разни рути, методи за пренос на параметри, кодови за одговори и е поддржана од многу услуги кои се подготвени за употреба (вклучувајќи прокси).Но, тоа не е лесна - тоа ги присилува сите услуги да имплементираат многу не толку ефикасен код за да анализираат и генерираат патеки, наслови и така натаму. Протобоф над главата Серијализација за мрежна комуникација и десеријализација при примање пораки се потребни. Кога користите protobuf за размена на пораки, треба да: создавање на објекти, да ги претвориме во заменски артерии, Исфрлете ги веднаш по употреба. Ова создава многу дополнителна работа за колекторот за ѓубре или менаџерот за динамичка меморија. Мрежата Overhead Преносот на податоци преку мрежата го зголемува времето на одговор на услугата. Тоа ја зголемува потрошувачката на меморија и CPU, дури и ако микро-услугите се извршуваат на истиот домаќин. Меморија над главата Испраќањето и примањето на пораки бара одржување на дополнителни структури на податоци, користење на одделни нишки и нивното синхронизирање. CPU над главата Се разбира, сето ова меѓу-процес и меѓу-контејнер комуникација бара компјутерски ресурси. База на податоци Overhead Нормалните трансакции се невозможни кога операциите опфаќаат повеќе микро-услуги. Дистрибуираните трансакции се многу побавни и бараат сложена – често рачна – координација. Дискови на мрежата Overhead Контејнерите за микро-услуги често се работат на дискови монтирани на мрежа, што ја зголемува латенцијата, го намалува перформансот (IOPS) и го прави непредвидлив. Проектот Borders Overhead Дизајнот и развојот на микро-услуги доведува до потешкотии во развојот и рефакторирањето на проектот. Не е лесно да се промени зоната на одговорност на една услуга. Не можете само да го преименувате или избришете нешто.Не можете едноставно да го преместите кодот од една услуга на друга. Ова обично бара: Многу време и напор, неколку верзии на API, и комплексни миграции пред функционалноста да може да се редистрибуира помеѓу услугите. Покрај тоа, ако сакате да ажурирате или да замените библиотека, ќе треба да го направите тоа во сите проекти, а не само еден. Инфраструктура на врвот Вие не можете само да „правите микро-услуги.“ Ќе ви треба инфраструктура – не, ИНФРАСТРУКТУРА: контејнери (секој од нив содржи копии од споделени библиотеки), Ѕвездите на Кубица, услуги во облак, редици (RabbitMQ, Кафка) алатки за синхронизација на конфигурацијата (Zookeeper, Etcd, Consul), и така натаму. Сето ова бара огромни ресурси и од машините и од луѓето. Независна надворешна депонија Поддршка на независни дислокации значи: Секоја услуга мора да биде распоредена одделно, Секој од нив мора да има свој ЦИ / ЦД цевка, И најтешкиот дел - API верзија. Секоја услуга ќе мора да поддржува повеќе верзии на API истовремено, а повикувачите ќе мора да ги следат овие верзии и да ги ажурираат своите повици на време. Дистрибуирана топка од муд Постои речиси 100% шанса дека нема да ги добиете границите на услугите од самиот почеток.Наместо чисти микро-услуги, ќе завршите со дистрибуирана топка кал - каде што функционалноста е слабо дистрибуирана, надворешните повици предизвикуваат цели синџири на внатрешни повици за услуги, а целата работа е ужасно бавна. Дали монолитот е навистина толку страшен? Модуларни монолити Модуларните монолити ви овозможуваат да го избегнете поголемиот дел од микро-услугите - додека сепак обезбедува одвојување кое може да се користи подоцна, ако е потребно. Овој пристап вклучува пишување на апликацијата (првенствено backend) како една услуга поделена на индивидуални модули со: јасно дефинирани граници, и Минимална меѓузависност Ова им овозможува да ги поделите на услуги ако скалирањето навистина го бара тоа. Чекај, можеш ли да го направиш тоа? Многу бенефиции што се припишуваат на архитектурата на микро-услуги може да се постигнат во еден монолит: Модуларноста може да се имплементира со јазични карактеристики: класи, име-простори, проекти и збирки; Многу бази на податоци – можно, ако навистина е потребно; Многу јазици – исто така е можно, на пример, комбинирање на C/C++/C#/Java со скриптинг јазици како JavaScript, Python или Erlang за развој на повисоко ниво; Interop – многу платформи поддржуваат повикување на C/C++ од Java, C#, Python, JavaScript или Erlang; Редици за пораки – само користете соодветна структура на податоци. И кога сакате да дебаг — еден тастатура, и целата апликација е на врвот на вашите прсти. Актерски рамки Актерските рамки ви овозможуваат да креирате микро-услуги – без микро-услуги. Целата логика е поделена на класи (актови) кои комуницираат само преку автобус за пораки (везови). Овие актери можат: постои во рамките на еден процес, или да бидат дистрибуирани низ повеќе процеси. На овој начин, ќе го добиете моделот за програмирање на микро-услуги, но поголемиот дел од инфраструктурата се ракува со самата рамка. Conclusion Заклучок Архитектурата треба да се избере врз основа на: барања на проектот, достапни ресурси, И тимски експертиза. Микро-услугите не се сребрена топка. Тие се корисни за големи проекти и тимови – но монолитот не е застарен и не е технички долг по дефолт. Она што е најважно е балансот помеѓу флексибилност и комплексност, скалабилност и одржливост - така што системот што го градите е ефикасен и одржлив.
