RESTful API срещу Microservice

Edit: нова страхотна статия за Microservice от Thoughtworks.

Редактиране: още едно страхотно ръководство за проектиране на API от Google.

Редактиране: моите мисли след четене на модуларизация

Архитектурният стил на REST е представен за първи път през 2000 г., основно проектиран да работи добре с HTTP / 1.1. Основният му принцип е да се определят имена на ресурси, които могат да бъдат манипулирани с помощта на малък брой методи. Ресурсите и методите са известни като съществителни имена и глаголи на API. С HTTP протокола имената на ресурсите естествено се преобразуват в URL адреси, а методите естествено се преобразуват в HTTP методи POST, GET, PUT, PATCH и DELETE.

Един ден ме попитаха за разликите / отношенията между RESTful API и много горещите микросервизи. Има много страхотни статии, които говорят за принципите и дизайна на Microservices, а RESTful API изглежда много подобен на Microservices. Микросервизите обаче са по-скоро архитектурни, докато RESTful API се фокусира повече върху това как да се излагат микросервизи.

Без значение как внедрявате Микросервизи, един от основните двигатели е надеждата за по-бързо време на пазара, така че една от основните му дизайнерски цели е да създаде отделени, независими и малки системи (позволяващи независимата доставка на бизнес стойност), всяка от които

  • е лесно да се разбере / промени (защото те са малки)
  • е единственото място с логика / бизнес правило
  • не излага подробности за внедряването, като например база данни, за да се осигури хладно свързване; това също така предполага, че RESTful API или функции, които реализират агрегати в ограничен контекст, трябва да принадлежат на една микросервиз, тъй като те са тясно свързани по отношение на споделяне на много еднакъв дизайн и архитектура на високо ниво, т.е. език за програмиране и рамки, рамка за достъп до база данни, и т.н., за да намалите сложността, тъй като може да не искате да поддържате модул или ограничен контекст (т.е. услуга за съобщения), която използва различни технологии и технологични стекове
  • може да бъде разгърната отделно, без да засяга други, стига интерфейсите да останат същите
  • още няколко предимства (като мащаб отделно, избор на езици за програмиране и т.н.)
  • сложност на развитието на търговията за скучна, но трудна оперативна сложност, т.е. междусекторни проблеми като откриване на услуги, сигурност на обслужване и сигурност на произхода, наблюдение (включително телеметрия и разпределено проследяване)

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

Изолацията или толерантността е една от най-важните цели при проектирането на микросервизи. Ако системата се състои от набор от добре изолирани Микросервизи, срив в една от Микросервизите няма да засегне цялата система. Например, ако микросервизи (като услуга за членове) са основна услуга, от която зависят много други микросервизи, трябва да помислим как да ги проектираме, за да сме сигурни, че комуникацията и взаимодействието с основната услуга са устойчиви на откази. Ограниченият контекст би могъл да помогне, като имам предвид, че всяка Микросервизи (като услуга за съобщения) има собствена дефиниция на същия модел (като член) и ги поддържа / синхронизира вътрешно, така че да ги използва, без да извиква Микросервисите. Брокерът на съобщения би могъл да се използва и като междинен елемент между тях, когато се опитва да извика Microservices да промени състоянието си и в крайна сметка данните ще станат последователност.

Следователно, Microservices е по-скоро за архитектурен и дизайнерски стил и е възможно да можете да внедрите Microservices без RESTful API. Въпреки това, RESTful API улеснява изграждането на слабо свързани микросервизи.

RESTful API беше представен преди Microservices. Той е един от RPC протоколите. Една от ключовите идеи е всеки обект да има единен интерфейс. Например обектите се идентифицират и манипулират чрез шаблон. В света на ASP.NET Web API обектите се организират чрез атрибути Контролери, Действия и HttpVerbs.

За разлика от API на библиотеката (под формата на .dll), RESTful API (на практика API, изложен чрез HTTP крайни точки)

  • е наистина слабо свързан (стига интерфейсите и тяхната семантика да са еднакви, внедряването на API на сървъра може да се промени по всяко време, без да се притеснявате за нарушаване на неговите потребителски и потребителски разположения)
  • е езиково-агностичен

Следователно, Микросервизите и RESTful API решават различни проблеми, но работят заедно!