В этом посте я рассмотрю видео на YouTube Дэвида Шмитца из Anti-Patterns и советов, чтобы победить микросервисы.
10) Перейти полномасштабный полиглот
Одним из преимуществ использования микросервисов является то, что вы можете использовать разные языки программирования в разных службах. Эта свобода выбора может подвергаться ненадлежащему использованию нескольких технологий. Существует фраза «инженерная инженерия CV», которая используется, когда разработчики используют рамки и инструменты, потому что она будет хорошо выглядеть на их резюме. Никто не сможет поддержать весь код, и клиенты будут хуже для него.
9) Данные монолит
Следующий анти-паттерн является общей базой данных. Вы можете поделиться кластером базы данных с общей изоляцией таблиц. Здесь вызывает обмен данными через базу данных. Если вы зайдете в другие таблицы микросервисов, и они меняют свои таблицы, все взорвется. Несколько десятилетий назад на первой платформе, где я был технологическим лидером, заключалась в том, чтобы иметь одну общую базу данных со многими командами, которые писали микро-фронтенции. Единственная служба входа означала, что мы могли бы связать между приложениями, и пользователь имел иллюзию одной большой услуги, но каждая область системы была построена разными командами. Там, где техническая стратегия была глубоко ошибочной, заключалась в том, что команды должны были обмениваться данными с помощью хранимых Procs. Базы данных не предназначены для того, чтобы выступать в качестве API для инкапсулированной бизнес -логики. По сути, команды только что предоставили другим командам доступ к Procs, которые использовали их собственное приложение. Это похоже на запрос таблиц друг друга. 💩 💥 💀
8) Событие монолит
Существует популярный шаблон поиска событий, и его логическая крайность известна как шаблон «база данных изнутри», который набирает популярность в мире Кафки. Видео Дэвида объясняет, что, если вы не заботитесь о разоблачении событий между командами, дает вам высокую связь и может привести к исправлению копирования и вставки и улучшения, добавляемых в каждый сервис. На очень высоком уровне вы можете получить те же проблемы, что и обмен таблицами баз данных. Добавление записей в журнал общих событий подобен добавлению строк к общей таблице баз данных. Ни одна команда не должна подвергнуть потока событий другой команде, не являясь контрактом, который они будут поддерживать строгие правила обратной совместимости так же, как и с любым API микросервисов. AVRO может быть использован для добавления атрибутов таким образом, чтобы не разбивать старые процессы, читающие новые события. Обновление данных или исправление ошибок, связанных с данными, требует тщательного планирования и практики, или у вас будет монолитная головная боль.
7) Доморощенный монолит
Очевидно, что что -то новое, столь же крутое, как микросервисы, требует, чтобы вы отправились и писали свою собственную структуру. В конце концов, вы один из самых умных людей вокруг, и если Google может сделать это, то вы можете. Тем не менее, очень трудно избежать события изменения мира, когда вы пишете свою собственную структуру во время писать свое приложение. Доморощенная структура — это монолитная сила, а также незрелая и отвлекающаяся от добавления бизнес -функций.
6) Используйте мясное облако
Дэвид специально выбирает здесь крупные организации финансовых услуг. «Мясное облако» использует много людей в команде OPS, а не автоматизации самообслуживания. Как правило, команды, занимающиеся микросервисами, имеют непрерывную интеграцию и непрерывную конвейер развертывания для кода приложения. Тем не менее, крупные фирмы считают, что оптимально иметь отдельные команды, которые управляют всей инфраструктурой, нуждающейся в билете поддержки, чтобы внести какие -либо изменения. Поскольку у них есть люди, сидящие, ожидающие работы, они нажимают вручную, чтобы настроить вещи, а не автоматизировать что -либо. Чтобы люди не преодолели дорогие общие инструменты, они заблокируют их, чтобы сделать только то, что, как они ожидали, вам нужно сделать. Опытный человек, который настроил его, не будет рядом, чтобы на самом деле управлять магазином. У вас есть кто-то без большой картины, который щелкнет мышью повседневную жизнь. Это отделяет, кто хочет, чтобы что -то было сделано, от людей, которые знают, как это можно сделать, от людей, у которых есть привилегии для этого, от людей, у которых есть время, чтобы сделать это. Так что ничего не делается.
5) Распределенный монолит
Анти-паттерн здесь состоит в том, чтобы построить приложение, как будто это монолит, но развернуть его столько же микросервисов. Это объединяется, чтобы дать вам худшее из обоих миров. В среде микросервисов сбои встречаются чаще, чем в монолитной среде для того же уровня качества кода приложения. Это связано с тем, что сети не являются идеальными и из -за математики совокупных вероятностей. Если у вас есть проблема, когда только 1 из 365 запросов терпит неудачу в монолите, которая является достаточно плохой проблемой. Если вы используете микросервисы, где для создания страницы требуется 23 вызовов между сервисными услугами, то сбой 1 в 365 запросов, означает, что 50% страниц клиентов потерпят неудачу. Сеть не надежна. Вот пост о реальных отключениях мира, показывающих, что надежность сети является ошибкой. Сервисная сетка может помочь, но сама по себе является сложной распределенной системой, которая потребует усилий для настройки и запуска.
4) Приложение для одной страницы (SPA) Монолит
Это еще один скрытый монолитный анти-паттерн. Проблема в том, что ваше приложение для одной страницы может стать монолитом. У этого есть все проблемы традиционного монолита с дополнительным поворотом, который работает во многих различных браузерах. Дэвид отмечает, что легко просто вставить новую логику в передний день, когда ваши требования внезапно меняются, но это удобство-это путь к большому применению грязи. Такие подходы, как React.lazy, применяемый для реагирования маршрутов с расщеплением кода, может позволить вам создать модульная архитектура Для вашего фронта, чтобы избежать этой ловушки. Такие продвинутые методы выходят далеко за рамки оснований и потребуют усилий для настройки, и они будут проблемой для модернизации быстро растущей кодовой базы.
3) Решение монолит
Мы все можем взять раскопать архитекторов, которые ограничивают использование новых технологий и которые запретили J2EE в качестве решения для всего. Тем не менее, трудно не сказать «нет» новым идеям в интересах снижения рисков. Мы должны убедиться, что у нас нет догматического и негибкого подхода и создавать способы экспериментов и постоянно вводить новые инновации.
2) Монолитный бизнес
Микросервисы не могут быть только технологией. Если у нас есть монолитные процессы, то мы действительно замаскируем водопад. Это также известно как «wagile», «водный флаг», «Dark Agile», «Faux Agile» и множество других имен. Помимо того, как работает процесс, мы также должны вызывать монолитные отношения и подходы за пределами технологий с точки зрения вовлечения бизнеса. Суть гибких и микросервисов заключается в том, что мы немного выпускаем и часто получают ценную обратную связь. Если между бизнес -пользователем нет реальной обратной связи между бизнес -пользователем и тем, что мы строим, мы не оптимизируем ценность бизнеса.
1) Используйте архитектуру микросервисов, управляемой HR
Примечательная цитата здесь:
» Проще искать разработчиков React, чем для общих мастеров ».
В основном это говорит о том, что если ваша практика найма сосредоточена на специализациях, вы де-оптимизируете свою способность создавать, развертывать и поддерживать микросервисы. Это также известная плохая практика для организации команд в специалисты. Вам необходимо организовать небольшие смешанные дисциплинированные команды, которые уполномочены проектировать, создавать, развернуть и поддерживать то, что они создают в максимально возможной модели самообслуживания. Тем не менее, когда я разговариваю с разработчиками, я часто удивляюсь тому, как они самостоятельно идентифицируют себя как в данном специализе, такой как «Я разработчик Java» или «Я разработчик React». Это просто увековечивает бункеры и позволяет организациям устроить вас в силос и лишить вас, утверждая, что это делает вас счастливыми. Назовите себя инженером -программистом и будьте интеллектуально любопытными относительно того, как все работает. Инфраструктура и сети в облаке определены программным обеспечением и имеют API, который вы можете использовать. Стремитесь стать создателем вещей, а не обладателем определенных навыков.
Это все люди. Было бы здорово услышать о вашем опыте того, что работает, а что нет.
Оригинал: «https://dev.to/simbo1905/microservces-anti-patterns-and-ten-tips-to-fail-badly-2le»