13 Java рамки за твърди микроуслуги

Това беше дълго пътуване за Java, език, който започна като lingua franca за кутията върху телевизора в дните, когато телевизорите не идваха с вграден Roku или Chromecast. Тогава Java щеше да притежава World Wide Web, като анимира браузъра, преди JavaScript да се появи и да го отстрани.

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

Междувременно JavaScript като цяло и по-специално Node.js предизвикаха Java на сървъра, използвайки тяхната висока производителност и скорост без нишки, за да поемат огромен дял от трафика в мрежата. Node завладя въображението на най-новите сървърни програмисти, предлагайки не само скорост и ефективност на ресурсите, но и простотата на кода, който работи както на клиента, така и на сървъра.

И въпреки нарастването на конкуренцията, Java продължава не само да оцелява, но и да превъзхожда. Много от екипите, натоварени с разработването на микросервизни архитектури, продължават да използват Java. Основната причина трябва да е, защото технологията е тествана от години на фронтовите линии, анализирайки HTTP заявки. Sun създаде солидна виртуална машина и Oracle продължава да я поддържа и поддържа.

Друга причина трябва да бъде продължаващата еволюция на езика. Java 8 предлага солидна поддръжка за функционалните езици като Scala и Kotlin. JVM сега е основа за много от най-добрите експерименти в развитието на компютърния език. Десетки нови езици могат да се компилират до байтов код на Java и да се свържат помежду си, за да накарат сложните проекти да работят заедно. Много от стековете, работещи гладко на JVM, могат да бъдат изградени от смес от Java и редица други езици.

Най-голямата причина обаче трябва да е чистата инерция. Докато пиша, на Dice са изброени 371 работни места за програмисти на COBOL. Има много, много повече работни места с думата Java в тях. Изненадващо ли е, че интелигентните екипи разглеждат своите огромни купища остаряващ Java код и мислят, че най-простото решение е просто да добавите странична врата, която изплюва данните като JSON структури от данни? Voilà. Старият код продължава да работи, но действа като модерна микрослужба на тези странични врати.

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

Ето списък с 13 опции с отворен код, които разработчиците на Java използват, за да намерят решения, които формират основата на микросервизните архитектури навсякъде.

Пролетно зареждане

Светът на Java изгражда пролетни приложения от дълго време. Spring Boot е конкретна версия на Spring, която значително улеснява процеса, като обработва много от подробностите за конфигурацията вместо вас. Spring Boot е създаден, за да автоматизира стартирането на пролетни проекти от всякакъв вид, не само микроуслуги. За да направите нещата още по-прости, след като приключите с приложението, Spring Boot се смесва в уеб сървър и изплюва един JAR файл, който е почти всичко, от което се нуждаете, с изключение на JVM. Помислете за него като за оригиналния контейнер на Docker.

Цялата тази хитрост се оценява от много от хората, натоварени с изграждането на микросервизи, защото цялата конфигурация става досадна, когато трябва да го правите отново и отново за всяка от дузината микро услуги. Ако Spring Boot може да го автоматизира, изхвърлянето на няколко десетки микроуслуги е толкова по-лесно.

Микроуслугите, разработени с Spring, следват същата философия на MVC като макро уеб приложенията, които изграждаме от години. Рамката се радва на всички дълбоки връзки, изградени в продължение на години на разработка на Java, включително интеграция с всички основни и малки хранилища на данни, LDAP сървъри и инструменти за съобщения като Apache Kafka. Съществуват и десетки малки и не толкова малко функции за поддържане на работеща колекция от сървъри, функции като Spring Vault, инструмент за поддържане на тайните, паролите и идентификационните данни, необходими на производствените сървъри. Всички тези предимства показват защо Java програмистите се присъединяват към бандата от много години.

Eclipse MicroProfile

През 2016 г. някои от феновете на общността на Java Enterprise се огледаха и решиха да изчистят целия пробив от Java Enterprise Edition, за да могат хората да изграждат прости микроуслуги с класическите части. Те изхвърлиха изненадващ брой библиотеки, но запазиха код за обработка на REST заявки, анализиране на JSON и управление на инжектиране на зависимости. Това, с което завършиха, наречен Eclipse MicroProfile, беше бързо и просто.

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

Dropwizard

Когато Dropwizard се появи през 2011 г., той отвори очите на разработчиците на Java Enterprise за това колко малко код наистина е необходим. Рамката Dropwizard предостави много прост модел за разработка с много от важните решения, взети за вас, и продължи да следва този път. Добавяте малко бизнес логика и след това почти всичко останало е конфигурирано за вас според конвенцията. Резултатът са тънки JAR файлове, които потребителите хвалят за бързото стартиране.

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

WildFly Thorntail

Хората от Red Hat създадоха собствена версия на MicroProfile, пълна с инструмент за конфигуриране. Първоначално рамката се наричаше WildFly Swarm, но след това беше преименувана на Thorntail. Уебсайтът Thorntail ви помага да създадете свой собствен компилационен файл на Maven, само като посочите функциите, от които се нуждаете. След това Maven се грижи за сглобяването на всичко.

Thorntail също ще открие основните компоненти, от които се нуждаете, чрез сканиране на вашия код, но можете да замените това с файл със спецификация (спецификация). Когато всичко се изпълни, Thorntail ще премахне частите от Java Enterprise Edition, които няма да бъдат използвани, и ще създаде JAR файл, който е малък и готов за разполагане с една команда - елегантна функция, която позволява на проекта Thorntail да го нарече Uber -ЯР. Това е друг подход за следване в традицията на Java Enterprise Edition, без да се запазва целият багаж.

Хелидон

Helidon излиза само от няколко месеца след прессъобщенията и първия ангажимент към хранилището на GitHub, но рамката вече привлича вниманието, което подкрепата на Oracle гарантира. Въпреки че вселената на Java е огромна, много от нея все още се върти около Oracle. 

Архитектите на Хелидон следват много от същите теми, които се повтарят и в другите проекти тук. Изкоренете Java Enterprise Edition и запазете лекото ядро, базирано на сървлети, което е спечелило доверието в света. В случая на Хелидън разработчиците започнаха с Netty и добавиха достатъчно код, за да направят някакво маршрутизиране и обработка на грешки. За да направят нещата интересни, те приеха два основни модела за кода, така наречените SE и MP версии.

Helidon SE ще изглежда много познат на програмистите Node.js с дългите вериги от извиквания на функции, обединени от точки. Helidon MP ще изглежда по-познат на програмистите на Java, които използват JAX-RS. Има и някои полезни и добре оценени инструменти за проверка на изправността на сървърите или проследяване на потока от данни през гора от микроуслуги. Това са убедителни причини да проучите потенциала, дори без подкрепата на Oracle.  

Крикет

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

Джърси

Един от стандартните подходи за разработване на уеб услуга е Java API за RESTful Web Services (известен още като JAX-RS), обща спецификация, внедрена в рамката на Джърси. Подходът зависи в голяма степен от използването на поясненията за задаване на картографиране на пътя и подробности за връщането. Всичко останало от разбора на параметрите и опаковането на JSON се обработва от Джърси.

Основното предимство на Джърси е, че той изпълнява стандарта JAX-RS, функция, която е достатъчно желана, така че някои разработчици да комбинират Джърси с Spring Boot, за да се насладят и на двете заедно. 

Играйте

Един от най-добрите начини да изпитате междуезичната мощ на JVM е с рамката Play, купчина код на Scala, който се свързва с Java или някой от другите JVM езици. Фондацията е много модерна, с асинхронен модел без гражданство, който не претоварва сървъра с безкрайни нишки, опитващи се да следи потребителите и техните сесийни данни. Има и редица допълнителни функции, които могат да се използват за подобряване на уебсайт като OpenID, проверка и поддръжка на качване на файлове.

Кодовата база на Play се развива повече от десетилетие, така че ще намерите и отзвуци от отдавна забравени времена като поддръжка за XML. Играта е едновременно зряла и гъвкава, комбинация, която може да бъде рядка в дивата природа.

Суагър

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

Опростеното, почти спартанско описание на API в конфигурационния файл на Swagger е завъртяно в Java код за внедряване на интерфейса, документиране на поведението му и предоставяне на набор от инструменти за тестване на кода, изграден под него. Има дори механизъм за управление на API, така че можете да работите с немитите маси, които скоро ще се блъскат във вратата на вашия API и очакват отговори.

Swagger е екосистема за API и не се ограничава само до Java. Ако вашият екип се премести на Node.js или някой от няколко десетки други езика, има модул Swagger Codegen, който чака да преобразува вашите OpenAPI спецификации в изпълнение на този език.

Restlet

Една от най-големите разлики между различните рамки е броят на връзките с други услуги и библиотеки. Проектът Restlet предлага една от по-големите колекции от функции и връзки. Той вече е интегриран с библиотеки като JavaMail, в случай че вашата микрослужба ще трябва да говори POP, IMAP или SMTP с някакъв пощенски сървър и Lucene / Solr, в случай че искате да изградите индекси за търсене на големи парчета текст и метаданни, увити около то.

Възможностите в Restlet просто продължават, защото този стек обикновено поддържа няколко различни опции за всяка част. Не е необходимо например да използвате JSON, защото кодът ще обработва XML, CSV, YAML и още няколко файлови формата. Получавате няколко различни опции за шаблоните за структуриране на вашия отговор. Една от най-добрите функции е клиентът Restlet, който ви позволява да тествате своите API от браузъра Chrome.

Скуош

Отстраняването на грешки на микроуслуги често е истинско предизвикателство, тъй като частите са толкова свободно свързани и е трудно да се проследи потокът от данни през всички слоеве на системата. Скуошът ви позволява да настроите точки на прекъсване в кода си, работещ на клъстер Kubernetes, и след това да получите всички данни обратно във вашата IDE, сякаш са код, който се изпълнява локално. Squash също се интегрира с Node.js и Python по време на изпълнение, в случай че вашата колекция от микроуслуги не е само за Java.

Телеприсъствие

Друга възможност за отстраняване на грешки е използването на Telepresence за създаване на локален прокси за микросервиз в отдалечен клъстер Kubernetes. Обажданията ви за тази услуга ще бъдат пренасочени към локалната версия, където можете да настроите точки за прекъсване или да направите каквото и да е друго, което можете да си представите на вашата локална машина.

Zipkin

Zipkin е механизъм за регистриране на събития на различни микроуслуги и след това корелиране на събитията, така че проблемите да могат да бъдат изолирани и изучавани, докато се пулсират чрез събирането на машини. Има реализация на Zipkin за Java, както и поне шест други езика, така че могат да се справят с многоезични системи. Някои от най-сложните рамки като Spring вече са интегрирани Zipkin под някаква форма.