МИКРОСЕРВИС АРХИТЕКТУРА
Принципы IDEALS, которые должен знать каждый разработчик микросервисов
Изучите эти шесть принципов проектирования, чтобы создать прочную основу для вашей микросервисной архитектуры.
Микросервисы получают широкое распространение в разработке программного обеспечения. Крайне важно иметь список принципов проектирования, которые могут помочь разработчикам точно реализовать архитектуру микросервисов.
Подобно тому, как SOLID помог объектно-ориентированному программированию иметь справочный список принципов проектирования, теперь у нас есть IDEALS для поддержки разработчиков в создании приложений на основе микросервисов.
Некоторые принципы SOLID также включены в IDEALS. Но IDEALS также включает принципы, характерные для архитектуры на основе микросервисов.
- I сегрегация интерфейса
- D возможность использования (на вас)
- E с вентиляцией
- A наличие над согласованностью (согласованность в конечном итоге)
- L oose Coupling
- S единая ответственность
Четкое понимание использования и недостатков различных шаблонов и принципов может помочь вам создать стабильное и поддерживаемое приложение на основе микросервисов. Давайте углубимся в каждый из этих принципов, чтобы лучше понять их.
Разделение интерфейсов
Архитектурный стиль микросервисов - это технологическая эволюция старой доброй сервис-ориентированной архитектуры (SOA). В SOA одним из важнейших факторов является дизайн сервисных интерфейсов или контрактов.
Обычно SOA предлагает определить единый контракт и позволить каждому клиенту службы придерживаться его. В конечном итоге контракт становится раздуваемым, поскольку он должен учитывать различные требования отдельных потребителей. Таким образом, эффективность и ремонтопригодность службы со временем снижаются.
Принцип разделения интерфейсов предполагает, что каждый интерфейс микросервиса должен учитывать определенные потребности клиентской программы. Другими словами, клиентов не следует заставлять зависеть от интерфейса, который они не используют.
Один из способов реализовать принцип - через шлюз API. Шлюз помогает понимать различные протоколы связи, переводить их по мере необходимости, изменять запрос и ответ в соответствии с сервисом и клиентскими программами и т. Д.
Возможность развертывания (зависит от вас)
Микросервисная архитектура многократно увеличивает распределенный характер приложений. Теперь команды имеют относительно большое количество модулей, каждый из которых работает на нескольких узлах, динамически поддерживаемых их облачными платформами.
В этой сильно распределенной среде развертывание больше не является неизбежным при разработке программного обеспечения. Непрерывное развертывание стало таким же важным, как и любой другой этап жизненного цикла.
Возможность развертывания, как требование, больше не может быть решена позже. - Яцек Хмиэль
Организации прилагают целенаправленные усилия для автоматизации всего процесса развертывания от среды разработки до производственной среды. Успех групп разработчиков теперь измеряется тем, насколько быстро и без усилий они могут развертывать качественные продукты для своего бизнеса.
Поскольку практически нулевое время простоя становится стандартом для приложений, команды должны планировать свою методологию развертывания еще на этапах разработки приложения.
Им также следует убедиться, что у них есть твердые планы в отношении мониторинга и управления трафиком в своей производственной среде. Все эти усилия в совокупности могут помочь командам в значительной степени сохранить возможность развертывания своих приложений.
Вот отличное определение того, что означает возможность развертывания:
Настройка инфраструктуры времени выполнения, которая включает контейнеры, модули, кластеры, постоянство, безопасность и сеть.
Расширение и уменьшение микросервисов или их перенос из одной среды выполнения в другую.
Ускорение процесса фиксации + сборки + тестирования + развертывания.
Минимизация времени простоя при замене текущей версии.
Синхронизация изменений версий связанного программного обеспечения.
Мониторинг работоспособности микросервисов для быстрого выявления и устранения неисправностей.
Событийный
В архитектуре, управляемой событиями, взаимодействие между приложениями обычно происходит через очереди сообщений (Kafka Topics, RabbitMQ и т. Д.). Исходное приложение создает сообщение на основе события в своем домене, которое каким-то образом манипулирует данными.
Одно или несколько приложений (служб), называемых потребителями, прослушивают очередь сообщений, чтобы получить информацию о событии. Потребители могут свободно выбирать свою бизнес-логику в зависимости от события и данных сообщения.
Одним из важнейших проектных решений по обеспечению отказоустойчивости микросервисов является предотвращение каскадных отказов, вызванных простоями зависимых сервисов. Архитектура, управляемая событиями, помогает в этом аспекте, поскольку производитель и потребители события не связаны тесно.
Канал обмена сообщениями, используемый для связи, обеспечивает независимость обоих его концов и, следовательно, обеспечивает их слабую связь. Производитель не ждет ответа от потребителя. При этом потребитель не падает из-за отсутствия производителя.
В целом, управляемая событиями архитектура помогает повысить надежность, масштабируемость и пропускную способность всей системы.
У микросервисов, управляемых событиями, действительно есть определенные проблемы, о которых разработчики должны помнить, чтобы создать стабильную систему. Из-за асинхронного характера связи требуются дополнительные усилия для корреляции всех действий, выполняемых от начала до конца для одного события.
Разработчикам необходимо позаботиться об обработке потерянных сообщений из-за сбоев канала сообщений. Необходимо дополнительно учитывать обработку рассинхронизированных сообщений, частичную доставку сообщений и возврат состояния данных из-за непредвиденных обстоятельств.
Доступность важнее согласованности
Один вопрос, на который должен ответить каждый дизайн микросервиса, - это иметь правильные данные или иметь данные прямо сейчас. На него нет правильного ответа. Стратегия зависит от того, с какими данными работает служба и как их доступность влияет на поведение пользователя.
Вы можете подробно прочитать о теме возможной согласованности в статье Пэта Хелланда Следите за своим состоянием для своего состояния ума.
Большинство современных приложений электронной коммерции предпочитают, чтобы их страницы загружались быстрее, даже если у них могут быть неточные данные. Исследования показывают, что пользователи уходят с сайта, если корзина, товары или обзоры загружаются недостаточно быстро.
При разработке приложения на основе микросервисов вам необходимо определить приоритет между доступностью и согласованностью.
Показывать товар пользователю - это нормально, даже если его нет в наличии. Пользователи могут добавить его в корзину, а вторая проверка во время оформления заказа может сообщить о наличии продукта. Это важно для сайтов, чтобы удерживать клиентов.
Компании не хотят, чтобы пользователи переходили на другой сайт, пока их страница загружается медленно; потому что приложение намеревается проверить запасы в инвентаре и других тележках, чтобы дать точный статус наличия продукта. Это означает, что в данном случае доступность данных более важна, чем их точность.
В то же время существуют приложения, используемые для медицинских данных пациента или используемые на атомных электростанциях, которые не могут позволить себе роскошь конечной согласованности. Данные должны быть точными и согласованными, даже если это снижает производительность.
Следовательно, при разработке приложения на основе микросервисов вам необходимо определить приоритет между доступностью и согласованностью.
Репликация сообщений через архитектуру, управляемую событиями, как правило, обеспечивает согласованность в конечном итоге. Могут быть задержки из-за невыполненных очередей или из-за медленной обработки потребителя. Но данные в конечном итоге обрабатываются клиентским приложением и становятся согласованными с исходными данными.
Однако чтение непосредственно из исходной системы через API-интерфейсы является предпочтительным вариантом для приложений, которым требуются неизменно точные данные.
Слабая связь
Часто сервисам необходимо взаимодействовать друг с другом для выполнения всего рабочего процесса. Таким образом, они могут стать прочно связанными. Сильно связанная система затрудняет внесение изменений в одну службу, не влияя на другие службы.
Кроме того, в сильно связанных сервисах существует вероятность большого радиуса взрыва при выходе из строя одного из сервисов в цепочке. Это делает надежность всей системы менее предсказуемой.
Когда дело доходит до сервисных интерфейсов, рекомендуется держать их как можно слабее связанными с внутренними компонентами сервиса. Независимость контракта на интерфейс от бизнес-логики или технологий поможет командам со временем развиваться, не требуя изменений на стороне потребителя сервиса.
Чтобы сделать сервисы слабосвязанными, вы можете следовать модели издатель-подписчик. В этой модели источник и потребители отделены друг от друга через канал обмена сообщениями. Таким образом, простой одного из приложений не влияет на другие приложения в экосистеме.
Кроме того, на потребителей не влияет изменение внутренней логики производителя, если формат сообщения и определение не меняются.
Шлюзы API также могут помочь сохранить слабую связь между сервисами. Он предоставляет промежуточный компонент, который может обрабатывать необходимые переводы между поставщиками услуг и их потребителями.
Шлюзы могут обрабатывать мосты протоколов, преобразование формата сообщений, маршрутизацию и т. Д., Поэтому потребителям и поставщикам не нужно придерживаться одного определения. Он также абстрагирует от потребителей любые изменения на уровне обслуживания. Это, в свою очередь, помогает сущностям оставаться слабосвязанными.
В примерах как издатель-подписчик, так и шлюза API мы можем изменять или добавлять новые объекты (издатель / клиентское приложение, подписчик / услуга) без каких-либо изменений, требуемых для остальных объектов в экосистеме.
Единая ответственность
Принцип единой ответственности в SOLID предполагает высокую согласованность функций класса. Идея состоит в том, чтобы сделать класс ответственным за одно и только за одно. Альтернативный способ SRP можно определить так: у класса должна быть только одна причина для изменения.
При разработке наших классов мы должны стремиться объединить связанные функции, чтобы всякий раз, когда они меняются, они менялись по той же причине. И мы должны попытаться разделить функции, если они будут меняться по разным причинам. - Стив Фентон
Это, в свою очередь, помогает писать простой для понимания код, который отличается высокой степенью согласованности и легче развиваться с изменениями бизнес-требований.
Распространяя SRP SOLID на микросервисы, вы должны стремиться к тому, чтобы микросервис выполнял только одну функцию. Если вы планируете объединить несколько микросервисов вместе в одно развертывание, все они должны работать в одной области с относительно одинаковым циклом изменений.
В то же время вы можете не захотеть определять свои микросервисы на слишком детальном уровне. Если функция требует, чтобы другие функции изменялись вместе почти все время, их разделение увеличит нагрузку на обслуживание без особого преимущества.
Ось изменения - это только ось изменения, если изменения действительно происходят. Нецелесообразно применять SRP или какой-либо другой принцип в этом отношении, если нет симптома. - SRP: принцип единой ответственности
Таким образом, распределенные приложения уже требуют более тщательного обслуживания, чем монолиты. Командам будет сложно ограничить взаимозависимость с помощью слишком детализированных сервисов, что приведет к кошмару обслуживания.
Вы можете прочитать эту статью, чтобы узнать больше о том, как точно определить свои микросервисы.
Последние мысли
Каждый из рассмотренных выше принципов проектирования имеет свои компромиссы, как и любое дизайнерское решение, которое мы принимаем при разработке программного обеспечения. Следовательно, ему не следует слепо следовать.
Поскольку приложения на основе микросервисов постоянно находятся в стадии разработки, вы можете использовать свой собственный опыт, потребности вашей компании и шесть вышеперечисленных принципов в своих проектных решениях, чтобы помочь вам создать надежную архитектуру микросервисов.
Я хотел бы услышать о вашем опыте разработки приложений на основе микросервисов. Пожалуйста, не стесняйтесь делиться своими отзывами, предложениями или мнениями в комментариях.
Ссылки:
- Https://www.infoq.com/articles/microservices-design-ideals/
- Https://www.avenga.com/magazine/microservice-architecture/
Спасибо, что прочитали статью. Вы также можете прочитать:
