Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эволюционное проектирование закладывает основу для непрерывных инноваций
Все успешные приложения изменяются с течением времени: в них исправляются ошибки, добавляются компоненты, изменяются технологии, применяются меры для повышения масштабируемости и гибкости. Если все части приложения очень тесно связаны, в такую систему сложно вносить изменения. Изменение в одной части приложения может вызвать сбой в другой части или потребовать изменений во всей базе кода.
Такая проблема характерна не только для монолитных приложений. Даже если приложение разложено на несколько служб, в нем могут существовать такие жесткие взаимозависимости, которые делают систему жесткой и хрупкой. Но когда службы проектируются с учетом будущих изменений, команды могут смелее и чаще разрабатывать и внедрять новые функции.
Микрослужбы становятся популярными при эволюционной разработке, так как этот подход учитывает многие из упомянутых здесь аспектов.
Рекомендации
Обеспечьте высокую слаженность и слабую взаимозависимость. Служба считается слаженной, если ее функциональные возможности логически связаны друг с другом. При слабой взаимозависимости служб можно изменить одну из них, не затрагивая другую. Высокий уровень согласованности обычно означает, что изменения в одной функции потребуют изменений в других связанных функциях, где все связанные функции находятся в одной службе. Если вы обнаружите, что обновление службы требует скоординированных обновлений в других службах, это повод усомниться в слаженности функций. Одна из задач разработки на основе домена (DDD) — выявление таких границ.
Инкапсулируйте знания о предметной области Недопустимо перекладывать ответственность за соблюдение бизнес-правил предметной области на клиента, который использует службу. Вместо этого следует внедрять в службу все знания о предметной области, которые входят в ее область действия. Иначе каждый клиент должен следить за соблюдением бизнес-правил, и конечным результатом будет распределение доменных знаний по различным частям приложения.
Используйте асинхронный обмен сообщениями. Асинхронный обмен сообщениями помогает устранить зависимость поставщика сообщений от их получателя. Поставщик не обязан ожидать, пока получатель ответит на сообщение или выполнит какие-то действия. Архитектура на основе публикации и подписки может позволить производителю даже не знать, кто потребляет сообщения. Новые сервисы могут легко считывать сообщения без каких-либо изменений для производителя.
Не внедряйте знания о предметной области в шлюз. В архитектуре микрослужб шлюзы выполняют много важных функций, таких как маршрутизация запросов, преобразование протоколов, балансировка нагрузки и аутентификация. Но функции шлюза следует строго ограничить только инфраструктурными задачами такого типа. Он не должен содержать никаких знаний о предметной области, чтобы не стать очень опасной зависимостью.
Предоставьте открытые интерфейсы. Старайтесь не создавать пользовательские слои перевода, находящиеся между службами. Вместо этого служба должна предоставить API с четко определенным контрактом API. Важно версионировать API, чтобы развивать его с сохранением обратной совместимости. Это позволит вам обновить одну службу, не управляя обновлениями всех вышестоящих служб, которые от нее зависят. Общедоступные службы должны предоставлять интерфейс API RESTful по протоколу HTTP. Для серверных служб допустимо использовать протокол обмена сообщениями в стиле RPC для повышения производительности.
Проектируйте и тестируйте в соответствии с контрактами на обслуживание. Если службы предоставляют четко определенные API-интерфейсы, вы можете использовать эти API-интерфейсы для разработки и тестирования. Это позволяет создавать и тестировать каждую службу отдельно, не затрагивая все зависимые службы. (Но, разумеется, вы все равно будете проводить интеграционное и нагрузочное тестирование на реальных сервисах.)
Используйте функции фитнеса. Функции фитнеса измеряют результат, чтобы узнать, ближе или дальше от оптимального решения. Функции фитнеса помогают защитить архитектурные характеристики по мере изменения с течением времени. Фитнес-функция — это любой механизм, обеспечивающий целевую оценку целостности характеристик архитектуры. Оценка может включать различные механизмы, такие как метрики, модульные тесты, инженерия хаоса и т. д. Например, архитектор может определить время загрузки страницы как важную характеристику. Впоследствии рабочая нагрузка должна иметь оценочную функцию для проверки времени загрузки страницы и запускать тест в рамках непрерывной интеграции.
Абстрагируйте инфраструктуру от логики предметной области. Не смешивайте логику предметной области с инфраструктурными функциями, такими как обмен сообщениями или сохраняемость. В противном случае изменения логики предметной области повлекут за собой изменения на уровне инфраструктуры, и наоборот.
Разгружайте сквозные функции в отдельную службу. Например, если несколько разных служб используют запросы аутентификации, эту функциональность можно вынести в дополнительную службу. Затем вы можете развивать службу проверки подлинности , например, добавив новый поток проверки подлинности, не касаясь каких-либо служб, которые его используют.
Развертывайте службы независимо друг от друга. Если команда DevOps может развернуть одну службу отдельно от остальных служб в приложении, обновления выполняются быстрее и безопаснее. Вы сможете чаще развертывать исправления ошибок и новые функции. И само приложение, и процесс выпуска должны поддерживать независимые обновления.