Комментарии 16
Cоблюдается ли правило один мс — одна таблица в бд (модель)?
Никогда не слышал о таком правиле. У нас есть другое правило — у каждого сервиса своя БД в которую можно достучаться только через API. И в этой БД может быть столько таблиц, сколько необходимо для реализации функционала сервиса.
Как общаются мс между собой?
Вызовы по API и Event Bus
Есть ли разница в общении между мс, написанными на одном языке и мс, написанными на разных?
По сути нет — мы выпускаем клиентов под наши основные языки. Взаимодействия через общие принципы работы шины или REST API
Дублируются ли мс для распределения нагрузки?
Если я правильно понял вопрос — да, мы запускаем несколько инстансев сервиса
Как решается вопрос функциональных зависимостей?
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
Сколько слоев из (микро)сервисов получется на данный момент?
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
Как решается вопрос функциональных зависимостей?
Смотря какой вопрос… Расскажите, что имелось в виду, плз
Сколько слоев из (микро)сервисов получется на данный момент?
Пока уровень вложенности меньше 10
Какова стоимость развертывания и управления зависимостями по сравнению с обычными сервисами?
А что считать обычными сервисами? Любому сервису нужен сетевой доступ, роутинг, мониторинг, доступы к БД… У нас сейчас многие из этих задач на себя берет k8s и PaaS, поэтому на мой взгляд сейчас у нас выходит дешевле и безопаснее — многие риски закрывает сам PaaS и прикладной инструментарий ему сопутствующий
При восходящей разработке (аджайлы — это bottom-up), функции добавляются инкрементально. После десятков итераций получается каша из взаимозависимостей, по-хорошему требующая работы предметных аналитиков по реструктуризации. Хотя, конечно, всегда есть опция «оставить как есть и жить с этим».
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
Т.е. по сути у вас 10-звенная система. Неужели нигде «не жмёт туфля» в плане производительности?
Обычные сервисы реализуют не строго одну «автономную» функцию (см.выше про кашу), а несколько тесно связанных (интегрированных), тем самым избавляя их от необходимости медленно взаимодействовать по сети.
При восходящей разработке (аджайлы — это bottom-up), функции добавляются инкрементально. После десятков итераций получается каша из взаимозависимостей, по-хорошему требующая работы предметных аналитиков по реструктуризации. Хотя, конечно, всегда есть опция «оставить как есть и жить с этим».
Рефакторинг и работу над техническим долгом никто не отменял
Речь не про технический долг, а про функциональный (надеюсь, вы не будете отрицать, что техническая и функциональная архитектуры суть разные вещи). Чтобы распутать кашу функциональных зависимостей нужно заняться проектированием этой самой архитектуры. «Чистый» код в общем случае инвариантен «грязной» прикладной логике. Более того, «чистая» функциональность сэкономит вам тонны часов на технический рефакторинг.
Поддержу предыдущих ораторов. Есть пост про микросервисы, но в нём всё о низкоуровнево-инфраструктурыных нюансах в районе ДевОпс и чуть выше.
Что за сервисы и как поделены — ничего про это нету.
Что за сервисы и как поделены — ничего про это нету.
Что за сервисы и как поделены — ничего про это нету.
Тут вопрос знания нашей специфики и предметной области. Вряд ли Вам что-то даст описание наших сервисов. Но если есть конкретные вопросы — спрашивайте, постараюсь ответить.
Рассказать про вашу специфику и как она мапится в конкретные сервисы, их API взаимодействие, что откуда куда идёт. Про специфику рассказать достаточно, чтобы была понятна реализация.
Давайте я поясню на примере. Допустим счас 1992-й год, вы пишете про то как перейти с хранения данных в текстовых файлах, на реляционные БД.
И вот вы рассказываете про то как деплоите SQL БД, сколько оно жрёт памяти, как вы делаете бэкапы. Про данные ничего не говорите. А ведь это самое главное!
Аудитории не понятно, как можно данные из текстовых файлов разместить в SQL таблицах. Вернее вроде вот есть же мануал, где рассказано что у таблицы есть поля и вроде всё понятно, но как спроектировать большую систему на SQL — не понятно.
Вот я и предлагаю описать вашу предметную обласить, и расписать как она мапится в таблицы, поля, БД, связи, запросы.
Возвращаясь от аналогии к реальности — предлагаю расписать сервисы, их API, ключевые методы вызовов в API, связи.
Зачем всё это? Потому что правильное разделение сущностей на сервисы — вопрос сложный и интересный, где нет одназначных ответов.
Давайте я поясню на примере. Допустим счас 1992-й год, вы пишете про то как перейти с хранения данных в текстовых файлах, на реляционные БД.
И вот вы рассказываете про то как деплоите SQL БД, сколько оно жрёт памяти, как вы делаете бэкапы. Про данные ничего не говорите. А ведь это самое главное!
Аудитории не понятно, как можно данные из текстовых файлов разместить в SQL таблицах. Вернее вроде вот есть же мануал, где рассказано что у таблицы есть поля и вроде всё понятно, но как спроектировать большую систему на SQL — не понятно.
Вот я и предлагаю описать вашу предметную обласить, и расписать как она мапится в таблицы, поля, БД, связи, запросы.
Возвращаясь от аналогии к реальности — предлагаю расписать сервисы, их API, ключевые методы вызовов в API, связи.
Зачем всё это? Потому что правильное разделение сущностей на сервисы — вопрос сложный и интересный, где нет одназначных ответов.
Спасибо за статью. Интересно было бы почитать как у вас реализованы бизнес фичи, меняющие данные в нескольких сервисах. Саги? Event sourcing? Другое? Все это можно ещё и реализовать по-разному. :)
Собственно оба варианта: саги и события в общей шине — зависит от требований синхронности и консистентности данных.
Можно еще тут посмотреть:
habr.com/ru/company/avito/blog/418235
habr.com/ru/company/avito/blog/418235
Спасибо! Очень интересная и полезная статья!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что мы знаем о микросервисах