Наше путешествие в мир микросервисов – и что мы этому научились.

nashe puteshestvie v mir mikroservisov – i chto my etomu?v=1656541606

Игнасио Салазар Уильямс

QTmUvRWczec44xHTrgf7UoeVK47ivPHRNaaf
«Снимок компаса сверху, выложенного на старой карте» Химеш Кумар Бехера на Unsplash

Я знаю, я знаю, что все говорят о микросервисах. Это шаблон, который приведет нас к будущему зодчеству, говорят те, кто говорит о цифровой трансформации. Для других это «разрушитель монолитов», серебряный шар, который решит все наши архитектурные проблемы.

Позвольте мне рассказать вам кое-что о микросервисах. Они действительно что-то, но это не просто **пуф** **какая магия** **Сказочная пыль** здесь есть решение всех наших проблем. я нет собираюсь рассказать вам больше о них как шаблоне, но я попробую рассказать эту историю (мою историю) как можно лучше. Я обсудю, как эта концепция, эта модель была разработана в реальности, при определенных обстоятельствах. Я называю это Микроармагеддон.

kHXZp0ke9-N0aBMf6LeqPV5RrjZaDIKjCtOP
Источник из GIPHY

Каждый день в моей команде случались вещи, которые были вне нашей досягаемости и приводили к проблемам. Но это был только вопрос увидеть общую картину и работать с ментальностью, чтобы постоянно совершенствовать наши компоненты, пока мы не достигли стандартов качества, которые мы как команда имели.

Итак, пожалуйста, следуйте за мной в этом путешествии, полном добра и зла, смеха и слез, и множества «почему, черт возьми, мы вообще это сделали?»

TL; DR?
Я знаю, что это кажется много, но позвольте мне кое-что сказать. Если вы хотите учиться на чужих ошибках по поводу микросервисов, я настоятельно рекомендую вам полностью прочитать эту статью. Но если нет, вы можете перейти к мемам — по крайней мере, это заставит вас смеяться!

Немного фона

HFuGKP76J88kmX5hEOYDvZQnocRWHcqehIql
Источник из Innoview

Начнём с основ. Был я (Привет!), недавно окончил факультет информатики, который только устроился на консультацию (дикая мера работы). Меня назначили на проект для одного из наших клиентов (в их офисах), в котором наша команда отвечала за применение цифровой трансформации в их бизнесе. Потому были привлечены микросервисы. (Теперь, когда я более опытен в этой области, я очень часто слышу эти два понятия вместе.)

Мы использовали Node.js как внутренний язык программирования (ohhhh yeeees), и это означало, что мы также использовали Express в качестве фреймворка по умолчанию для раскрытия API. Кроме того, важно добавить в смесь то, что мы использовали методологию Agile Scrum (вы увидите, почему я вскоре поднял этот момент).

Команды

AyGe9CCxGMuw6dKE2txFxzMYtm-Dg511LMTF
Фото от rawpixel на Unsplash

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

Команда «Архитектура». выглядел примерно так:

  • 1 старший менеджер (наш)
  • 2 менеджера (1 наш, 1 их)
  • 10 архитекторов (6 наших, 4 их)
  • 2, ответственный за большие данные
  • 3 зарядного CI/CD
  • 3, ответственный за безопасность
  • 2, ответственный за архитектуру разработки back/front-end

Каждый Команда разработчиков выглядел примерно так:

  • 1 Scrum Master (ещё одна консультация)
  • 1 Владелец продукта (сторона клиента)
  • 4 разработчика (2 наши, 2 их)
  • 1 QA
  • 1 UX
  • 1 архитектор (сторона клиента)

Я знаю, что это уже звучит плохо, смешивая все это, но не беспокойтесь — для нас это была возможность все исправить…

Базовые навыки разработчика

jmm-Fjij7bveSXWDVpeKMQVaeHMijUZyp8oG

Никто из нас не родился опытным разработчиком, все мы были как обезьяны, пытающиеся составить базовый Hello World. Фелипе Лазо

Члены нашей команды имели разный опыт, от тех, кто едва знает, как работает их собственный компьютер, до тех, которые, вероятно, пришли из NASA. Некоторые люди работали с COBOL, Java, JavaScript, C, Python и другими, а другие работали вообще без языков.

Поэтому было бы легко понять, если бы некоторые члены команды не были особенно ловкими в разработке хорошего кода и структур, поскольку многие из них не имели предыдущего опыта в этой теме. Опять же были и другие, которые имели определенный опыт. Поэтому было прекрасно иметь все эти разные профили, но мы должны были использовать их лучше. Мы не могли рассматривать это как слабость, а возможность для нас как команды (особенно когда вы работаете в agile среде).

Цель

Здесь мы преследовали цель реализовать Microservices как Back-End решения для интеграции устаревших компонентов, которые были у нашего клиента. Мы планировали представить их как простые API, чтобы команды могли интегрировать их в свои программы.

Вот начальные требования к нашим микросервисам:

  • Они должны были использовать службу SOAP и вернуть результат в формате JSON. Я знаю, что для большинства из вас (и даже для меня) это будет звучать очень плохо. Но так должно быть, потому что микросервисы не имели права напрямую подключаться к уровню данных, поэтому они должны были пройти через SOAP [Client initial requirement].
  • Он должен был зарегистрировать все данные, которые создали микросервисы, в совершенно новом DataLake.
  • Основная проверка подлинности.
  • Сделайте их очень надежными.

К этим требованиям мы должны были добавить:

  • качество, которое мы желали с помощью модульного тестирования (включая наш амбициозный стандарт покрытия 90%)
  • Статический анализ кода
  • Тест на производительность
  • и какая-нибудь проверка безопасности.

Все это нужно было вручную проверять локально, а затем проверять через строгий конвейер (CI/CD). Я говорю суровый, но это не было блокировки. Это все равно позволяло командам разворачивать микросервисы даже если одна из задач не удалось. Но никогда не делайте этого или, по крайней мере, знайте последствия.

Пока проблем у нас вообще не было. Это звучало достаточно хорошо для базовой настройки для разработки микросервисов. У нас был DevOps, мы все были в одном месте, у нас была своя методология, у нас был свой шаблон и у нас было фантастическое время выполнения (Node.js), которое позволяло нам строить и соблюдать правила шаг за шагом, чтобы сделать этот проект шедевр. Ну, по крайней мере, мы так думали…

Ой, парень, были допущены ошибки

NI49nxrMg1e5yTrvyk9QU6RZrVo5qONSrong
Точное изображение команды, которая пытается сохранить микросервисы

Посмотрите на довольно точную картину команды архитектуры, которая пытается спасти микросервисы от гибели. Почему это произошло, спросите вы? Что ж, это может произойти, если вы дадите нескольким командам разрабатывать собственные микросервисы в среде Agile. Проблемы возникают, когда вы не даете никакого другого объяснения, что такое микросервисы, что они делают, для чего они предназначены, как мы ими управляем и, главное, насколько они должны быть велики.

И ко всему этому, в начале проекта у нас не было ни одного надежного программного обеспечения для контроля версий, кроме Subversion. Тем временем мы ждали, пока Git будет установлен на месте.

Проблема, которую мы часто видели во многих незрелых командах, заключалась в том, что вместо того чтобы пытаться потушить огонь, они просто распространяли его еще больше, дублируя микросервисы и начиная надстраивать их. Это сделало их еще больше, и они содержали бесполезное и повторяющееся содержимое.

  • Микросервис Клиенты (Команды A, B и C работают над этим)
    — Команда Б устала от всех слияний, от всей борьбы за то, кто за что отвечает, а также от ее развертывания.
  • Микросервис Кредиты-клиенты (Команда Б)
    — Команда B копирует точное состояние, над которым они работали в Клиенты Микросервисы. Это открывает и поддерживает все больше и больше ненужных конечных точек поверх их практически полезных.

Итак, мы были здесь. Как у беса (на самом деле) мы решаем все эти проблемы? Ну это то, что мы сделали.

Симптомы

A2j6VKJ699KC42Umz9HLnuNLJhkGTLKc8z8A
Фото от rawpixel на Unsplash

Мы явно не могли продолжать все эти беспорядки, поэтому мы одели наши белые халаты, стерилизовали комнату и сделали вскрытие того, что у нас было. Мы определили симптомы нашей неизбежной обреченности, определили приоритетные из них и попытались одержать небольшие победы, позволяющие взять ситуацию под контроль.

Маленькие победы позволяют не только доказать, что вы знаете эту тему, но и дают понять командам, что можно что-то сделать, чтобы улучшить их ежедневную работу.

Мини-Монолит АКА Макросервисы

Ждать, что? Мы говорили о микросервисах…

S1UIv5TkaDGJjNGUjDudUMTPXhuyKITVkeZV

Бьюсь об заклад, вы неоднократно читали о ТВЕРДЫЙ. принцип, о наличии разумных компактных элементов, обладающих знаменитым принципом единой ответственности.

То, что у нас было, не было ничего подобного. Вот почему я их позвал макросервисы, после того, как я увидел, что происходит.

Просто представьте себе это: в простой области, назовем ее Пользователиих было около 15 POST Операции в же **кашель** «Микросервис». Каждый из них имел разное предназначение в одном домене и использовал для каждой из них созданные по заказу библиотеки. Кроме того, мы распространили все тесты единиц и производительности. Это был хаос. Это было примерно так:

.
├── app --The whole MS is in here
│   ├── controllers --All the controllers of the domain
│   │   ├── dummies
│   │   │  └── ** All the dummies for each controller **
│   │   ├── xsl
│   │   │   └── ** All xsl configuration for each controller **
│   │   ├── Controller1.js
│   │   ├── Controller2.js
│   │   ├── Controller3.js
│   │   ├── Controller4.js
│   │   ├── Controller5.js
│   │   └── **Literally 20 more controllers**
│   ├── functions --All the functions of the MS
│   │   ├── function1.js
│   │   ├── function2.js
│   │   ├── function3.js
│   │   └── function4.js
│   ├── properties --All the properties of the MS
│   │   ├── propertie1.js
│   │   └── propertie2.js
│   ├── routes --All the routes of the MS
│   │   ├── routes_useSecurity.js
│   │   └── routes_withoutSecurity.js
│   ├── services --Extra services that were consumed
│   │   ├── service1.js
│   │   └── service2.js
│   └── xsl
│      └── **A bunch of XSL to do transformations**
├── config --"Global" configurations
│   ├── configSOAP.js
│   ├── configMS.js
│   ├── environments.js
│   ├── logging.js
│   ├── userForBussinessA.js
│   └── userForBussinessB.js
├── package.json
├── README.md
├── test--All the tests
│   ├── UnitTesting
│   │   └── Controllers
│   │       └── ** All the 25 tests in theory **
│   └── PerformanceTest
│       ├── csv_development.txt
│       ├── csv_QA.txt
│       ├── csv_production.txt
│       ├── performance1.jmx
│       └── performance2.jmx
├── server.js --Express Server
├── serverKey.keytab
├── sonarlint.json
├── encryptor
├── ** Around 10 more useless files **
└── Dockerfile
9omI01k5ttMHeMANmTT3xHEgG9fFvclEkeLo
Это был почти я

Прежде всего, это нужно было прекратить, потому что это было неуправляемо. Команды сражались, потому что чтобы что-то проверить в среде DEV (что они делали часто), им приходилось проходить через конвейер CI/CD. В тот момент в проекте он, безусловно, не был идеальным.

Так что если команда А изменен Контроллер 1, они должны были пройти через конвейер с высоким шансом на неудачу (и развертывание тогда тоже не удалось). Они шли бы снова и снова, пока не добились успеха. Поэтому все команды пытались участвовать в гонках, чтобы они не были последними. Потому что если что-то не удавалось в этом развертывании, то указывали на пальцы. Это означало, что команда сделала что-то не так и сломала это.

Весело верно? Здоровая среда для всех разработчиков. Кто не хочет быть там… ну, НЕ Я!

Пора начать все заново

w6qPgt5B6Wy2mmnYRsbSNmY34FSk5IqKiDP3

Нам нужно было начинать все заново и делать все правильно. Возьмите под контроль, кто что делал, и возложите на них ответственность. Но мы должны были быть справедливыми: мы не собирались делать команду ответственной за целый домен, содержащий 15 операций, тестов, развертываний и т.д. Никто этого не желал.

Вы знаете, мы ловкие, ловкие люди делают ловкие вещи. Нам не нужно тратить свое драгоценное время на эти потасовки о том, кто чем владеет, подняв блокировщики и указывая пальцем ** закатывает глаза**.

Шаг 1. Размер микросервисов

Я собираюсь сделать а смелое утверждение и говорят, что наибольшее количество сделок для любых микросервисов должны следовать за CRUD стандартный. Забудьте о том, насколько велики должны быть микросервисы.

Соблюдение этого правила даст вам покой ночью, зная, что в любой момент времени вам понадобится всего 4 операции в любом субдомене. И все это.

Это означает:

POST — Создать

Процедуры CREATE – это вставка новых данных как завершение микросервисов.

Получить — Прочесть

Процедуры READ считывают данные, необходимые клиенту.

PUT — Обновление

Процедуры UPDATE изменяют записи, не перезаписывая их.

DELETE — Удалить

Процедуры DELETE удаляют там, где указано.

3SKmmU2hZXeEdU2Owfg9z-ihdt-NS6Bq-8-k

Использование этого правила позволило нам создать более компактные, умные и стандартные микросервисы. К примеру, это даст нам преимущество, когда придет время разделить микросервисы.

Скажем, у меня есть своя Клиенты Микросервис в банковском домене, и вдруг я вижу, что мне нужен не только наш кредитные клиенты но и наши заемщики. Ну, это легко. Я просто разделяю наших клиентов домена на два субдомена: Кредит-Клиент и Кредит-Клиенти оттуда можно увидеть, как все начинает становиться на свои места.

Идеально! Теперь у нас были надлежащие микросервисы. Теперь клиент и команда должны были разработать способ разбить домены и знать их субдомены.

Если бы только был способ это сделать… **кашель** Дизайн, управляемый Доманом.

Шаг 2. Кто-то должен владеть им

У-у-у, мы решили одну из наших проблем, но подождите – теперь у меня была куча меньших частей, и все над ними работали. И я не собирался нести за это ответственность, если он сломался.

Все, что я скажу: «Если вы его кодируете, вы владеете им». И с этой могучей мудростью вы можете сказать: «Я это знаю, это знают все». Но нет, не все это знали, и это распространенное заблуждение. Поэтому будьте разумны, сделайте еще один шаг и возьмите это за правило.

gKCZrqk4UPKn1dD2rJ7n-QJnrCHKoBELGhYN
Источник из статьи Д. Кита Робинсона Научитесь любить Git

Git позволяет вам развиваться спокойно (если это хорошо применено – проверьте ссылку «Учимся любить Git» от Д. Кита Робинсона выше), зная, что ваш код всегда будет актуален. Если кто-то хочет улучшить его, предложить изменения или если ему просто нужно обновление, все это должно пройти через владельца. Ради этого примера скажем, что владельцем является архитектор команды DEV, которая его разработала. Это очень хорошо работает в гибкой среде.

Шаг 3. Конечная точка API (именование) и установка версий

То, как вы называете API, может сэкономить всем вашим разработчикам массу времени и усилий. Именование API – это не игра. Это могло бы спасти жизнь.

Очень важно прибавлять ценность своим микросервисам, правильно называя их. Если вы не знаете, как их назвать, спросите у компании и обсудите это со своей командой. Здесь может помочь разработка, ориентированная на дизайн.

Ознакомьтесь с инструкциями по разработке RESTful API – лучшие методы для получения дополнительной информации здесь. Я мог бы процитировать всю страницу.

Шаг 4: Давайте перестроим то, что у нас было

D1OTtJsvT32jf-aLthKXqbYlnWQwbOkJpYSq
«Ребенок, который играет с башней Дженга», Михал Парзуховский на Unsplash

Одно дело иметь правильную концепцию, но как это выглядит на практике?

Следующее дерево файлов, которое я вам покажу, возвращает моему представлению о том, насколько я последователь концепции микросервисов. Я заставил его следовать ослабленное сцепление и высокая сплоченность концепция между услугами:

.
├── config
│   ├── artillery.js
│   ├── config.js
│   ├── develpment.csv
│   ├── processorArtillery.js
│   ├── production.csv
│   └── qa.csv
├── index.js
├── package.json
├── package-lock.json
├── README.md
├── service
│   ├── getLoans --The operation
│   │   ├── getLoans.config.json --Configuration of the resource
│   │   ├── getLoans.contract.js --Contract test
│   │   ├── getLoans.controller.js --Controller
│   │   ├── getLoans.performance.json --Performance test config
│   │   ├── getLoans.scheme.js --Scheme validator
│   │   ├── getLoans.spec.js --Unit Tests
│   │   └── Util --Local functions
│   │       ├── trimmer.js
│   │       └── requestHandler.js
│   ├── postLoans
│   │   ├── postLoans.config.json
│   │   ├── postLoans.contract.js
│   │   ├── postLoans.controller.js
│   │   ├── postLoans.performance.json
│   │   ├── postLoans.scheme.js
│   │   └── postLoans.spec.js
│   └── notFound
│       ├── notFound.js
│       ├── notFound.performance.json
│       └── notFound.spec.js
├── Util --Global functions
│   ├── headerValidator.js
│   ├── bodyValidator.js
│   ├── DBConnector.js
│   └── BrokerConnector.js
├── sonarlint.json
└── sonar-project.properties

Во время DDD процесса, но также в виде каталога/файла. Для целей этого примера я использовал проект в Node.js.

Каждая операция наших микросервисов имела все компоненты, отвечающие требованиям ее разработки, конфигурации, модульного тестирования, тестов производительности, теста контракта, проверки схемы и контроллера. Таким образом, обработка сделки в целом позволила нам контролировать, когда наши микросервисы слишком растут и их приходится разделять. Итак, нам почти пришлось переместить всю папку в соответствующий новый микросервис. Но это было все – не нужно пытаться найти правильные компоненты или пытаться жонглировать ими, чтобы снова заработал.

ПРИМЕЧАНИЕ: Мы создали маршрут API динамически, поэтому каждая операция является достаточной описательной, вместе с package.json проекта, чтобы построить маршрут, который мы выставили. Это позволило получить гибкость, которую мы хотели: больше не было ручного редактирования маршрутов (здесь часто допускается много ошибок, поэтому мы хотели их избежать). Например:

  • ДИЕСЛОВО /{{Название артефакта}}/{{Домен}}/{{Версия}}/{{Субдомен}}/
    — Нame of Artifact: Какой артефакт вы раскрываете (микросервисы, BFF или любой другой)?
    Домен: Домен, к которому относится операция.
    Версия: Текущая основная версия, доступная нашему ресурсу.
    Субдомен: Операция, которую выполнят наши микросервисы CRUD.
  • GET/Microservice/Client/v1/loan/ — Получить все займы, предоставленные всеми клиентами.

Это действительно звучит как магия, но я очень рекомендую. Вы увидите, что большинство проблем, возникающих у вас при организации ваших микросервисов, будет значительно уменьшено.

Шаг 5: Документация

exGoVYJp-DUx9jiFKEqFceDZNDu81jww0Slj
Гениальный комикс от Дилберта, Source Here

Уфф, я должен сказать, я буквально прошел озноб. Я могу представить всех вас, ловких практиков, которые выкрикиваете свои души в столкновениях. Но ты не волнуйся, я поведала тебе об этом.

Я расскажу о двух концепциях: первой и самой важной, поскольку мы открываем API, давайте все попробуем это Первая разработка API.

API First Development – ​​это стратегия, где первой задачей бизнеса является разработка интерфейса прикладной программы, чтобы заинтересовать целевого разработчика, а затем создать продукт поверх него, будь то веб-сайт, мобильное приложение или программное обеспечение SaaS. Создавая API, подразумевая разработчиков, вы и ваши разработчики экономите много работы, закладывая основы, на которых другие могут строить. (Подход API-первой разработки по повторному сценарию).

И как мы это построим, спросите вы? Вот наша вторая концепция заработала: чванство, один из многих инструментов для создания API. Этот инструмент откроет ворота для проектирования и моделирования API чистым и организованным способом.

Вы не можете просить ничего лучшего. Мы не только уже решили проблему, с которой обычно сталкиваемся при адаптации документации, но это также улучшает то, как команда будет разрабатывать микросервисы. Это дает им правильные инструменты для взаимодействия друг с другом и устраняет возможность того, что другая команда может сказать что-то вроде: «Моей команде требовалось это как выход, с этими характеристиками этого API, а мы ничего подобного не получили». Тогда можно смело сказать: «Это документация нашего API, разработанная и утвержденная архитектором, отвечающая требованиям бизнеса». Падение микрофона. Таким образом любая дальнейшая итерация будет вокруг хорошо документированного API.

Шаг 6: Обучение

Как я уже говорил в начале, от нас зависит, как лучше всего использовать наших разработчиков и команд. Не торопитесь, определите слабые стороны и улучшайте!

I1erhqLk-0Kgh8G-4z7xkxTfKHmfAkVFYYQR

Я знаю, что каждый имеет разные преимущества при подготовке своих команд, но я очень рекомендую Кодирование доджо когда дело доходит до ловкости и оптимизации времени вашей команды. Эта техника обучения позволила нам научить все наши команды, чтобы у них был одинаковый базовый уровень знаний по каждому предмету (Node.js, микросервисы, модульное тестирование, тесты производительности и т.д.). Это также улучшило то, как информация передавалась командам — все мы играли в игру по телефону, и мы знаем, чем она заканчивается большинство времени. Никто не имеет времени читать многолетнюю документацию. Мы даже можем применить отзывы от наших команд к нашей повседневной жизни. Так что все ПОБЕДУТ!

Изученные уроки и заключительные слова

1Dbzf84WYhYQC0StYhfnrNvrlwXLADAq6X2R
Фото Hello I’m Nik на Unsplash

Для меня это значит знать, как все части вашей экосистемы взаимодействуют с одним и другим. Речь идет о том, чтобы научиться реагировать на них, потому что я могу заверить вас, что однажды вы подумаете над решением проблемы. Но тогда вы можете сделать что-то совсем другое, чтобы адаптироваться к требованиям. В этом и состоит красота микросервисов. Они позволяют вам быть гибкими, и как бы ужасно это ни выглядело, если вы будете придерживаться концепции сменные детали, ослабленное сцепление, и высокая сплоченностьповерьте, все будет хорошо.

Внедрение микросервисов – это путешествие для смелых людей, желающих совершенствоваться каждый день. Это для тех, кто отдает себе отчет, что они могли бы сделать лучше, кто видит общую картину и все исправляет.

Как я уже говорил раньше, я не был экспертом, когда начинал и были ошибки. Но это не мешало мне делать все правильно. Для всех, кто борется со своими собственными макросервисами, мини-монолитами, микросервисным адом, я могу сказать вам следующее: остановитесь, сделайте глубокий вдох, сделайте собственную диагностику и улучшайте. Пока не поздно сделать все правильно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *