Какво представляват микроуслугите? Вашата следваща софтуерна архитектура

Почти всяка компютърна система изпълнява множество задачи, използвайки споделени ресурси, и един от въпросите на компютърното програмиране е доколко битовете на кода, които изпълняват тези задачи, трябва да бъдат свързани помежду си. Все по-популярен отговор е концепцията за микроуслуга - малка, дискретна част от функционалността, която взаимодейства с други микроуслуги, за да създаде по-голяма система.

Въпреки че основната идея за наличието на такива дискретни компоненти не е нова, начинът на внедряване на микроуслугите ги прави естествена основа както за съвременните облачни приложения. Микроуслугите също се съчетават с философията на devops, която насърчава бързо и непрекъснато внедряване на нова функционалност.

Какво представляват микроуслугите?

„Микро“ в микрослужбите предполага, че това са малки приложения. Това понякога е вярно, но по-добрият начин да мислим за тях е, че те трябва да бъдат толкова големи, колкото е необходимо, за да направят едно конкретно нещо или да решат определен проблем. Този проблем трябва да бъде концептуален, а не технически. Както казва Microsoft, „Микроуслугите трябва да бъдат проектирани около бизнес възможности, а не хоризонтални слоеве като достъп до данни или съобщения“. Те комуникират с други микроуслуги и външни потребители чрез относително стабилни API, за да създадат по-голямо приложение.

По този начин вътрешната функционалност на отделна микрослужба може да бъде променена или радикално надградена, без да се засяга останалата част от системата. Това от своя страна е свързано с начина, по който магазините на devops се стремят да работят: Ако специфичните функции на по-голямо приложение са разделени на отделни, независимо работещи парчета код, е по-лесно да живеете в мантрата на devops на CI / CD (непрекъсната интеграция и непрекъсната доставка) . Също така, добре дефинираните приложни програмни интерфейси (API) правят микросервисите лесни за автоматично тестване.

Архитектура на микроуслуги срещу монолитна архитектура

Често ще чувате за микроуслуги, за които се говори по отношение на „архитектура на микроуслуги Тази фраза включва не само самите микроуслуги, но компоненти за управление и откриване на услуги, както и API шлюз, който обработва комуникацията между микроуслугите и външния свят.

„Монолитно приложение“ е обратното на това, което са микроуслугите. Това е ретроним за приложение, при което целият код е в един голям двоичен изпълним файл. Както обяснява TechTarget, монолитното приложение е по-трудно за мащабиране и по-трудно за подобряване. Но тъй като е изградено като едно цялостно приложение, то не изисква толкова управление, колкото архитектурата на микроуслугите.

Ограничени концепции: Как да дефинирам микроуслуга

Нека се върнем за момент към предишната ни заповед, че микроуслугите трябва да направят едно конкретно нещо. Това е лесно да се каже, но на практика функционалността често се преплита и чертането на разделения е по-трудно, отколкото изглежда. Анализът на домейни и дизайнът, управляван от домейн, са теоретичните подходи, които ще ви помогнат да раздвоите задачата си за голяма картина на отделни проблеми, които микросервисът може да реши. В този процес, очертан в осветителна поредица от публикации в блогове от Microsoft, вие създавате абстрактен модел на вашия бизнес домейн и в процеса откривате ограничения контекст , който групира функционалността, която взаимодейства със света по специфичен начин.

Например, може да имате един ограничен контекст за доставка и друг за акаунти. Физическият обект от реалния свят би имал както цена, така и място, на което трябва да отиде, разбира се, но ограничените контексти представляват специфични начини, по които вашето приложение мисли и взаимодейства с тези обекти. Всяка микроуслуга трябва да съществува изцяло в един ограничен контекст, въпреки че някои ограничени контексти могат да обхващат повече от една микроуслуга.

Микроуслуги срещу ориентирана към услуги архитектура срещу уеб услуги

В този момент, ако сте ИТ професионалист, който се занимава с бранша от известно време, може би си мислите, че много от това звучи познато. Идеята за малки индивидуални програми, които работят заедно, може да ви напомня както за SOA (ориентирана към услугите архитектура), така и за уеб услуги , две модни думи от бурните Web 2.0 дни на 2000-те. Докато в един смисъл наистина няма нищо ново под слънцето, има важни разграничения между тези понятия и микроуслугите. Datamation има добра разбивка на разликите, но ето кратка версия:

  • В ориентирана към услуги архитектура отделните компоненти са относително тясно свързани, често споделят активи като съхранение и комуникират чрез част от специализиран софтуер, наречен корпоративна шина за съхранение . Микроуслугите са по-независими, споделят по-малко ресурси и комуникират чрез по-леки протоколи. Струва си да се отбележи, че микроуслугите възникват от средата на SOA и понякога се считат за вид SOA или наследник на концепцията.
  • Уеб услугата е публично изправен набор от функционалности, до които други приложения имат достъп чрез мрежата; може би най-разпространеният пример е Google Maps, който уебсайтът на ресторанта може да вгради, за да предоставя указания за клиентите. Това е много по-свободна връзка, отколкото бихте забелязали в архитектурата на микроуслугите.

Комуникация с микроуслуги

Крилата фраза, която често ще чувате за архитектурите на микроуслугите, е, че те трябва да съдържат „интелигентни крайни точки и тъпи тръби“. С други думи, микроуслугите трябва да се стремят да използват основни и утвърдени комуникационни методи, а не сложна и тясна интеграция. Както беше отбелязано, това е друго нещо, което отличава микроуслугите от SOA.

По принцип комуникацията между микроуслугите трябва да бъде асинхронна , в смисъл че кодовите нишки не се блокират в очакване на отговори. (Все още е добре да се използват синхронни комуникационни протоколи като HTTP, въпреки че асинхронните протоколи като AMQP (Advanced Message Queuing Protocol) също са често срещани в архитектурите на микросервисите.) Този вид свободно свързване прави архитектурата на микросервисите по-гъвкава в лицето на неуспеха на отделни компоненти или части от мрежата, което е ключово предимство.

Микроуслуги, Java и Spring Boot и Spring Cloud

Някои от първите работи по микроуслуги възникват в общността на Java; Мартин Фаулър беше ранен поддръжник. На конференция за Java през 2012 г. в Полша беше представена една от най-важните ранни презентации по темата, озаглавена „Микро услуги - Java, начинът на Unix.“ Препоръча се прилагане на принципите, ръководещи развитието на първите приложения на Unix през 70-те години („Напиши програми, които правят едно нещо и го правят добре. Напишете програми за съвместна работа “) за разработка на Java.

В резултат на тази история има много Java рамки, които ви позволяват да изграждате микроуслуги. Един от най-популярните е Spring Boot, който е специално създаден за микроуслуги; Boot се разширява от Spring Cloud, което, както подсказва името, ви позволява да разположите тези услуги и в облака. Pivotal Software, разработчикът на Spring, има добър урок за започване на разработка на микроуслуги, използвайки тези рамки.

Микроуслуги и контейнери: Docker, Kubernetes и други

Основната технология, която е отишла най-далеч към навлизането на микроуслуги в основния поток, са контейнерите .  Контейнерът е подобен на екземпляр на VM, но вместо да включва цяла самостоятелна операционна система, контейнерът е просто изолирано потребителско пространство, което използва ядрото на операционната система на хоста, но в противен случай поддържа кода, изпълняващ се в него, самостоятелен. Контейнерите са много по-малки от екземплярите на VM и са лесни за бързо разгръщане, локално или в облака, и могат да се въртят нагоре или надолу, за да съответстват на търсенето и наличните ресурси.

Привлекателността на контейнерите за микроуслуги трябва да е очевидна: Всяка отделна микрослужба може да работи в собствен контейнер, което значително намалява режийните разходи за управление на услуги. Повечето внедрения на контейнери имат допълнителни инструменти за оркестрация, които автоматизират внедряването, управлението, мащабирането, работата в мрежа и наличността на приложения, базирани на контейнери. Комбинацията от малки, лесни за изграждане микроуслуги и лесни за разгръщане контейнери прави възможната философията на devops. Има няколко реализации на концепцията на контейнера, но най-популярният е Docker, който обикновено е свързан с Kubernetes като платформа за оркестрация.

Пролетта, макар и популярна, е обвързана с платформата Java. Базираните на контейнери системи, от друга страна, са полиглоти: Всеки език за програмиране, който поддържа операционната система, може да работи в контейнер, което дава повече гъвкавост на програмистите. Всъщност голямо предимство на микроуслугите е, че всяка отделна услуга може да бъде написана на който и да е език, който е най-разумен или с който разработчиците са най-удобни. Всъщност една услуга може да бъде напълно възстановена на нов език, без да се засяга системата като цяло, стига нейните API да останат стабилни. DZone има статия, обсъждаща плюсовете и минусите на Spring Cloud срещу Kubernetes за микроуслуги. 

Модели за проектиране на микроуслуги

Без значение какъв език използвате за разработване на микроуслуги, ще се сблъскате с проблеми, с които други разработчици са се сблъсквали преди. Дизайнерските модели са формализирани, абстрактни решения на повтарящи се проблеми в компютърните науки и редица от тях са специално за микроуслуги. Devopedia има страхотен списък, който включва:

  • Сервизен регистър: за свързване на клиенти към налични копия на микроуслуги
  • Прекъсвач: за предотвратяване на повтарящи се повиквания на неуспешни услуги
  • Резервен: за предоставяне на алтернатива на неуспешна услуга
  • Sidecar: за предоставяне на спомагателна услуга на основния контейнер, като например за регистриране, синхронизиране на услуги или наблюдение
  • Адаптер: за стандартизиране или нормализиране на интерфейса между основния контейнер и външния свят
  • Посланик: за свързване на основния контейнер с външния свят, например за проксиране на връзки на localhost към външни връзки

Микроуслуги и облак : AWS и Azure

Както беше отбелязано по-горе, едно от предимствата на използването на контейнери е, че те могат лесно да бъдат внедрени в облака, където са налични гъвкави изчислителни ресурси, за да можете да увеличите максимално ефективността на приложението си. Както можете да си представите, всички главни доставчици на публични облаци са нетърпеливи да използвате техните платформи, за да стартирате вашите приложения, базирани на микроуслуги. За повече информация разгледайте ресурсите на Amazon, Microsoft и Google.