Если вы не жили под камнем в течение последних нескольких лет, вы, несомненно, услышали о чудесах микросервисов. Это подход к созданию и доставке программного обеспечения, который был принят такими технологическими гигантами, как Netflix и Uber, и теперь оно попало в корпоративное программное обеспечение.
Архитектуры микросервиса имеют много преимуществ, и развязка ваших приложений в более мелкие компоненты, как правило, отличная идея. Однако для каждого преимущества, которое имеет внедрение микросервисов, существуют условия, которые должны быть выполнены, прежде чем пожинать вознаграждения.
В этом посте я выровняю мелкий шрифт некоторых преимуществ, предлагаемых архитектурой микросервисов, и почему большое количество организаций не видят преимущества, обещанные им спикерами и дорогими консультантами.
Большая терпимость разлома
Микросервисы по своей природе не терпимы.
Одним из наиболее часто показных аргументов для микросервисов является то, что ваше приложение будет более устойчивым к ошибкам, чем монолитная альтернатива. Идея, лежащая в основе этого, заключается в том, что один компонент сбоя приложения не будет снижать все приложение, поскольку они работают как отдельные процессы, что действительно верно.
Однако, если вы не построили свои приложения с учетом устойчивости к ошибкам, вы просто увеличиваете свои точки отказа от одного до exp (n) , где n это количество микросервисов, которое у вас есть. Когда вы принимаете микросервисы, вы также принимаете проблемы, связанные с распределенными вычислениями, и невежество этих проблем является верным образом огненного способа сделать ваше приложение более хрупким, чем когда -либо.
Более низкая когнитивная нагрузка
Это выходит из окна, если вы отвечаете за несколько сервисов.
Возможность сосредоточиться на одной части домена приложения означает, что новые члены команды могут стать продуктивными гораздо быстрее, чем в монолитном применении. Однако очень важно отметить, что микросервисы являются такими же организационным образцом, как и архитектурными.
Если ваша команда несет ответственность за каждую услугу в приложении, адаптация нового члена команды намного медленнее, чем на монолите. Наличие нового сотрудника пытается получить 10 микросервисов и услуги поддержки на их машине, просто жестоко, даже с Docker. И не заводите меня, если микросервисы написаны на разных языках.
Развернуть чаще
Непрерывная доставка требует намного больше, чем микросервисы, чтобы добиться успеха.
Мы все слышали истории о сотнях развертываний производства в день в крупных технологических компаниях. Это должно быть Best Practice ™ Если Uber и Netflix делают это. Возможность развертывания в производстве несколько раз в день останавливает нас, разработчикам, приходится быть в офисе к 6 утра для классических развертываний «Большой взрыв», поэтому я, естественно, большой поклонник этого.
Тем не менее, вы можете доставить программное обеспечение только так быстро, как позволяет ваша организация. Чтобы достичь Святого Грааля с непрерывной доставкой, вам нужен организационный бай-ин, а многие менеджеры OPS очень не хотят отпускать процессы управления изменениями. Есть несколько довольно больших книг, посвященных этой теме, так что это никогда не будет таким простым, как «Мы просто сделаем микросервисы» Анкет
Безопасное развертывание
Код багги сломает производство независимо от того, сколько частей он разделен.
Я упомянул развертывание «Big Bang», где все приложение с автонта скинуло на определенное время, когда приложение обновляется, и, возможно, запускаются миграции базы данных. В этих ситуациях есть много, чем (и часто) ошибается в этих ситуациях, поэтому развертывание только одного услуги означало бы, что вы уменьшаете количество вещей, чем могут пойти не так.
Если вы не развертываете код качества, у вас не будет более безопасного развертывания независимо от вашей архитектуры. Я понимаю, что качественный это очень загруженный термин, но я имею в виду качество в самых простых формах в том, что он делает то, что он должен делать. Вы проверяете, что код делает то, что он должен делать, тестируя код. Чтобы сделать это таким образом, чтобы предотвратить плохое развертывание, вам необходимо инвестировать в автоматическое тестирование и в идеале интегрировать это в ваши трубопроводы.
Вывод
Чтение этого может создать впечатление, что мне не нравятся микросервисы, но это просто не так. Я думаю, что микросервисы — это фантастический способ создания программного обеспечения, и многие команды добились невероятных успехов, приняв их.
Однако важно отметить, что они не являются серебряной пулей для всех наших проблем. Внедрение микросервисов требует гораздо большего, чем просто разделение вашего приложения на API: для этого требуется организационный сдвиг, и решения для проблем, не требуемых в монолитном приложении.
Оригинал: «https://dev.to/carltonupp/microservices-the-fine-print-4ili»