|
|
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton Давай смягчим это утверждение. Пускай будет не SPOF, но нечто, декларирующее устойчивость бизнеса, в условиях когда часть сервисов находятся в down-time. Про БД мы такое сказать не можем. Если датацентр упал (вследствие пожара или землетрясения) - то и все сервисы - недоступны. можем. особливо про оракл, где standby нода в соседнем здании вполне норма. mysql так вообще очень давно без репликации не видел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 10:56 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 mayton Давай смягчим это утверждение. Пускай будет не SPOF, но нечто, декларирующее устойчивость бизнеса, в условиях когда часть сервисов находятся в down-time. Про БД мы такое сказать не можем. Если датацентр упал (вследствие пожара или землетрясения) - то и все сервисы - недоступны. можем. особливо про оракл, где standby нода в соседнем здании вполне норма. mysql так вообще очень давно без репликации не видел. Standby - это справедливое замечание. Однако, я задам вопрос о практике этого применения. Как говорят в физике - если явление редко - то этим можно пренебречь. Если там где стоит RAC - не ставят Standby - то практика подобного применения не выражена. Соотв. мы говорим о том что существует в теории но на практике не используется. Про MySQL - ничего не скажу. Не знаком с их технологиями. Однако для MySQL я-бы задал вопрос о том существует ли коробочная конфигурация для автоматического переключения БД на резервную? Или должен сидеть индус который нажимает на кнопочку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:08 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton Давай смягчим это утверждение. Пускай будет не SPOF, но нечто, декларирующее устойчивость бизнеса, в условиях когда часть сервисов находятся в down-time. Про БД мы такое сказать не можем. Если датацентр упал (вследствие пожара или землетрясения) - то и все сервисы - недоступны. Есть "книжка" такая, называется ITIL, я ее изучил в 2006 году и сдал экзамены, с тех пор там еще вышло несколько редакций, но в целом ничего не изменилось. "Датацентр упал" - это называется Continuity Management (не путать с Availability Management), так вот, Continuity Management - это уровень CIO и CEO, а не бичей, клепающих микросервисы на коленке - никто в здравом уме этим бичам такое не доверит, хотя текущая тенденция говорит о том, что в CIO поперли дебилы, которые даже книжку по профессии прочесть не в состоянии . Ну да хрен с ним, в случае нормального предприятия, когда внедряется новый сервис, идет оценка потенциальных угроз, влияния на бизнес, способов их устранения, требуемые бюджеты и прочее, и в итоге у сервиса фиксируется SLA/OLA, в случае же микросервисов получается так, что любое обновление может привести к полному и безоговорочному фиаско, просто потому, что ответственность по обеспечению непрерывности и доступности была делегирована какому-то бичу с улицы (условно разработчик решил что так делать лучше/проще, понаписал говнокода, оно тесты прошло и ушло в прод) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:30 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton существует ли коробочная конфигурация для автоматического переключения БД на резервную? Или должен сидеть индус который нажимает на кнопочку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:32 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton Как говорят в физике - если явление редко - то этим можно пренебречь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:33 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов Есть "книжка" такая, называется ITIL, я ее изучил в 2006 году и сдал экзамены, с тех пор там еще вышло несколько редакций, но в целом ничего не изменилось. "Датацентр упал" - это называется Continuity Management (не путать с Availability Management), так вот, Continuity Management - это уровень CIO и CEO, а не бичей, клепающих микросервисы на коленке - никто в здравом уме этим бичам такое не доверит, хотя текущая тенденция говорит о том, что в CIO поперли дебилы, которые даже книжку по профессии прочесть не в состоянии . Ну да хрен с ним, в случае нормального предприятия, когда внедряется новый сервис, идет оценка потенциальных угроз, влияния на бизнес, способов их устранения, требуемые бюджеты и прочее, и в итоге у сервиса фиксируется SLA/OLA, в случае же микросервисов получается так, что любое обновление может привести к полному и безоговорочному фиаско, просто потому, что ответственность по обеспечению непрерывности и доступности была делегирована какому-то бичу с улицы (условно разработчик решил что так делать лучше/проще, понаписал говнокода, оно тесты прошло и ушло в прод) Наверное ты только что ответил на главный вопрос топика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:37 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов mayton существует ли коробочная конфигурация для автоматического переключения БД на резервную? Или должен сидеть индус который нажимает на кнопочку. Это - тоже полезная синергия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 11:39 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton H5N1 пропущено... можем. особливо про оракл, где standby нода в соседнем здании вполне норма. mysql так вообще очень давно без репликации не видел. Standby - это справедливое замечание. Однако, я задам вопрос о практике этого применения. Как говорят в физике - если явление редко - то этим можно пренебречь. Если там где стоит RAC - не ставят Standby - то практика подобного применения не выражена. Соотв. мы говорим о том что существует в теории но на практике не используется. ни разу не видел RAC без Standby(или аналога на уровне дискового массива), т.к обычно если рак - то достаточно серьезно, а тогда и стендбаем никто пренебрегать не будет. часто даже не соседнее здание, а соседний город. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 12:07 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов в случае же микросервисов получается так, что любое обновление может привести к полному и безоговорочному фиаско, просто потому, что ответственность по обеспечению непрерывности и доступности была делегирована какому-то бичу с улицы (условно разработчик решил что так делать лучше/проще, понаписал говнокода, оно тесты прошло и ушло в прод) вы ИТ где-то в Урюпенске изучали ? почему у микросервисы обязаны отменять продукт овнера и дробить ответсвенность ? а что с двухзвенкой oracle forms ? там две компоненты, в Урюпенске их тоже по отдельности в прод пускают без единого ответсвенного ? mayton Про MySQL - ничего не скажу. Не знаком с их технологиями. Однако для MySQL я-бы задал вопрос о том существует ли коробочная конфигурация для автоматического переключения БД на резервную? Или должен сидеть индус который нажимает на кнопочку. у нас индусы как раз для переключения оракла нужны, из-за кастрации standard едишенов, коих в конторе десятки. у mysql у нас какой-то peacemaker переключает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 12:27 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 вы ИТ где-то в Урюпенске изучали ? почему у микросервисы обязаны отменять продукт овнера и дробить ответсвенность ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 13:06 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 у нас индусы как раз для переключения оракла нужны, из-за кастрации standard едишенов, коих в конторе десятки. у mysql у нас какой-то peacemaker переключает. А. Нашел. Pacemaker называют. Читаю вики. Использует Corosync Cluster Engine. Есть ли в нём кворумы и децентрализованное принятие решений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 14:34 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Мне всегда была подозрительна концепция микросервисов применительно к statefull-объектам вообще и к БД в частности. Я так вижу, что декларируемая микросервисной архитектурой легкость deployment и изолированность доработок хороши для stateless, но никак не для statefull, где требуется согласованность структур данных и всего завязанного на эти структуры прикладного кода. С другой стороны, микросервисы для меня что-то из серии простоты, которая "хуже воровства" - избавляя разраба от тяжких размышлений о системе в целом этот подход просто выбрасывает за борт сложность взаимосвязей компонент системы. Как избежать развала системы после микро-распила? В частности - как выявлять конфликтующие "изолированные" доработки разных "микро"? Как обеспечить согласованность данных в слабо связанной системе? Как быть с резервным копированием и согласованным восстановлением при сбоях сотен отдельных микробазулек? В микросервисном подходе вообще возможно хоть как-то гарантировать целостность данных в масштабе системы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 14:56 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Применительно к данному топику (к распливанию уже работающей БД) я тоже не согласен. Скорее всего пострадают joins. А если не пилить базу тогда принцип low-coupling/high-cohession не достигается. Зачем тогда вообще начинать? Но если создавать новую систему - вроде туристического букинга билетов, гостиниц, шаровых машин - то тогда получается вполне себе красиво. За каждую часть процесса отвечает свой микро-сервис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 15:15 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mayton А. Нашел. Pacemaker называют. Читаю вики. Использует Corosync Cluster Engine. Есть ли в нём кворумы и децентрализованное принятие решений? есть. andrey_anonymous Мне всегда была подозрительна концепция микросервисов применительно к statefull-объектам вообще и к БД в частности. Я так вижу, что декларируемая микросервисной архитектурой легкость deployment и изолированность доработок хороши для stateless, но никак не для statefull, где требуется согласованность структур данных и всего завязанного на эти структуры прикладного кода. С другой стороны, микросервисы для меня что-то из серии простоты, которая "хуже воровства" - избавляя разраба от тяжких размышлений о системе в целом этот подход просто выбрасывает за борт сложность взаимосвязей компонент системы. Как избежать развала системы после микро-распила? В частности - как выявлять конфликтующие "изолированные" доработки разных "микро"? Как обеспечить согласованность данных в слабо связанной системе? Как быть с резервным копированием и согласованным восстановлением при сбоях сотен отдельных микробазулек? В микросервисном подходе вообще возможно хоть как-то гарантировать целостность данных в масштабе системы? примитивный взгляд. реально в бизнес системах лишь крошечная часть по настоящему требует абсолютной согласованности. я не видел тру микросервисов, но видел как избавлялись / выпиливали куски и ораклового монолита. например для веб-портала клиентов сделали solr индекс и mysql. получили профит, нагрузка на оракл в разы снизилась и угроза аппгрейда лицензий миновала. взять алиэкспрес и заказы, чё-то я сомневаюсь, что данные по заказам пользователь в риалтайме видит. сто балов такой-же асинхронный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 15:51 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 примитивный взгляд. реально в бизнес системах лишь крошечная часть по настоящему требует абсолютной согласованности. я не видел тру микросервисов, но видел как избавлялись / выпиливали куски и ораклового монолита. например для веб-портала клиентов сделали solr индекс и mysql. получили профит, нагрузка на оракл в разы снизилась и угроза аппгрейда лицензий миновала. взять алиэкспрес и заказы, чё-то я сомневаюсь, что данные по заказам пользователь в риалтайме видит. сто балов такой-же асинхронный индекс. но это будет даже в обратку работать, если из микросервисов будут монолит делать - причём, даже с большим эффектом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 18:47 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Sayan Malakshinov ох, да я вообще хотел бы увидеть хоть один реальный, не надуманный пример, когда вынос логики из базы на апп.сервер реально поможет снизить нагрузку Но подавляющее большинство подобных JAVA клепателей ничего не знают что блокировки и уровни изоляций и тем не менее их сервисы работают и как-то даже удовлетворяют потребности какого-то бизнеса. Зачем тогда заморачиваться? Я не говорю что у этого подхода есть плюсы в снижении нагрузки, но есть своя ниша говноподелок. Другой вопрос - warehouse. Во-первых для хранилищ оказывается иногда вообще выгоднее от Оракла уйти (и не только из-за стоимости). Здесь его ACID и прочие навороты не так уж критичны. Можно вспомнить, что идеал может быть слишком дорог и какие-то два из трех наиболее важны, а где-то можно пойти на компромисс - CAP theorem . И выбрать себе какую-то MPP . ! Во-вторых даже если пока хранилище крутится на Оралке, и есть внешний мощный ETL движок, то может оказаться что логику в движке организовать дешевле (да, это означает что данные сначала фетчаться, потом трансформируются, потом заливаются обратно). Нет чудаковатых ограничений Оракла на 2GB *_area_size с последующим уходом в темп (не надо тут вспоминать про _ параметры плиз, все равно нормально не взлетает). Не надо генерить redo. Упал ETL - ну и фиг с ним. Логи работы остались, проанализируем и повторим снова. Не надо обеспечивать уйму прочих структур и процессов Оракла для того же ACID. PS. Если чо, прямой ответ на вопрос после "!". До этого лирическое отступление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 20:06 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 реально в бизнес системах лишь крошечная часть по настоящему требует абсолютной согласованности. ...видел как избавлялись / выпиливали куски и ораклового монолита. например для веб-портала клиентов сделали solr индекс и mysql. получили профит Опасаюсь, что кэш веб-портала как раз и есть одна из тех крошечных частей, которая не требует согласованности в системах с "ответственным вистом", если понимаете о чем я. А так да, взгляды у меня самые примитивные - не поспоришь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2021, 20:28 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов mad_nazgul Ну использовать на проде БД в docker - ИМХ такая себе идея. "Так себе", т.к. "чтобы что?!" Принцип докера и микросервисов в том что "быстро поднятое не считается упавшим" и горизонтальное масштабирование. Или грубо говоря нужно чтобы микросервис был стейтлесс. А БД по определению стейтфулл. А горизонтальное масштабирование решается через кластер. В докер можно засунуть всё что угодно, но смысла я лично не вижу. Может он есть, но для БД, пока меня никто не убедил, что это надо делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 08:41 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов есть мнение что кто-то что-то "не договаривает", вся эта история про пространства имен и пр. работает _только_ из линукса, больше нигде она не работает: в MS крутится линусковая виртуалка, в OS X - тоже виртуалка, поэтому с рабочего десктопа до докеровского окружения толком достучаться нельзя (попробуй-те ради развлечения запустить отладку PL/SQL в SQL Developer), а для меня "возможность запускать тесты на декстопе" - это в первую очередь возможность отладки, которая по сути в докере-то и отсутствует, т.е. или кто-то на самом деле никакие интеграционные тесты не пишет, либо эти интеграционные тесты никакие не интеграционные и не тесты. Вот! Поэтому я против использование ХП и триггеров. :-) Т.к. нет на данный момент удобного инструментария для автоматического тестирования. Почему докер удобен для тестирования для меня. Я использую БД как хранилище данных. А внутри докера легко поднять БД с нужным набором данных и конфигурацией. При этом внутри докера лично мне ничего не надо тестировать/отлаживать и пр., т.к. считается что данные валидны и протестированы. <:o) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 08:48 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Мне всегда была подозрительна концепция микросервисов применительно к statefull-объектам вообще и к БД в частности. Я так вижу, что декларируемая микросервисной архитектурой легкость deployment и изолированность доработок хороши для stateless, но никак не для statefull, где требуется согласованность структур данных и всего завязанного на эти структуры прикладного кода. С другой стороны, микросервисы для меня что-то из серии простоты, которая "хуже воровства" - избавляя разраба от тяжких размышлений о системе в целом этот подход просто выбрасывает за борт сложность взаимосвязей компонент системы. Как избежать развала системы после микро-распила? В частности - как выявлять конфликтующие "изолированные" доработки разных "микро"? Как обеспечить согласованность данных в слабо связанной системе? Как быть с резервным копированием и согласованным восстановлением при сбоях сотен отдельных микробазулек? В микросервисном подходе вообще возможно хоть как-то гарантировать целостность данных в масштабе системы? Ну например сага или лямбда-архитектура Ну а так. Микросервисная архитектура эта попытка перенести сложность на "уровень вверх". Т.е. сами микросервисы внутри простые, а вот их взаимодействие между собой сложное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 08:57 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
mad_nazgul Ну например сага или лямбда-архитектура Ну а так. Микросервисная архитектура эта попытка перенести сложность на "уровень вверх". Т.е. сами микросервисы внутри простые, а вот их взаимодействие между собой сложное. Спасибо за ссылки. Что касается саги, то, пмсм, это шляпа. - Не любое воздействие можно легко скомпенсировать (тривиальный пример - удаление, более сложные - разноообразная агрегатчина и прочие необратимые действия), что налагает ограничения на применимость. - Объем разработки удваивается (по каждому кейсу dml требуется разработать два воздействия). - в отсутствие координатора восстановление при сбое может стать забавной забавой. Лямбда же у меня никогда с микросервисами не ассоциировалась - скорее с большими хранилищами. Возможно, не прав - почитаю. Про сложность взаимодействий я отдельно переживаю - как управлять, на каком уровне? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 09:48 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Спасибо за ссылки. Что касается саги, то, пмсм, это шляпа. - Не любое воздействие можно легко скомпенсировать (тривиальный пример - удаление, более сложные - разноообразная агрегатчина и прочие необратимые действия), что налагает ограничения на применимость. - Объем разработки удваивается (по каждому кейсу dml требуется разработать два воздействия). - в отсутствие координатора восстановление при сбое может стать забавной забавой. Лямбда же у меня никогда с микросервисами не ассоциировалась - скорее с большими хранилищами. Возможно, не прав - почитаю. Про сложность взаимодействий я отдельно переживаю - как управлять, на каком уровне? объем разработки удваивается, команды утраиваются, манагеры в проектах и между ними наверно по экспоненте приростают, но какое это имеет значение ? жрет то все это в итоге на порядок-два меньше, чем лицензировать оракл и пытаться процессить данные в самом дорогом и практически не умеющем параллелится ресурсе. pl/sql застрял в 90х, за 15 лет почти не развивается, притока спецов нет, самые вменяемые уходят в более динамично развивающиеся платформы, где кстати все крутиться вокруг stateless и параллельности (ровной противоположности идеологии pl/sql). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 11:35 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
H5N1 объем разработки удваивается, команды утраиваются, манагеры в проектах и между ними наверно по экспоненте приростают, но какое это имеет значение ? И действительно, какое? Микросервисы, если не изменяет склероз, завоевывали мир ровно по той же схеме, что и все предыдущие вундерконцепции, от разделяемых библиотек через ООП к СОАПу и далее - "облегчает разработку, снижает timetomarket, экономит деньги". Впрочем, как всегда :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 12:03 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Спасибо за ссылки. Что касается саги, то, пмсм, это шляпа. - Не любое воздействие можно легко скомпенсировать (тривиальный пример - удаление, более сложные - разноообразная агрегатчина и прочие необратимые действия), что налагает ограничения на применимость. - Объем разработки удваивается (по каждому кейсу dml требуется разработать два воздействия). - в отсутствие координатора восстановление при сбое может стать забавной забавой. А кто сказал, что будет легко?! :-) На сколько я понял, с сагой, мы просто забиваем, что у нас данные должны быть согласованы. Т.е. они будут согласованы и не противоречивы, но потом. И передается не управляющее воздействие, а состояние(данные) той или иной сущности. За агрегатчину, как раз отвечает лямбда-архитектрура andrey_anonymous Лямбда же у меня никогда с микросервисами не ассоциировалась - скорее с большими хранилищами. Возможно, не прав - почитаю. Про сложность взаимодействий я отдельно переживаю - как управлять, на каком уровне? Это как бы "второй вопрос", на который обычно "не отвечают". А так. Проектируем микросервисы, которые как стейтлесс возвращают всегда одно и то же при одинаковом входе. Ну а дальше из них формируем некую цепочку бизнес-логики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 14:34 |
|
||
|
Зачем все пилят монолит?
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous И действительно, какое? Микросервисы, если не изменяет склероз, завоевывали мир ровно по той же схеме, что и все предыдущие вундерконцепции, от разделяемых библиотек через ООП к СОАПу и далее - "облегчает разработку, снижает timetomarket, экономит деньги". Впрочем, как всегда :) Ну как бы - да. Микросервис написать гораздо легче, чем делать изменения в монолитном приложении. Мое мнение, все что не делается за пару спринтов микросервисом называться не может. :-) Т.е. "сила" в том, чтобы вместо изменять, можем просто "переписать всё нафиг". С монолитом такой фокус проделать трудно. С микросервисами проще (читай дешевле). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2021, 14:38 |
|
||
|
|
start [/forum/search_topic.php?author=Alexander+Zdanevich&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
129ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 332ms |
| total: | 602ms |
| 0 / 0 |
