Планируется создание двух микросервисов: один для депозитов, другой для кредитов. Вопрос как быть с базой данных?
Точнее, делать одну общую базу данных для депозитов и кредитов или 2 раздельные?
По хорошему, конечно, одну нужно делать — проще обслуживать, бэкапировать, лицензии опять же.
Как правильно по феншую?
«По феншую» не бывает таких «микро» сервисов, чтоб «для кредитов» и «для депозитов». Бывают сервисы для работы с клиентами, для управления продуктами, для работы с клиентскими заявками, расчета процентов и прочей генерации проводок и отчетов
с одной базой это будет точно не про микросервисы.
А если разделить на 2 разных базы не выходит, есть завязка на общие данные и т.д.то что? Совершенно верно — создавать 3й микросервис, который будес содержать весь персистанс
Тогда это уже
и который будет бутылочным горлышком
варианты? «распределённый» монолит?
Местами микро, а местами не очень микро, если внятно не делится?
Andrey Rogovsky
Допомагаю знайти першу роботу IT для Трейні та Джунів
в TOPIZDATO: Соціальна IT-екосистема
21.04.2019 22:27
В одном микросервисе держим расходы, в другом приходы а третий делает игого.
переписать все на плюсах
Плюси ідуть в дупу моноліт!
Rust рулить на мікросервісах!
Я це гарантую!
моноліт
плюсы и монолит. монолит и плюсы. что же в них общего? фантазии рустамана
плюсы и монолит. монолит и плюсы. что же в них общего?
Партия и Ленин -
близнецы-братья
кто более
матери-истории ценен?
Мы говорим Ленин,
подразумеваем -
партия,
мы говорим
партия,
подразумеваем -
Ленин.
Партия и Ленин -близнецы-братья
я же говорю
фантазии рустамана
Rust рулить на мікросервісах!
Еще поговаривают, что Go рулит на микросервисах) habr.com/ru/post/430300
И еще для всяких банковских оперденей слышал Erlang годен.
тільки Го з GC, а Rust навіть швидше за С, не кажучи за СРР, Ерланг на ембедед не розвернеш
Rust навіть швидше за С, не кажучи за СРР,
ну. это если код на Си и плюсах не оптимизировать)
Ерланг на ембедед не розвернеш
А это разве не подхордит www2.erlang.se/...embedded/users_guide.html ?
Chapters
Embedded Solaris
Windows NT
дуже такий жирний ембедед на солярці,
а на вантус НТ, то шутка?
Ну я хз, написано, что embedded значит embedded)
Тут надо смотреть, на чем должны эти самые микросервисы крутиться)
Ну и насколько помню есть также возможно запускать эрланг без операционки — правда название этого проекта не помню.
bare metal erlang
є ще така штука — nerves-project.org — кажуть, для IoT
кстати, я нашел, как называлось раньше то, что я имел ввиду — Erlang on Xen. Счас оно вроде по другому называется, может счас оно и называется
bare metal erlang
bare metal erlang
Real bare-metal Erlang virtual machine
Hard real-time event handling, using open source code
ну. это если код на Си и плюсах не оптимизировать)
хз, але на С++ ( починаючи з 11 стандарту) тре добре подрочитися з move та swap
крім того, Rust можна збрирати LLVM, який взуває тормознутий gcc
открою для тебя маленький секрет, только тссс!
с++ тоже можно собирать LLVM
и еще одно скорость сборки != скорость работы
я про runtime performance
чукча видно пісатєль ...
с++ тоже можно собирать LLVM
открил сікрєт Полішінеля
я про runtime performance
Rust можна збрирати LLVM, який взуває тормознутий gcc
где тут про рантайм, а чукча?
move та swap
Не певен, що вони взагалі треба. Чи ти великі класи туди-сюди між контейнерами ганяєш в основному циклі програми?
це не я гоняю, це плючи гонять... в чужом коді,
а Rust муває
Ти ж сам знаєш, що чужий код — завжди — ...
да понятно, шо легасі код на плюсах, але починати новий проект на них, да нунах.
Я от оцінив, що те що зараз роблю на Rust (бекенд для телеметрії\діагностики), якби писав на С\С++, тільки сама розробка зайняла би в три рази більше часу (а ще як врахувати кроскомпіляцію, крослінкування з іншими бібліотеками, інтеграцію з Yocto, деплоймент, ... потім відладка непонятних крешів в рантаймі), то оверхед ще більший.
Чому не пітон чи го? Чи у вас воно навантажене?
high load (перековбашувати дані з декількох CAN шин)
Взагалі, розкажи про той раст. А то стільки шуму, що незрозуміло, нащо воно тра.
(попкорн)
Тут вот систему управления роутером хотели с плюсов на раст переписать. Но что-то не сложилось. Зато мне уже интересно, что оно.
Дивно, мало би взлетіти.
Я читав, що бізнес логіку роутерів зараз на Go клепають.
Може, руки не дійшли.
А він же стейтлесс? Як там з багатопоточністю? Наприклад, якщо відкрито 2 вебки одночасно, і з обох почнуть одне налаштування міняти, а воно асинхронне з кількох етапів, що буде?
Go i Rust якраз для багатопоточності задизайнені.
Для цього є локи\мютекси.
С++, монопоточний, і потребує костилів.
С++, монопоточний, і потребує костилів.
pthread?
як в расті на практиці синхронізувати доступ до налаштувань з двох вебок?
щоб далеко не ходити:
doc.rust-lang.org/...td/sync/struct.Mutex.html
от з глобальними змінними, біда, тре lazy_static костиляти
С++, монопоточний, і потребує костилів.
там такиеже костыли как и в русте
I think the success of Rust at this point is a foregone conclusion, since its main competitor is C++,
and many (most?) people hate C++—not that C++ will disappear any time soon,
but a lot of new projects that would have been in C++ in the past are now started in Rust.
but a lot of new projects that would have been in C++ in the past are now started in Rust.
а пачіму ти же ж знаєш? ))
патаму чта іпаль піпл в ріт ваш поінтер аріфмєтік в ООП об"ьортці
==
це єслі кратко
поінтер аріфмєтік в ООП об"ьортці
ты вот щас какойто бред написал
Поки не спробуєш, не взнаєш.
Я спробув — мені сподобалося (для тих задач що є наразі в телеметрії).
Принаймі створення прототипа і верифікація архітектури іде на ура.
В мене event-based | actors | half-async/half-async
для телефонії в роутері?
і асинхронно розгрібати, на яку слухавку позвонити, яким рінгтоном, і асинхронно шукати номер в телефонній книзі, і кодеки налаштовувати) А поки ти те асинхронне розгребеш, слухавка сама кудись позвонить, і на неї вже позвонить не можна...
багато питань, я не встигаю..
я з ІР телефоніє давно працював,
SofiaSIP (чисто С), а що в кодеках налоштовувати, тобі ж SDP прилітає
Rust я поку ще не бачу SIP бібліотек
На С++ PJSIP, але мені не сподобався, бо тягне за собою медіа стек, а в SofiaSIP там розділено сигнальний рівень і медіа
Тут з іншого боку SIP стека не звукова карта, а USB-приблуда, що спілкується з 6 радіотелефонними слухавками. І треба її обслуговувати (купа асинхронних пакетів в USB щоб налаштувати кожний дзвінок), при тому чекати чи протормозить ніде не можна, бо слухавок 6, і кожна щось може зараз робити. І 10 SIP підключень.
якісь у Вас там збоченці,
Rust то виглядало би як 6 каналів (messages channels), або spawn thread або future, думаю якось так і ще один для супервізора за тим неподобсвтом
отут і питання:
1) слухавка кудись телефоує, thread, що за неї відповідає, поліз посилати в SIP, а в цей час на слухавці нажали велику червону кнопку. І що буде? Поток же висить чекає відповіді від SIP? А користувач вже готовий слухавку об стінку кидати, бо вона на кнопки не реагує.
2) слухавка 1 телефонує на * (усі інші слухавки). Як це зробить, коли в кожної слухавки свій потік?
(збоченці не у нас, це soft real-time / telecom system)
1) сигналінг (Start/Stop/Pause)
2) RTP медіа стрім
3) бізнес логіка кнопок,
нє?
чи всі 3 в 1 потоці?
Як тобі пояснити, руст зручний для concurrency
doc.rust-lang.org/...0.0/book/concurrency.html
Але він не випривить помилок дизайну.
На відміну від С++, більше думаєш саме про бізнес логіку,
а не ієрогліфи кода.
Не зрозумів.
Маємо інтерфейси:
* з інтернетом для SIP/RTP (10 клієнтів)
* з USB для слухавок (control/media) (6 клієнтів)
* з файлами (історія дзвінків, телефонна книга)
* з системою (stdin, syslog)
Кожного клієнта треба швдко обробляти, але відповіді на запити залежать від стану та відповідей інших клієнтів
на жаль, архітектуру на коліні я не задизайню
а де тримаєте стани, в файлі, БД, датаброкері?
А відповіді інших клієнтів?
Я так розумію у вас event2 (libevent)?
Чи DBUS, чи як?
а де тримаєте стани, в файлі, БД, датаброкері?
А відповіді інших клієнтів?
В оперативці)
Я так розумію у вас event2 (libevent)?
Чи DBUS, чи як?
pthread
це якось по-дідівський, ви що там робите select сокетів в циклі?
не по event
зате працює)
select сокетів в циклі
цим займається pjsip
не по event
расскажи, где в линуксе евенты
libevent.org
як для нуба, більше по темі 10К, звідки власне і ростуть ноги
www.kegel.com/c10k.html
я с таким же успехом могу кьют в пример привести — там тоже есть евенты и сигналы и слоты
на самом деле эти либы — надстройка над селектом, поллом и еполлом
Як тобі пояснити, руст зручний для concurrency
doc.rust-lang.org/...0.0/book/concurrency.html
Поки що воно виглядає страшніше за С++ / pthread
от я й цікавлюсь: навіщо?
люде пишуть, що навіть для С++ника корисно повчити Rust, щоб побачити код з іншої перспективи погляду
а ще як врахувати кроскомпіляцію, крослінкування з іншими бібліотеками, інтеграцію з Yocto, деплоймент
в Yocto это делается автоматически
а для Rust з Yocto ще простіше, чим ти подумав
ты так топишь за руст, но почему то у тебя на твоей доу-страничке про него ни слова
Я позиціоную себе, як Embedded systems & IoT експерт.
Можемо поговорити про це, я що тебе це, дійсно хвилює.
можем, как только обьяснишь за счет чего
Rust навіть швидше за С
dtrace.org/...erformance-of-c-and-rust
этому перцу в комментах натолкали уже
он там сравнивает хрен с пальцем
Ну если не влом — найди кого-то посмотреть, в чем отличаются проги в первом линке. Там какое-то SSE, и дальше я не шарю. Надо дисассемблить, что ли, или тоже кеш мерять.
мне влом, если честно
там оно сравнивает кодогенератор силанга с гцц при чем с разыми уровнями оптимизации и с выключенными оптимизациями линковки
Там по первому линку код в 1 файле, разницы в имплементации не заметил. Сильно быстрее у раста с дробными числами на SSE, второй пример по прогону через индексную таблицу тоже, вроде, быстрее.
Сильно быстрее у раста с дробными числами на SSE
у раста какойто особенный ссе? нет. дело в кодогенерации. как я уже сказал — хрен с пальцем
шас подкіну дровцят:
www.quora.com/...ter-than-C-or-C-languages
Then Queralt says:
„C++ is growing and evolving every day, making it a modern language .”
COBOL keeps growing, but it is hardly modern. C++ is not modern — in many ways it is just adding features that have long been in other languages, in particular Eiffel. But while other languages are elegant and like Eiffel express sophisticated constructs in clear and regular syntax, C++ never will be. C++ is quite old and contains much old thinking such as making things incredibly complex rather than the more sophisticated thinking of simple solutions for complex problems. C++ keeps digging itself into a deeper hole. C++ is an awful implementation of OO concepts.
Ну тогда получается, что кодогенератор раста лучше в части случаев. А язык — это и есть кодогенератор.
кодогенератор раста лучше
в последний раз: сравнивая что лучше — руст или плюсы надо сравнивать плюсы собранные силангом и руст собранный силангом, желательно с отключенной оптимизацией
а он сравнивал руст силанг с о3 и ц++ гцц с о2
а Rust муває
и все должны мувать? лы — логыка
Ya like to (move it!)
genius.com/...-i-like-to-move-it-lyrics
а шо такого? нашо вам тє нєкошернії указатєлі коли єсть всьо шоп пісать як на джавє? ))
Rust навіть швидше за С, не кажучи за СРР
:))))
Плюси ідуть в дупу моноліт!
Rust рулить на мікросервісах!
Монолиты это прекрасно.
Микросервисы идут в жопу.
пиздно (к) (тм)
Только C, только хардкор!
а ну да, это же микросервисы
Потому cgi-bin, а не вот эти ваши HTTP2. Понапридумывают извращений
вообще-то cgi всё равно с чем работать он просто на вход принимает входной поток запроса а на выход отдаёт выходной поток ответа как там оно внешне представлено ему монописуально вы же ж не озабочиваетесь как там дальше пакет пойдёт по ethernet или по fiber или вообще по вайфай? ))
То была шутка.
Но честно говоря я вот так сходу затрудняюсь представить как будет работать CGI поверх HTTP2: там же подход немного другой чем запрос-ответ.
browser => GET => HTTP2:stream1 => web-server => cgi:input[GET] => application
browser <= HTTP OK <= HTTP2:stream1 <= web-server <= cgi:output[HTTP OK] <= application
CGI не «поверх» он только на самом конце более того он никуда не поменялся и веб-сервер принимающий что HTTP что HTTP2 точно так же ж может к приложению что по CGI что по FastCGI что как-нибудь ещё например memcached.
HTTP/HTTP2 это веб-протокол а CGI это уже протокол самого приложения сам принцип request/response остаётся полностью тот же ж.
при схемі двох баз, виникне потреба синхронізації клієнтів. Потрібно уточнити, чи в замовника не появляться перехресна бізнес логіка. Тобто, коли логіка видачі кредиту торкається історії депозиту, чи навпаки. Зведені звіти по клієнту, адже для бізнесу клієнт є клієнт і не залежить, чи у нього депозит, чи кредит. З часом появляться нові послуги і архітектура з двома базами буде вимагати створення третьої бази. Також креш бази: У випадку двох баз, при відновленні однієї за продовження роботи іншої, буде проблема розсинхронізації даних. Якщо хочеться вже все розділити, то розділяйте схемами в одній базі.
Любой кредит или депозит в банке это не просто строчечка в табличке. Это целый флоу который затрагивает изменения в нескольких бд, которые физически могут находится в разных государственных и коммерческих организациях.
Исходя из этого между учётными системами типа кредит и депозит вообще может быть мало общего и конечно это может быть два совершенно разных сервиса с двумя разными бд.
Хороший вброс. Много корма для для троллей мамонтов украинского аутсорсинга.
Мікросервіси — це добре, звичайно. Але це добре для обмеженого кола задач. А не там де багато залежностей, перехід до мікросервісів може виявитись досить болісним.
Ставь монгу и делай микробазы на каждый микросервис! Потом по ходу разработки подфиксишь! ;-)
я работал когдато в такой системе, в итоге получаюццо сервисы микросервисов чтобы пофиксить циклический депенденси. В особо упоротых случаях микросервисы сервисов микросервисов...
Точнее, делать одну общую базу данных для депозитов и кредитов или 2 раздельные?
По хорошему, конечно, одну нужно делать — проще обслуживать, бэкапировать, лицензии опять же.
Как правильно по феншую?
Правильно не по фэншуй, правильно проанализировать требования к именно тому, что вы разрабатываете.
Лучше разбей предметную область пологичнее для синтетического проекта. Например, данные о клиентах в одном сервисе, кредиты / дебеты с балансами в другом. И чтобы не совсем тривиально было — данные клиентов могут меняться, но должны быть неизменны для определенных транзакций (вчерашняя выписка если я сегодня поменял адрес). Ну и GDPR прикрутить.
Неплохо бы определиться что хочешь отработать в упражнении. Микросервисы решают определенные проблемы ценой увеличивая других. Масштабируемость в разработке растущей командой/командами, более явные интерфейсы взаимодействия между компонентами и повышенная изолированность оных достигается ценой усложнения инфраструктуры. Так что вполне возможно, что базу в реальной ситуации таки будет сложнее обслуживать.
Дублирование данных в микросервисах — это в целом нормально. База может быть одна физически, но с жетским разделением схем.
А какие микросервисы взаимосвязаны между собой иначе кроме как через апи?
ну очередями могут быть связаны, или всякими другими (не http) протоколами, как smpp, xmpp сокетами в конце концов
API — это публичный контракт. Каким образом он выражен — второй впросы. Удобнее всего для внешних систем — HTTP API, внутри системы — подписка на event stream и формирование локального кеша данных, которые нужны для принятия решения о бизнес-транзакции.
Имхо это не для классических микросервисов. Обычный сервис, с одной общей базой.
т.е. сначала делаем монолит как можно лучше со всякими там DDD, блудницами и преферансом. И только потом переделываем на microservices? А не будет ли это в конечном итоге дороже, чем если бы сразу на микросервисы проектировали.
Будет, но оно может стартануть. А если сразу делать микросервисы — может не стартануть или утонуть в багах и деталях.
KISS
YAGNI
Лучше работающий прототип, которым можно прощупать предметную область и пособирать грабли, чем неработающий монстр.
Я эту статью старика Фаулера привожу всем клиентам, которые сразу в начале проекта хотят микросервисы, только «потому что это модно и у всех уже есть».
выдачу кредитов обозвать микросервисом можно только не понимая ни значения термина микросервис, ни представляя хоть отдаленно сам этот бизнес-процесс
Можливо, мова йде про мікрокредити?
а это не важно
между МИКРОсервисами и МИКРОкредитами нет никакой связи, чтобы там не думали лингвисты
то, что суммы меньше, не упрощает данный бизнес-процесс до линейного уровня
а за якобы упрощенным скорингом, на самом деле может стоять ИИ
скажем, отдельно подачу заявки, еще можно оформить как микросервис, но все бизнес-процессы целиком ну никак не натянуть на определение микросервиса
если они все в куче — это полная противоположность в виде монолитной архитекуры
разделение — это SOA
еще больше разделения — это и есть те самые мифические микросервисы
Вже й пожартувать не можна :)
между МИКРОсервисами и МИКРОкредитами нет никакой связи
так может потому и не работает? ))
Вы должны быть точно уверены, что стоит связываться с микросервисами. Как по мне, то для данной задачи микросервисы не оптимальное решение. Всё-таки кредиты и депозиты не оформляются настолько часто, чтоб разделять их на микросервисы. Тем более микросервисы хороши для соцсетей, например, а для бизнес-задач вам придется решать кучу проблем. Так что подумайте хорошо, возможно обычная архитектура окажется оптимальным вариантом.
По феншую — нанять специального архитектора и помощника архитектора по микросервисам и консультанта по базам данных.
Вообще фигня это. Если нет опыта создания сложных HA app читайте как реализовали другие или найдите когото, у кого опыт есть.
Ага, архитекторов, которые что-то знают про архитектуру 10 человек на всю Украину, остальные выступают только в роли переговорщика
А что за помощник архитектора?)
Помощник по микросервисами же. Внешний консультант. Модно так щас, для каждой дырки отдельная затычка
Ага, архитекторов, которые что-то знают про архитектуру 10 человек на всю Украину
Какие глупости. Если вы думаете, это архитектура это что-то волшебное и недостижимое, то... выдыхайте, и выходите из манямирка.
я так не думаю, но факта это не меняет — в украине профессия архитектора выродилась в менеджерскую
в украине профессия архитектора выродилась в менеджерскую
+ продажницьку
Технічно підкований продавець == солюшон архітект.
Откуда такая статистика? Или вы про архитекторов, которые дома проектируют?
из того что я вижу что если человек, работая архитектором, только разговаривает, то через несколько лет он уже и не может ничего больше, более того меняя работу практически всегда приходишь на какой-то увал, а не проект, если на нем есть архитектор, то можно поговорить и понять что все решения, которые он принимал не подходили к проекту, просто он слышал что такая связка как он выбрал хорошо работает в вакууме
Во-первых, это проблема касается не только украинских архитекторов. Во-вторых, если сам архитектор не понимает/не хочет/не может, то это проблема конкретного архитектора. Каждый (не только архитектор) должен заниматься самообразованием и понимать куда он движется дальше. Если ему нормально постоянно болтать, то пусть идет в деливери или поднимается уровнем выше и идет в VP of Engineering. Но если ему нравится своя работа, то нужно понимать, что без практики, без кодирования, скилы будут падать, и нужно этому уделять хотябы немного времени.
Подход к построению архитектуры тоже имеет значение. Самое ценное в архитекторе — это практический опыт и умение строить архитектуры, которые работают в реальности и стратегически мыслить. Если все, что может архитектор — это погуглить и взять решение с первой странички — то это не архитектор. Настоящий архитектор должен уметь любыми способами получить гарантированный результат. И это начиная POC и до даже интуиции.
согласен, поэтому и мало
все решения, которые он принимал не подходили к проекту, просто он слышал что такая связка как он выбрал хорошо работает в вакууме
Когда проект в новой для тебя области, остаются чужие решения и чуйка. Нормально (идеально) будет устроен только дважды переписанный проект.
может на плюсах оно и так из-за того что лютый спектр задач решается от микроконтроллеров до геймдева, но в шарпе, джаве, пхп, джаваскрипте и т.д. можно сходу сделать хорошо
Если честно: не скучно?
нет, специфика работы другая просто и как следствие другие проблемы, но если бы их не было, я бы только рад был, а не скучал :) ведь как можно скучать, если все хорошо и все довольны? от рутины что ли? она вся автоматизируется, а если не хо, то одной рукой коды строчил, второй рукой... кхм... вобщем раз голова не занята из банального можно сериал смотреть/доу читать/всевозможные разговоры от личных до митингов говорить и т.д.; мне вот вообще не интересно превозмогать боль, о которой ты говоришь, вот не хочу я постоянно разбираться в какой-то мути, которая на один раз нужна, толку с такого человека потом нет, по крайней мере в шарпе, все не мейнстрим технологии просто не пригодятся и то что в них у кого-то может быть опыт никого не волнует, но если нет опыта в мейнстриме, то плохо
Возможно я не прав, но проектировать систему должен разработчик, а не какой-то архитектор. Разве что этот архитектор и является разработчиком. Теория это одно, а применить все премудрости на практике совсем другое.
Мидл точно не должен. Развечто вам совсем пофигу на саму систему. Архитект, естественно, разработчик уровня сенйор или выше.
пересечение работы архитектора и работы синьора минимальное, большинству синьоров не приходится проектировать ничего дальше пары классов, да и то иногда такое уродство получается, а архитектор не углубляется в тонкости реализации. наверняка полно исключений, но в среднем работу друг друга выполнить нормально разработчик и архитектор не смогут
Это у вас просто «украинские сенйоры». Сенйор по определению должен быть способен спроектировать сложное приложение.
«сложное» для кого?
сложно спроектировать или спроектировать сложное?)
Это откуда такое определение? Я читаю комментарии, и четко видно какие решения предлагают сеньйоры, а где реально архитекторы. Сеньйоры реально не понимают, зачем нужно физически разделять базы, а не делать две схемы в одной базе.
І навіщо розділять бази? Я маю власний досвід, але мені цікава точка зору архітекта.
Для того, чтобы можно было реально скейлить микросервисы по-отдельности. Если вы задеплоили несколько инстансов микросервисов на разных виртуалках/контейнерах, а база у вас физически одна, пусть даже и в разных схемах, то она будет являться бутылочным горлышком, и реального скейлинга и отказоустойчивости не будет. У каждого микросервиса — свой инстанс базы, который можно скейлить независимо от других сервисов. Только тогда это будет работать.
Накладних на синк інстансів нема, або мало, так?
або усім класти на консистентність
Особливо прикольно, коли іопси зашкалюють, і базу партиціонують на інстанси, шоби розпаралелить, а потім комусь приходить в голову думка, що треба робить якийсь мультимастер для агрегації, і там іопси зашкалюють іще більше :)
А треба було всього лиш трошки денормалізувати базу і трошки помінять модель, аби запити з семиповерхових перетворилися на однострочники. З індексами.
А треба було всього лиш трошки денормалізувати базу і трошки помінять модель, аби запити з семиповерхових перетворилися на однострочники. З індексами.
у «архитекторов» с этим сложно и даже уперевшись в потолок, доходит не до всех
Вот как раз в этом и заключается работа архитектора, чтобы подобрать саму базу и ее оптимальную конфигурацию. Обычно есть множество разных решений одной задачи, и нужно выбрать баланс с точки зрения соответствия требованиям, стоимости инфраструктуры, стоимости и скорости реализации решения. Зачастую приходится реализовывать не самое оптимальное решение, просто потому что нет времени/денег. И да, бывают просто криворукие решения :)
база — дело такое. А то ж наваяют схему, что любой кровавый энтерпрайз в сторонке курит, по итогу не взлетит нигде и никак
Ну здесь вариантов накосячить просто бесконечность :)
Зачастую приходится реализовывать не самое оптимальное решение
В чем тогда его оптимальность?
Это уже отпимальность не с технической точки зрения, а с точки зрения всего проекта. Идеальных проектов не существует, всегда есть ограничения, и оптимальное решение должно учитывать все факторы, не только технические.
Тогда зачем реализовывать неоптимальное?
Cuz it’s beta than nutting!
Тобто, можна напроектувати що завгодно, а потім сказати, що не вистачило часу/грошей, або просто руки криві?
Якось воно не теє... не той во...
Тогда зачем реализовывать неоптимальное?
А какие еще варианты? Клиент всегда хочет быстро, качественно и дешево. Это как CAP теорема, чем-то нужно пожертвовать :) А бывает даже двумя пунктами приходится жертвовать и создавать технический долг. Если приходит например стартап с собственными инвестициями, чтобы очень быстро сделать MVP и пойти к инвесторам за следующим раундом, то у них ключевые ограничения — деньги и скорость. Масштабируемое и отказоустойчивое решение можно сделать после MVP, когда пойдут реальная нагрузка и будут финансы для такого решения.
Тобто, можна напроектувати що завгодно, а потім сказати, що не вистачило часу/грошей, або просто руки криві?
Наверняка бывает и такое. Но обычно заканчивается печально, так как даже самый далекий от IT клиент просто нанимает внешний аудит и в результате вы теряете клиента, деньги и репутацию.
«Это у вас просто» большие проекты. Вдобавку, временами один синьор может сделать проект быстрее, чем 5 команд по 5 человек с архитектором.
Повно виключень у добре профінансованих стартапах. Можуть дозволити собі найняти тямущого архітектора, і водночас розміри продукту часто роблить виправданим залучення архітектора до розробки.
проектировать должен тот, кто умеет проектировать, ни больше, ни меньше, то что одни проектируют, а другим потом под это подстраиваться это обычное дело, даже если будет проектировать тот, кто будет и реализовывать, то он рано или поздно уйдет и оставит наследство, и это тоже самое по большому счету. если он умел проектировать, то будет хорошо, если не умел, то будет то, что часто можно увидеть на проектах, выбрали что-то модное, но не подходящее: мода ушла остались только проблемы
Как правильно по феншую?
Non sunt entia multiplicanda praeter necessitatem
А чем вообще отличаются «микросервисы» от «разпределённый монолит»?
Тем, что то и то горизонтально скейлится, но микросервисы можно скейлить по отдельности, а монолит только целиком. Но в большинстве случаев можно спокойно скейлить монолит, а несколько «особо ценных сервисов» вынести отдельно и скейлить отдельно.
Для микросервисов есть четко определенные задачи, которые они решают и из этого вытекает подход к их построению и в общем микросервисная архитектура. В манифесто одним из столбов микросервисов является ответственность. Если эту ответственность размазать, то это явно не микросервисы.
.as*x никакого отношения к микросервисам не имеют.
вопрос:
чи це вже мікросервіси тоді, чи ні?
ответ:
.as*x никакого отношения к микросервисам не имеют.
Я ответил на вопрос?
Те, которые захотели? Можете еще пару любых дописать, сути это не изменит.
Все — это никто. Почитайте сначала хотя бы что-то про микросервисы, а потом пишите.
Если прочитал, почему чекбокса два?
Вы наверное считать не умеете. Оставлю здесь и специально для вас пронумерую, так как видимо вы сами не в состоянии:
The 6 core pillars of the Microservice Manifesto
1. Ownership: Ownership is the most important pillar, according to Aucoin. „Without creating ownership, without really valuing your team members and knowing that they are all trying to work towards the same goal of making your company successful, you won’t be successful,” he said. According to the manifesto, businesses typically organize systems in a multi-tier way with segmented teams. However, if you create cross-functional teams that have full ownership and are aligned with the business, it allows solutions to be delivered faster, and the company to respond to hurdles quicker.
2. Automation: Automation is a top pillar because it helps businesses break down large monoliths quicker, with fewer errors. „If you don’t have automation, trying to break down a monolith or deploy several new greenfield microservices becomes an exercise in madness, and no one wants that,” the manifesto states. Aucoin added that automation enables the success of the other pillars, such as testing.
Testing: Testing as much as possible requires being able to automate as much as possible, which is why testing is the third pillar. „Having automated tests that can run during each deployment ensures that we are delivering quality products and not regressing. The benefit to automating that testing is that we get much better use of people time so that instead of executing tests, quality engineers can be writing tests instead,” the manifesto states.
3. Discoverability: Discoverability refers to being able to find what you need, when you need it. This is important from a business perspective as well as a technical perspective, Aucoin explained. It enables the business and teams to manage and utilize the system’s functionality. In addition, discoverability refers to data governance and making sure data is consistent and accessible.
5. Accessibility: Accessibility is making sure services can access each other regardless of the program they are in. „After your services can be found, other services need to be able to connect to them. Within the world of microservices, the preferred methodology for this is to expose your services via HTTP(s) and use standard serialization formats that have excellent support across multiple languages such as JSON,” according to the manifesto.
6. Responsibility: Lastly, after you build something, you need to be responsible for it — not just how it impacts your team, but how it might impact other teams, services and people, Aucoin explained. „Responsibility also means being responsible for the care and feeding of the services your team owns,” according to the manifesto. „It is your responsibility not only to make services that fulfill the needs of the business; you also need to make sure that the services are fault tolerant, stable, and new releases don’t interrupt consumers.”
Конечно, Facebook, Google, Azure, Twitter, Netflix, Amazon, eBay — все сектанты, у которых микросервисы работают именно в таком виде. Только вы самый умный и одном словом даете определение. Я уже не буду дискутировать про ООП, так как это бесполезно.
У вас есть своя секта и теория микросервисов из 2 пунктов, и вы занимаетесь ее маркетингом. Тогда развивайте свою секту, а не задавайте здесь вопросы, если знаете лучше всех.
Ясно, когда нечего ответить по сути.
Так просвятите нас, несведующих, что там эти дурные авторы упустили, а все сектанты в силу своей глупости не заметили.
Спасибо, что снизошли и позволили мне один раз угадать. Низкий поклон, барин.
Даю вам одну попытку написать, ибо уже надоело читать всю эту воду без единой конкретики.
Нечего сказать — молчи, есть конкретика — пиши, а не 100500 сообщений ни о чем.
Опять вода, абстрактные философские высказывания, не имеющие никакого отношения к практическому использованию микросервисов, тем более основной мотивации их создания.
Я уже молчу про отношение микросервисов/монолитов к языку/парадигме программирования.
архітєкт. :(
солюшін архітєкт (к) (тм)
Це щоб
інформейшн хайдінг
не плутали з
мікросервісним підходом
та
об’єктно-орієнтованою, або, ба більше, функціональною мовою програмування
.
Я привел реальные юскейсы, а не маркетинг, в отличии от вас. А вот от вас, кроме отвлеченных философствований на свободные темы, так ничего услышать и не удалось.
Направь пожалуйста на инфу по данной теме, с нуля. Начиная с проблемы, которую микросервисы решают, гайдлайны по построению, и т.д.
Спасибо. Это всё, что нужно знать для начала?
Я вообще не в курсе. У джавистов надо спрашивать.
Краще у тих, хто використовує Kubernetes.
«По феншую» не бывает таких «микро» сервисов, чтоб «для кредитов» и «для депозитов». Бывают сервисы для работы с клиентами, для управления продуктами, для работы с клиентскими заявками, расчета процентов и прочей генерации проводок и отчетов
Пусть даже будет один кластер БД, но можно же сделать тупо разные схемы(если Postgres) или базы данных (если mysql). Ну и ключи между ними не должны ссылаться друг на друга. Таким образом у нас лучшее из двух миров — и админить легче, и есть сепарация данных.
Эх, зря вы философию прогуливали, знали бы что такое ложная дихотомия и гегельянского синтез.
причем все это же часто используется и в монолитах и никто не носится со своей супер особенной методой
А кто носится-то?) Микросервисы — в первую очередь о функциях и контекстах, а данные уже подстраиваются под них, поэтому спор о разделении изначально вторичен (хотя тема и о кол-ве баз, но тем не менее). Почему-то для тебя одна база на сервис — это прям ппц какая догма, хотя сам ты догматически настаиваешь на другом подходе).
Здесь есть ещё момент (хотя, какой нафиг «момент» — самое главное): архитектура. Можно сделать несколько микросервисов, тем временем часть системы оставив просто сервисами — в таком случае можно наблюдать любые огороды. Если же мы говорим о микросервисной архитектуре (где каждый сервис — микро), то своя база на сервис и eventual consistency — это действительно правило, а другие кейсы — исключения.
Ну а как? Много баз — всё, фу, Библия, не верю; одна база — освящённый Древним Монолитом Святой Грааль 146% и все должны доказать, что другие варианты лучше).
Лол, так ты же предлагаешь наоборот). Привык есть всё с хлебом (потому что он, как известно — всему голова), и говоришь, что правильно — есть продукты именно с хлебом, потому что так и дешевле, и количество контролировать легче без перерасхода продукта, т.к. всего один тип продукта, и сытыми все будут в любом случае, и хлебницы стандартизированы бгг (бирку повесим именную для каждого), и вообще существует 100500 сортов хлеба на любой вкус, и магаз прям рядом с домом, поэтому какие проблемы? Какие булки, какое ещё что-то — покупаем только хлеб, нормальные хот-доги будут, вы чё).
Потому что он пропадет и не окупить себя и займет место для хранения и доставка сложнее и тд
Если это — проблема, то в очередной раз поднимается вопрос, а нужны ли там микросервисы. На них переезжают, если это упрощает дела, а не усложняет. И они нужны меньшинству бизнесов вообще. То, что в этой теме упомянули микросервисы — не значит, что они там нужны, и что твой к этому подход правильный, т.к. уже сам автор говорит, что это чисто пет-проект поиграться с микросервисами ради микросервисов.
Зависит от архитектуры же. Кто знает что вы городите на беке, если CQRS+ES то 2 отдельные, может у вас простая
По уму так ни один из сервисов «для депозитов» или «для кредитов» не должен заниматься клиент менеджментом, это верный способ отстрелить ногу. Так что третий сервис и третья база, да
данные о клиенте в обеих базах дублировать?!
уже давно не
Если уже будут два микросервиса, значит, за ними вполне могут стоять два разных отдела с разными потребностями. Значит, буква S в одной известной аббревиатуре решает.
Робиш один мікросервіс, але деплоїш його два рази (і дві бази), через енв змінну прокидуеш параметр SIGN — «+» якщо депозит та «—» якщо кредит.
у отставного пожарника, который работал вахтёром в филармонии, дружбаны спросили:
«а чем отличается скрипка от виолончели?»
— виолончель дольше горит, ответил пожарник
Только лишь микросервисы, без кложи и блокчейна — не взлетят.
В данной конкретной ситуации нет никаких оснований вообще городить микросервисы.
Что касается БД, то правило тут одно — у каждого микросервиса своя, выделенная БД.
Здесь скорее нужна аргументация, зачем там микросервисы? Или если там просто распределённый монолит, зачем использовать модное название ради хайпа?) Другое дело, что в энтерпрайзах эволюционное разделение проходит не то что не за 5 минут, а даже не за год, и вот прям раз, и у нас был монолит, а стали микросервисы — такого не бывает. Может, оттуда и точечные деплои на базы с 10к таблицами? Короче, вне конкретного контекста и процессов обсуждать это не особо есть смысл.
ну потому шо в противном случае табличка в базе станет интерфейсом какого-то из сервисов, а интерфейс в виде таблички как-то сложнее поддерживать годами без изменений, чем какую-то хттп апишку
Накатил изменения на таблички для этого микросервиса
и сломается микросервис Б, который импортирует себе данные из этой таблички скл запросами, которые теперь не работают. Теперь надо и на сервис Б накатывать деплой, т.е. это концептуально уже не микросервисы получаются
А что хттп апишка на тот же сервис будет работать без базы
так я не об этом. Деплоим так, как ты написал, но когда сервис А проснется, у него будет такая же апишка, а данные хранить он теперь будет по другому
если у каждого сервиса свой набор табличек — то логически у нас 2 базы, просто они в одном субд сервере валяются. Я, как наверное и многие в топике, понял понятие «одна база» как такую, где данные шарятся
окей, в таком случае ответ на вопрос автора
Как правильно по феншую?
никак, абстрактные паттерны не дают ответа на такие прикладные вопросы, делай как проще конкретно тебе
Типичный контекст/общий случай именно микросервиса подразумевает свою базу, поэтому сорри, в данном случае с твоей стороны должен быть пруф, что для микросервисов подойдёт одна база. Либо вообще пруф, зачем там микросервис (и микросервис ли там, а не обычный сервис). Про контекст я имел в виду, что чаще всего декомпозиция идёт поэтапно, но ведь пока она не завершена, это ещё и не микросервисы. Мы, кстати, сейчас идём по этому пути (в начале месяца целюсь выкатить отдельный сервис вместо куска монолита), но т.к. есть ещё пара жёстких зависимостей, которые в перспективе уйдут, каноничным микросервисом он пока не является.
нужно много баз! Так говорит Библия микросервисов
Я не вижу микросервис — я вижу, что ты говоришь, что можно развести данные разных сервисов в одной базе.
есть аргументы за?
Ты сейчас говоришь не «за» и «против». В общем случае, ты даже не сказал, почему это — хорошо, и так не обозначил свой кейс. В multi-tenant’е, например, тоже делают логическое разделение баз — как ты правильно сказал, это вполне себе используется в монолитах давным-давно. Микросервисы в этом празднике жизни где тогда и, главное, зачем?
Нет уж, утверждение чтт каждому микросервису нужно по базе — требует подтверждение, бремя доказательства лежит на утверждающем это
Ты утверждаешь пока только то, что это возможно, и раз это возможно, то тебе должны доказать, почему иначе — лучше. Интересная логика, мягко говоря). Типа я вот знаю свой кейс, и что так можно сделать — значит, это самый «микросервисный» кейс из всех и, более того, самый типичный. Но этот кейс как раз типичен для переходного периода, когда декомпозиция ещё не закончена. Более того, не факт, что эту декомпозицию доведут до «каноничного» завершения, т.к. это может оказаться вообще не нужно в конкретном случае — ну и хрен с ним, отлично, только зачем тогда термин «микросервис», и попытки притянуть туда исключительно то, что нравится конкретно тебе?)
Достаточно распространённый пример: асинхронное API. Ты собираешься нужную для имплементации инф-ю хранить в SQL базе? Или, ещё лучше, в одной SQL базе на все сервисы? Ну ОК, вперёд, отличный выбор бгг.
Какой мрак,
Где ? в том, что для решения описанной бизнес-задачи микросервисы не нужны ?
можно вразумительную аргументацию зачем отдельные базы?
Если разворачивается микросервисая архитектура, то неплохо бы найти обоснование тому, что БД должна быть одна.
Просто в силу того, что решения той или иной изолированной задачи может и предполагает — разный набор инструментов, в том числе хранилищ данных.
Грубо говоря какая может быть ОДНА БД у
Точечные деплои накатывают на базы с 10к таблицами
Какое это имеет отношение к обсуждаемому вопросу ?
а тут вишь ты микросервисы, так нельзя оказывается
У себя Вы вольны творить, что угодно. Хоть резать одним ножем и сырое мясо и сыр. Или данные микросервисов совать в одну БД.
Я ж говорю, как свидетели иеговы))))
Те, кто использует в своей работы паттерны GoF такое же ?
То есть это мне надо обосновывать вам что вам не надо 10000000000 баз а только одна?
Вопрос понимания что есть микросервис. Вы этого просто не понимаете. Почитайте пожалуйста, что такое микросервисы, зачем они нужны, для решения каких задач и когда.
Баз должно быть минимальное необходимое колличество,
У меня другое видении ситуации. Практически количество БД определяется реальностью, а именно сколько надо исходя из сложности проекта, бизнес задач, бюджета и так далее.
К примеру с ходу — классика постоения больших систем, а именно разные БД для «горячих» и «холодных» данных четко показывают определенную сомнительность Ваших утверждений.
С определенной натяжкой Ваше видении можно принять в одном случае — если у Вас есть очень сильный коллектив DBA и частично — бизнес логика на уровне БД.
Но это никак не касается микросервисов и вообще само по себе крайне сомнительное решение.
и пока что никто не привел норм аргументов зачем вам надо 2 базы
Например сервисы могут территориально распределены
Не правило-аксиому, то то, что одна база антипаттерн )
Сегодня микросервис тут, а завтра его надо перенести куда подальше, но без гемороя это сделать нельзя, так как база одна )
Отдельные базы нужны чтоб ничего о базе не знать, тупо место для сброса/подбора данных через ORM. Это веб-тема, в мире хранилищ и прочего энтерпрайзного бекенда нереализуемо
у микросервиса вообще никакой базы может не быть. либо он может иметь доступ к базе опосредованно (через другой сервис выставляющий CRUD как REST)
По феншую структуры данных правильно выбирать, базируясь на алгоритмах, которые будут использовать эти данные в программе.
Базу данных в вашем случае можно планировать так же, как архитектуру приложения — чем вас монолит не устраивает в прилржении, зачем микросервисы? Те же аргументы за и против применимы к БД, по существу.
Вообще, если просто попробовать — то начинайте с монолита (и приложения и баз), постройте приложение в DDD стиле (прочтя Big Blue Book), затем разделяйте приложение на отдельные микросервисы по Bouded context’ам — в том числе и БД — будет тренировка по феншую.
Ты главное на коллцентре и IVR не экономь для депозита
Добрый вечер.
С моей точки зрения, создавать микросервисы для таких схожих контекстов без необходимости, не стоит. Так как микросервисы вам часто добавляют сложностей в виде: дополнительного мониторинга, дублирование кода, дополнительных билдов и релиз пайплайнов. Дальше есть вопросы по коммуникации между микросервисами и транзакциям. Намного проще соединить в один микросервис с названием ,например, «Accounting».
В целом, у каждого микросервиса должна быть свою база данных — data projection. При изменение состояния одного микросервиса — создается событие в очереди, те сервисы, которые заинтересованные в этом событии подписываются и обновляют свои data projections.
Если же вы будете использовать одну базу данных для двух микросервисов, то:
— Вы теряете fault tolerance (если падает база, падает все).
— Вы теряете strong ownership (не понятно какая команда отвечает за конкретный набор в бд.)
— Сложнее понять кто меняет и читает данные (представьте себе 10 микросервисов, которые пишут в разные таблички в одной бд)
В целом, у каждого микросервиса должна быть свою база данных — data projection.
Не совсем, как правило микросервисом выступает коннекшн пул, который держит драйвер бд, умеет даздавать коннекшн тому микросервису, которому нужна эта база, понимаешь?
Меня это тоже смущает. Но живут же как-то люди, компромиссы находят...
Но живут же как-то люди, компромиссы находят...
Копромис простой: потерять бабки на разработке и замедлить скорость доставки новых фич, чтобы сэкономить на оркестраторе (даже банального докер-композа хватит)
якшо смущає кількість бд, то є підхід Private-tables-per-service
microservices.io/...database-per-service.html
Паттерн интересен тем, что он даже в примере в статье является неработоспособным. Т.к. по тем табличкам никак ACID не сделать без внешнего арбитратора, например.
Ибо сервис клиента не сможет удалить клиента, если у него есть ордера (про которые он ничего не знает), а сервис ордеров добавить ордер (т.к. внешний ключ на таблицу клиентов).
Так же прекрасен совет автора «а вы ACID программно реализуйте». Ага, чтобы при каждом деплое какого-либо из сервисов иметь немалую вероятность его сломать нафиг. Плюс нафиг забыть про бекапы и прочие артефакты дохипстерской эпохи, т.к. консистентными они при таком подходе не будут никогда.
ЗЫ. Основной и главный жыр микросервисов в том, что с их помощью можно относительно легко масштабировать нагрузку по небольшим инстансам в облачной среде при необходимости. Причем нагрузку на конкретные операции/части приложения (иначе инстансы будут большими).
И именно в этом контексте они и должны проектироваться в первую очередь. А уже во вторую (и это намного более редкий кейс), когда над огромным приложением одновременно работает несколько команд каждая над своей частью, причем эти части могу жить друго без друга (типа ядро и плагины).
Цэкюэрэс, потом проблемы с рассинхронизацмей данных, аудит, и много много другого гемороя, которого можно было бы избежать имея одну базу. Особенно там где транзиктивность и корректность данных — приоритет.
Я вообще пока что не понял для чего нужны микросервисы и что из них можно сделать полезного.
Но эта картинка мне нравится media.giphy.com/...giphy-downsized-large.gif
Мне больше эта нравися lostechies.com/...microservices-12-6381.jpg :-)))
микросервисы живут своей жизнью (деплоятся там сами себе) не задевая тем самым работу друг-друга.
микросервисы пересипользуются от проекта к проекту, поскольку каждый из них отвечает за свою микро работу, например: кто-то отсылает смски, кто-то почту; кто-то является коннекшн пулом к базе; кто-то занимается очередями, кто-то рисует фронтэнд.
микросервисы взаимодействуют друг с другом: имеют собственные микро апи с версиями и юзают друг друга
Жирные приложухи лишены всего этого и имеют более долгий процесс сборки, что увеличивает как даунтаймы продакшна так и личное время разрабов
Проблема в том что большенство программистов — идиоты, без собственных мозгов.
Прочитав пару статей о том как это круто, они бросаються решать любую проблему данной технологией без какой либо мысли о том подойдет это, или нет, какие могут быть челенджи, камни, итд.
И эт касаеться любой технологического базворда, не ток микросервисов. Вплоть до того что блокчейн пытаються всунуть куда не попадя.
Может, хочется попробовать новую игрушку, за которую платит заказчик.
Иначе откуда взять профессиональный рост?
Иначе откуда взять профессиональный рост?
ліл взять что?
ЗЫ: а стоп тут же ж недавно была заметка про нашего типлида с лондОна со софт скиллами ))
Ну вот идешь на собеседование чтобы +500, а там: «работал с микросервисами? нет? до свиданья».
А так: приходишь, «да», +1000.
И все это в рабочее оплачиваемое время.
ниоткуда не взять кроме как из интереса собственного, инженерного, блин, исследовательского. Нравится тебе это — ты растешь, ходишь чтаны просиживаешь — загибаешься!
А теперь откуда взять время?
Есть 3 задачи:
* работа (финансы)
* исследовательство (интерес инженерный)
* жизнь (семья/горы/придумайсам)
И на них 2 кванта времени и сил. Надо либо совмещать задачи, либо от одной из них отказаться.
Проще всего совместить работу и профессиональный рост. Пилить микросервисы за счет заказчика (даже если они ему не надо, но он об этом не подозревает).
Проблема в том что большенство программистов — идиоты, без собственных мозгов.
не пали кантору!!!
даунтаймы продакшна
Никто не заставляет выключать старую версию пока собирается новая. И по-хорошему должно быть несколько наборов серверов, один из которых можно обновить, пока остальные обслуживают продакшн во время низкой активности пользователей.
Да, но это уже вопрос кластеризации продакшна и к микросервисам не относится
А как разрабу мне быстрее собрать/протестить маленькую приложуху, чем большую — вот и все микросервисы.
И как пацаны
микросервисы более дружественны маленьким скрам командам
Скрам ни разу не дружественен длительным или сложным проектам
кто-то отсылает смски, кто-то почту
Угу, классический sink, когда сервис только принимает реквесты и не дергает другие сервисы — то все зашибись
там ещё COM/DCOM/COM+ были корба ацтой! ))
COM, CORBA — поколение пепси. Настоящие программеры ещё сидели под RPC.
ты катодные дисплеи видишь? а их нет! ))
Настоящие программеры ещё сидели под RPC.
технически COM построен поверх RPC как «транспортного уровня» и технически есть просто ООП для RPC ))
Микросервисы нужны там, где у вас природа задач ассинхронная и с бутылочными горлышками.
Ну вот пример. Есть система обзвона, после звонка надо проиграть 10 разных файликов, часть из них TTS создать.
Реализация на микросервисах работает лучше. Ложите в очередь задачу в состоянии «нужны файлики». Запускаете 100500 инстансов которые файлики переносят в локальный кеш, запрашивают у Polly недостающие, переносят в другую очередь на позвонить.
Потом «микросервисы» каждый со своим свичем звонят и играют файлики.
Потом результат ложится опять в очередь, и есть еще N микросервисов, которые возвращают результат в mysql, что позволяет сгладить пики.
При наличии минимальных знаний по блокировкам и многопоточности — все работает.
А монолитом тот же сервис вечно сбоит.
Это вот пример где сервисы лучше работают. Вообще любая не сильно связанная и некритичная к времени выполнения конкретной таски задача — подходит.
К тому же микросервисы просто горизонтально отмаштабировать более чем на одну ноду.
Как минимум на первых порах это работает и с монолитом, просто на разных инстансах запускаются свои демоны, зависящие от роли инстанса. Нужно обработать очередь файлов, на ряд инстансов деплоится весь монолит, но работают только слушатели очереди новых файлов, конвертации и отправки в другую очередь. На другой ряд инстансов опять деплоится весь монолит, но работают только обработчики другой очереди, которые что-то своё делают.
Одна кодовая база, нет архитектурного ступора по выделению зоны ответственности микросервисов и прочего оверхеда, уже есть масштабирование.
Но, хоть это действительно и промежуточный этап, он может вполне себе жить какое-то (долгое) время.
Пока не устаканятся бизнес требования, появится понимание жить идеи или нет и какая реально-прогнозируемая нагрузка будет на ту или иную часть системы, а не вымышленная — делаем убийцу фейсбука.
Если у вас монолит состоит из РАЗНЫХ демонов, то это у вас и есть первый шаг к микросервисам. При правильной архитектуре у микросервисом нет никакого оверхеда.
Вам все равно надо кудато ложить уже сделаное, вот вам и очереди.
очнее, делать одну общую базу данных для депозитов и кредитов или 2 раздельные?
Если у вас 1 БД (схема), то это уже не микровервисы. Точнее известный антипаттерн для микросервисов.
По хорошему, конечно, одну нужно делать — проще обслуживать, бэкапировать, лицензии опять же.
Выкатывать обновления как? Как гарантировать что обновление одного сервиса не повлияет на работу другого? Как гарантировать что «для упрощения» кто-то не заиспользует таблици из другого.
Кстати, чем объстняется желание сделать разные сервисы для депозитов и кредитов? И то и другое влеяет на баланс и прочие штуки. Вы уверены что «микросервисная архитектура» не закончится распределнными транзакциями?
пет-проект, этим и объясняется) а причём здесь распределённые транзакции?
пет-проект, этим и объясняется)
Тогда не важно как вы сделаете. Хотите делать 1 БД делайте одну.
нет, нужно приближенно к боевому решению, как должно быть. Пусть и пет проект
нет, нужно приближенно к боевому решению, как должно быть.
Тогда ответьте себе на вопрос:
Кстати, чем объстняется желание сделать разные сервисы для депозитов и кредитов?
В боевом решении нужно сначала понять зачем вам микросервисы, какую проблему они решают. Когда поймете, то сможете сами ответить на вопрос сколько нужно БД.
а причём здесь распределённые транзакции?
Они возникает, когда фактически одна логика оказывается физически разделенной между разными сервисами, базами и тд. Микро- или разными системами, не важно.
Потребность в них может возникнуть, наприммер, в результате усложнения бизнес-логики, когда ранее независимые процессы становятся связанными и должны поддерживать консистетнтность распределенных процессов и данных.
Или же в результате в том числе ошибки проектирования, когда изначально единые процессы, или очень тесно друг с другом связанные, недавльновидно решают реализовывать раздельно. С высокой долей вероятности, это ваш случай.
Не садить обезьяну за кодинг?
Не поможет: всегда найдется абезяна которая пообищает новую фичу на вчера :)
Микросервисы и с одной обезьяной вводить не стоит, а с командой-зоопарком так тем более
А прийдется, потому что есть абизяна, которая продала микросервисы заказчику :)
Проблема версий конфигурации и редеплоя всех микросервисов, часто значительно легче распределенных транзакций, и синхронизации данных.
Не садить обезьяну за кодинг?
Ты уверен, что такая вот абизяна не работает в соседнем отделе и прямо щас не пишет «фишку» присасываясь к базе, которую использовать напрямую не должна?
Практика показывает, что в этом никогда нельзя быть уверенным. Особенно если проект уже успел стать успешным, растолстеть, разрастись, приносить бабло и компания уже начала строить свою стратегию в т.ч. вокруг него.
Тут же отовсюду приходят знатные интеграторы, которые предлагают решить проблему в стиле «пфф, а мы тут щас вьюху сделаем вотсюда а воттуда процидурку». А потом при миграции ты в ярости ищешь того, кто накидал тебе в базу констрейнтов без спросу. Дропаешь эти констрейнты, а потом у марьванны из отдела аналитики и подсчета процента жиров у масле отчетность отпала.
Кстати, чем объстняется желание сделать разные сервисы для депозитов и кредитов? И то и другое влеяет на баланс и прочие штуки. Вы уверены что «микросервисная архитектура» не закончится распределнными транзакциями?
А что в микросервисах надо быть уверенным, что сервис не шарит данные из своего bounded context с другими сервисами или когда шарит, то консистентность не важна?
Не понял вопрос, перефразируйте.
Выше утверждается, что в ‘правильных микросервисах’ все, что зависит от депозитов и кредитов — ‘баланс и прочие штуки’ должны быть в одном месте, потому что разнесение в разные сервиса повлияет на необходимость делать нечто вроде распределённых транзакций — а это противоречит микросервисному паттерну?
Сделайте себе dataserver сервис для обращений в базу (он вам и кеш может дать синхронизированный) и не бойтесь обновлений и прочих контекстов
Сделайте себе dataserver сервис для обращений в базу
А расскажите подробнее. Если речь идет про вынесение персистенс лейера в отдельный сервис, то это антипаттерн.
Тут можно много привести различных аргументов. В основно потому, что персистенс леер не сводится к идиничным независимым инсерт/селект/апдейт, а выполняет в транзакции больше количество логики, таким образом слой персистентности неявно но жестко связан со слоем бизнес-логики. Яркий пример — транзакционные методы в сервисах.
Типа вынося персистент слой в отдельный типа сервис у вас есть фактически только 2 пути:
1) деградировать то круд-обертки над базой, с вытекающими большими проблемами
2) продолжить реализовывать логику как часть персистентного слоя, но уже неестественно разделенную на разные сервисы, опять таки с вытекающими большими проблемами.
Мне кажеться тут от задачи надо плясать.
Разделять дебит с кредетом от персистент леера — и получиться перечесленные проблемы.
Однако в случаях когда транзакции не нужны, для получения всяки конфигов, скедулов, и всякого прочего — чем плохое решение?
для получения всяки конфигов, скедулов
...и это 0,1% от всего персистент слоя приложения.
А не жирно ли под каждый bound context свою базу? Или раз уж назвались микросервисами, то и база/хранилище под каждый своя должна быть
А какой смысл в одном хранилище и двух сервисах, если база данных у вас всегда будет бутылочным горлышком ? Просто чтобы наклепать сервисов. Цель микросервисов поддержка, деплоймент и масштабирование, а у вас скажем нужно внести какие-то изменения в один сервис и обновить базу, в результате чего вы будет останавливать второй сервис, только чтобы сделать деплоймент первого.
Эмм... зачем останавливать базу, если будет апдейтиться только конкретная таблица для конкретного микросервиса. Второй микросервис это затронуть не должно.
апдейт таблицы может занимать очень продолжительное время
Oleksandr Nogai
Kostiantyn Chernovol
Denys Poltorak
Alex Koshterek
Vlad Stelmahovsky
flyman
Vlad Stelmahovsky
Grez
minodvesP Vasya
Мокий Парменыч
Vitalij Berdinskih
Roman Rasyak
DNA Exp
Anton Martynenko
Oleksandr Katykhin
Bot Bot
Oleksii Kliukin
Mykola Gurov
Pavel
sooul
Андрей Литвинов
anonymous
Denys Poltorak
Vitalii Sitnikov
Artem Astafyev
Oleg Korol
Артем Перекресний
Igor Kravchenko
Oleksandr Merkulov
Vadim Kopanev
Oleksandr Merkulov
Yegor Chumakov
Włodzimierz Rożkow
Igor Kravchenko
Vadym Liapin
Alex Fogol
Yegor Chumakov
Vladyslav Melnyk
Oleksandr Nogai
Sergius von Bielersee
Włodzimierz Rożkow
Мокий Парменыч
Dmitry
Andriy Maletsky
Dmitry
Victor Mikhaylov
Mykolai Miasnikov
Олексій Пєніє
Dmytro Vorobey
Gennady Dogaev
Bot Bot
Bogdan Shyiak
Дмитро
Valentyn Ponomarenko
Найкращі коментарі пропустити