Привет всем.
Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут.
Первое что хотел сказать, что везде пишут микросервисы это где много команд часто или много функционала. В этом проекте ни того ни другого не будет,
но зато скоп определен четко и подумал прекрасная возможность потренироваться, чтобы потом уверенее пробовать в большом проекте.
Тут я понимаю, что проще было бы сделать монолит, но для обучения вполне годный вариант?
Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?
Приложение: — Система контроля доставок грузов в разных странах (стран 10).
— Юзеры заходят по user/pswd и система определяет страну и подгружает данные этой страны. Новый юзер сам может зарегаться по логину выданному ему и восстановить пароль.
— В системе будет 4 роли: sysadmin, admin, manager, driver. В каждой стране свои пользователи. Один пользователь = 1 страна.
— Сами заказы поступают в эту систему из другой. В этой надо только мониторить и делать разные действия если доставка задержалась или не приехала.
— В каждой стране много складов и поэтому когда заказы поступают в систему то они сразу попадают на нужный склад и спец алгоритм распределяет на водителей.
— sysadmin управляет только техническими настройками разными (кому когда отчеты отсылать, как в системе заводить оптуска, сколько часов в сутки можно работать, заводит праздники), остальное всё только в режиме просмотра видит.
— admin видит всё, не может только технические настройки менять. Следит за водителями, чтобы они всрок доставляли всё — по юаю специальному, вносит отпуска, больничные их, ставит им рабочее время. Если водитель увольняется — удаляет изи системы.
— manager следит за водителями своего склада только, может посмотреть по всем своим водителям информацию и по всем доставкам, но менять не может
— driver видит только по себе все сделанные доставки и предстоящие. Каждый раз когда он начинает и заканчивает доставку то в системе нажимает Start delivery\End delivery. Если доставка не укладывается в
предполагаемые сроки то пишет к доставке комментарий почему не успел
Итого что по функционалу:
Sysadmin — логин в систему, управление настройками, праздниками и просмотр всего.
Admin — логин в систему, cледит за водителями, чтобы они всрок доставляли всё, вносит отпуска, больничные их, ставит им рабочее время. Если водитель увольняется — удаляет изи системы.
Manager логин в систему, следит за водителями своего склада только, может посмотреть по всем своим водителям информацию и по всем доставкам
Driver логин в систему, видит только по себе все сделанные доставки и предстоящие. Каждый раз когда он начинает и заканчивает доставку то в системе нажимает Start delivery\End delivery. Если доставка не укладывается в
предполагаемые сроки то пишет к доставке комментарий почему не успел
Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.
Здравствуйте, busk, Вы писали:
B>Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут.
Не надо, оно тебя сожрет
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, busk, Вы писали:
B>>Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут. G>Не надо, оно тебя сожрет
поясни пожалуйста подробней. а то смотришь тот же Яндекс, у них везде микросервисы + ci/cd
Выглядит так, что тут вкореживать (именно так) микросервисы – дороже выйдет. Ну вообще никак они тут не просматриваются. Очень маленький набор сущностей и функционала. Элементарно нечего пилить
Опять же, если это все без кубера делать, то жди беды и геморроя Так что не стоит
Потренироваться можно на пет-проекте. Самому придумать и написать что-то несложное. Один микросервис отдает погоду, второй загруженность дорог. Третий все это забирает и что-то отдает наружу. Плюс отдельный микросервис принимают от пользователей какие-то данные. Тут же добавить кэши, обратный прокси. можно потом с лоад балансером поиграться. Каждый сервис пусть по базе имеет. Сделать несколько инстансов каждого микросервиса. Ну и так далее...
Тогда может и будет понимание, где надо (и зачем!), а где не надо впихивать микросервисы. Ну и про кубер придет понимание, что этим зоопарком баз и сервисов как-то надо рулить. И как замечательно можно скейлить отдельные куски системы по необходимости
Здравствуйте, busk, Вы писали:
B>Тут я понимаю, что проще было бы сделать монолит, но для обучения вполне годный вариант?
А у вас ресурсы-то на микросервисы есть? На тот же K8S и CI/CD хотя бы.
B>Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?
Это самое простое. Делить нужно по бизнес-домену (мыши и кактусы отдельно, марксизм и диамат отдельно), по технологиям (ML на питоне, интеграция с внешними сервисами на Scala, интерфейс к БД на сишарпе), требованиям к масштабированию (фронтофисом пользуется вся страна, а бэкофисом 20 человек), надежности (если отчеты упадут об этом узнают через месяц, а если торговый робот упадет, компания обанкротится за 5 минут). Если ничего этого нет, микросервисы не нужны.
B>Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.
Можно, только это очень дорого и даже Яндекс себе такого не может позволить.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, busk, Вы писали:
B>>Тут я понимаю, что проще было бы сделать монолит, но для обучения вполне годный вариант?
M>А у вас ресурсы-то на микросервисы есть? На тот же K8S и CI/CD хотя бы.
я планировал без кубера, читал так можно. Ниже написал модель какую думал. ci/cd у нас есть на другом сервере и думал туда добавить билд нового проекта.
а кубер реально много ресурсов требует дополнительно? я думал он просто как failover service
B>>Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?
M>Это самое простое. Делить нужно по бизнес-домену (мыши и кактусы отдельно, марксизм и диамат отдельно), по технологиям (ML на питоне, интеграция с внешними сервисами на Scala, интерфейс к БД на сишарпе), требованиям к масштабированию (фронтофисом пользуется вся страна, а бэкофисом 20 человек), надежности (если отчеты упадут об этом узнают через месяц, а если торговый робот упадет, компания обанкротится за 5 минут). Если ничего этого нет, микросервисы не нужны.
а вот кстати будет порядка 3 сервисов на питоне интеграционных с другими системами, которые в теории могут попросить вызывать для онлайности данных с сайта этого.
Но я так понял что поддержка и настройка микросервисов дело хлопотное и надо делать в кубере, а если без опыта то времени на изучение и настройку уйдет с неделю точно.
B>>Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.
M>Можно, только это очень дорого и даже Яндекс себе такого не может позволить.
а почему дорого? я так понял просто каждый сервис — отдельный апп в веб сервере и есть шлюз приложение которое регулирует и каждая база на свой сервис.
Здравствуйте, DiPaolo, Вы писали:
DP>Выглядит так, что тут вкореживать (именно так) микросервисы – дороже выйдет. Ну вообще никак они тут не просматриваются. Очень маленький набор сущностей и функционала. Элементарно нечего пилить
DP>Опять же, если это все без кубера делать, то жди беды и геморроя Так что не стоит
DP>Потренироваться можно на пет-проекте. Самому придумать и написать что-то несложное. Один микросервис отдает погоду, второй загруженность дорог. Третий все это забирает и что-то отдает наружу. Плюс отдельный микросервис принимают от пользователей какие-то данные. Тут же добавить кэши, обратный прокси. можно потом с лоад балансером поиграться. Каждый сервис пусть по базе имеет. Сделать несколько инстансов каждого микросервиса. Ну и так далее...
DP>Тогда может и будет понимание, где надо (и зачем!), а где не надо впихивать микросервисы. Ну и про кубер придет понимание, что этим зоопарком баз и сервисов как-то надо рулить. И как замечательно можно скейлить отдельные куски системы по необходимости
Понял, спасибо. Монолит тогда сделаю.
А так вот, чисто для развития и понимания в реальных приложениях, подскажи пожалуйста как тут нарезать сервисы?
дополнительно. Еще будет 3 сервиса на питоне: один будет из 1с качать информацию по отпускам, болничным, один будет также из 1с качать новых сотрудников.
я правильно понимаю: сервис аутенфикации, сервис получения заказов со статусами по дням, сервис настроек и сервис сотрудников (где можно им выставлять рабочее время, заводить отгулы, удалять их если они уволились)
B>А так вот, чисто для развития и понимания в реальных приложениях, подскажи пожалуйста как тут нарезать сервисы?
Да вот именно, что сложно их как-то нарезать. Как коллега правильно заметил, есть несколько вариантов нарезки, и ни один из них сюда не подходит.
Можно нарезать по сущностям, теоретически: сервис юзеров, сервис заказов и так далее. Но это скорее запутает и микросервисы покажутся злом
Именно тут я бы не стал делить. А для практики придумал другой сервис, где нарезка имеет больший смысл.
B>дополнительно. Еще будет 3 сервиса на питоне: один будет из 1с качать информацию по отпускам, болничным, один будет также из 1с качать новых сотрудников.
Все что с 1С лучше вынести в один сервис (адаптер для интеграции со сторонним сервисом). Тем самым вся логика работы с конкретной сторонней системой будет сосредоточена в одном месте и будет инкапсулировать все что касается работы с этим сервисом. А наружу давать уже обработанные данные в форматах и сущностях, с коротким работает ваша система.
B>я правильно понимаю: сервис аутенфикации, сервис получения заказов со статусами по дням, сервис настроек и сервис сотрудников (где можно им выставлять рабочее время, заводить отгулы, удалять их если они уволились)
Я бы сделал так:
— основной бэк (заказы, настройки, сотрудники)
— сервис аутентификации (в вашем случае это тоже лишнее — выносить в отдельный микросервис; но пусть, так часто делают, когда микросервисов много и/или есть SSO)
— сервис для работы с 1С
B>Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.
Что касается докера и кубера... это хорошая идея – начать без них. Тогда чуть позже придет понимание исходя из реальных потребностей, зачем один и второй нужен.
Сделать можно так: скрипт, который запускает все сервисы + СУБД должна быть запущена (ее проще всего поднять в докере как раз) и базы созданы.
При этом надо продумать: а как определять, что тот или иной сервис упал/недоступен?
Далее, если понадобится вторая машина, тут встанет тоже вопрос, как с этим управляться.
Ну и дальше будет постепенно приходить понимание, зачем кубер и прочее.
Кстати, кубер сразу не стоит брать. Достаточно будет привнести докеры, а потом Docker compose. Этого хватит. А уже потом – кубер.
Здравствуйте, DiPaolo, Вы писали:
B>>Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.
DP>Что касается докера и кубера... это хорошая идея – начать без них. Тогда чуть позже придет понимание исходя из реальных потребностей, зачем один и второй нужен.
а я кстати тут вот понял, что без кубера и докера у меня бы точно были проблемы. Читал, что вроде нормально это всё под линухом работает.
а у меня на проде венда + mssql.
За советы спасибо!
видимо, да, домашний проект надо под линукс + postrges
Здравствуйте, busk, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, busk, Вы писали:
B>>>Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут. G>>Не надо, оно тебя сожрет
B>поясни пожалуйста подробней. а то смотришь тот же Яндекс, у них везде микросервисы + ci/cd
1) Ты не яндекс, даже на 1% не яндекс, и никогда яндексом не станешь
2) яндекс на старте не был микросервисным
3) cd\cd без микросервисов работает лучше
ну вот да, книжку читал и пишут, что большие проекты часто вначале делают монолитом, когда еще не всё ясно и четко по логике и потом типа уже распиливают на микросервисы.
G>3) cd\cd без микросервисов работает лучше
звучит что микросервисы удел либо больших компаний либо крупных систем.
Здравствуйте, busk, Вы писали:
B>Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?
Они проходят по границам команды. Одна команда — один микросервис.
Здравствуйте, busk, Вы писали:
B>я планировал без кубера, читал так можно. Ниже написал модель какую думал. ci/cd у нас есть на другом сервере и думал туда добавить билд нового проекта.
Можно, но микросервисы плохо работают без полноценного CD. Релизить руками умаешься.
B>а кубер реально много ресурсов требует дополнительно? я думал он просто как failover service
Ресурсов в смысле админа, который умеет k8s поднять и способен его настроить. Там же не один k8s, а еще сбор логов, CD пайплайны, мониторинг и т.п.
B>Но я так понял что поддержка и настройка микросервисов дело хлопотное и надо делать в кубере, а если без опыта то времени на изучение и настройку уйдет с неделю точно.
Микросервисы позволяют пернести часть сложности из приложения в оркестрацию. Это сильно упрощает разработку, когда у тебя в сервисе меньше 10к строк и один разработчик. Нет ни мердж конфликтов, не нужно ни с кем договариваться, не нужна документация, планирование, архитектура. Выставляешь Restful API и проблема других сервисов как этим API воспользоваться. Если в проекте энфорсится RMM level 3 и стопроцентная обратная совместимость, можно делать проекты на 1000 человеко-лет с минимальным оверхедом. За это приходится расплачиваться необходимостью контроллировать сложность взаимодействия. Вплоть до экономических механизмов, когда каждая команда платит за ресурсы потребленные их микросервисами в облаке.
B>а почему дорого?
Потому что k8s и docker сейчас умеют даже студенты, а для рукопашного CD нужны крайне продвинутые админы, умеющего автоматизировать развертывание каким-нибудь Chef или Puppet. Даже когда Chef был на пике моды, таких были единицы.
B>я так понял просто каждый сервис — отдельный апп в веб сервере и есть шлюз приложение которое регулирует и каждая база на свой
сервис.
Тогда не получится ни масштабирования, ни rolling updates без даунтайма, ни надежности. Непонятно зачем тогда вообще микросервисы?
Здравствуйте, busk, Вы писали:
B>Привет всем. B>Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут.
Я потренировался бы сначала, прежде чем делать реальный проект на микросервисах или в крайнем случае вывел бы в сервисы какую ни будь не критичную часть функционала, типа хранения разных типов уведомлений для пользователей.
B>самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?
Это как раз самое простое. Границы определяются orgchart — "организационной диаграммой". Иными словами, разделением ответственности по принципу "если это делает другая команда, это другой сервис".
Все остальные разделения рано или поздно скатятся во все ту же диаграмму подчинения.
PS: не видел еще ни одного продукта с микросервисной архитектурой который бы не скатился именно в этот принцип разделения. Во многих случаях разделение идет дальше (вплоть до того, что каждому программисту — по микросервису, а то и два-три), но в этом случае нередок обратный процесс помещения нескольких микросервисов внутрь единого огромного бинарника (привет фейсбуку).
Даже подразумевая, что всё это делается лишь для тренировки/обучения и не более —
больше, чем на две базы данных описанное разделить крайне трудно. Получается 1) аутентификация и авторизация 2) всё остальное.
Тем более, сервис аутентификации и авторизации вполне логично сделать централизованным (общим на весь корпоративный зоопарк приложений).
А сервисов больше, чем баз делать может иметь смысл только когда их реально делают разные команды (я не про экземпляры одинаковых).
Думаю, и 2 сервисов должно вполне хватить для отработки основных навыков.
Здравствуйте, busk, Вы писали:
B>Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут.
Если это реальный проект за деньги, то лучшее делать его на базе известных подходов, например монолит на базе хексогональной архитектуры. B>Первое что хотел сказать, что везде пишут микросервисы это где много команд часто или много функционала.
Это не основное их назначение. В монолите точно также можно делить всё на разные компоненты между командами. B>но зато скоп определен четко и подумал прекрасная возможность потренироваться, чтобы потом уверенее пробовать в большом проекте.
Проект, честно скажем, небольшой. B>Итого что по функционалу:
Ты забыл внешние системы такие как 1С и систему-поставщика заказов.
B>Третий вопрос. Если без докеров то как настроить этот набор микросервисов?
Это будет сложно. Можно на этом проекте поизучать контейнеризацию на базе докера и засунуть свой монолит и базу в отдельные контейнеры, настроить между ними сетевую связанность и подключить хранилища, подумать как будешь делать бэкап этой базы.
Для микросервисной архитектуры нужно ещё продумывать системный дизайн и процесс деплоя.
Здравствуйте, busk, Вы писали:
G>>Не надо, оно тебя сожрет
B>поясни пожалуйста подробней. а то смотришь тот же Яндекс, у них везде микросервисы + ci/cd
В том же яндексе в каждом микросервисе ад и Израиль, оно тебе надо?
Здравствуйте, busk, Вы писали:
B>звучит что микросервисы удел либо больших компаний либо крупных систем.
Монолит в одно жало/одной командой пилить гораздо проще.
Когда дорастёшь до того, что начнут возникать проблемы с монолитом — ты уже будешь нанимать программистов по 500 рублей и на архитектуру (монолит/микросервисы) тебе уже будет начхать
Так что не стоит
