Vladislav
Вроде правило двух пицц еще не успело устареть
Duamel
Озон долго существует и порой единственный вариант внедрения новой фичи это дополнительный сервис поверх существующей инфраструктуры, какие то события ловишь, что-то делаешь, что-то генерируешь. Изменять существующие сервисы, которые не всегда на го, а порой на джаве/шарпе не лучший вариант
Aleks
Существенная проблема микросервисной архитектуры, в отличие от монолита, это если бизнес процессы и бизнес логика меняется, то менять за этим количество и задачи микросервисов порой просто невозможно имеющимимя в наличии ресурсами. В результате получается избыточная размытая инфраструктура.
Aleks
Когда идет выбор архитектуры между монолитом, распределенным монолитом, и микросервисами, это не учитывается, потому что микросервисы модно. :)
Миринговин
Существенная проблема микросервисной архитектуры, в отличие от монолита, это если бизнес процессы и бизнес логика меняется, то менять за этим количество и задачи микросервисов порой просто невозможно имеющимимя в наличии ресурсами. В результате получается избыточная размытая инфраструктура.
В монолите ровно так же будут пилить избыточный функционал
Duamel
Монолит часто не поддается масштабированию под нагрузку, приходится пилить микросервисы когда у вас не 100 посетителей в сутки
Aleks
В монолите ровно так же будут пилить избыточный функционал
В монолите проще следовать за бизнес логикой.
Aleks
Миринговин
В монолите проще следовать за бизнес логикой.
Проще или сложнее это совсем другой вопрос. В прямом смысле другой. Избыточный там тоже будет
Aleks
Монолит не позволит канареечный релиз. Монолит не позволит одновременную работу нескольких версий и бесшовное обновление. У монолита тоже куча минусов как у любого подхода.
Vladislav
Мне вот просто страшно когда есть какой-то god entity. Который размазан по сотням микросервисов
Vladislav
И потом концов не сыскать
Aleks
Проще или сложнее это совсем другой вопрос. В прямом смысле другой. Избыточный там тоже будет
Избыточность будет всегда.
Duamel
Мне вот просто страшно когда есть какой-то god entity. Который размазан по сотням микросервисов
Одну точку ответственности вводить. В озоне это решается протобаф моделями и использованием этой модели всеми сервисами, а ответственность лежит на одной команде
Aleks
Привязываться к единому DTO?
Миринговин
Существенная проблема микросервисной архитектуры, в отличие от монолита, это если бизнес процессы и бизнес логика меняется, то менять за этим количество и задачи микросервисов порой просто невозможно имеющимимя в наличии ресурсами. В результате получается избыточная размытая инфраструктура.
Раз избыточность будет всегда, тогда о чем разговор? У вас как-то странно течет мысль. Как у пьяного человека.
Aleks
Раз избыточность будет всегда, тогда о чем разговор? У вас как-то странно течет мысль. Как у пьяного человека.
Вопрос в количестве избыточности. Вы в монолите добавляете функционал под новую бизнес задачу. Добавить микросервис задача более трудоемкая.
Aleks
Раз избыточность будет всегда, тогда о чем разговор? У вас как-то странно течет мысль. Как у пьяного человека.
Смысл катится с темы архитектуры на тему меня? :)
Duamel
Когда одну и ту же сущность использует пара сотен микросервисов - должно быть единое соглашение. Вариант когда формат задаёт исходный сервис кажется приемлемым. (Заказ контролит сервис заказов, а не каждый клепает свой) в любом случае уже после получения данных придется их маппить во внутреннюю сущность, всегда нужно будет что-то добавить, что-то убрать
Aleks
Когда одну и ту же сущность использует пара сотен микросервисов - должно быть единое соглашение. Вариант когда формат задаёт исходный сервис кажется приемлемым. (Заказ контролит сервис заказов, а не каждый клепает свой) в любом случае уже после получения данных придется их маппить во внутреннюю сущность, всегда нужно будет что-то добавить, что-то убрать
Если логика позволяет единым dto меняться между всеми микросервисами это нормальный подход. У нас микросервисы на разных языках, работают с разными задачами, и т.п. Единый dto не получится.
Duamel
Если логика позволяет единым dto меняться между всеми микросервисами это нормальный подход. У нас микросервисы на разных языках, работают с разными задачами, и т.п. Единый dto не получится.
Ну не знаю, в озоне единые дто гоняются между гошными, джава и шарповскими сервисами и норм. Возможно это вопрос к организации межкомандного взаимодействия а не к языкам
Vladislav
Когда одну и ту же сущность использует пара сотен микросервисов - должно быть единое соглашение. Вариант когда формат задаёт исходный сервис кажется приемлемым. (Заказ контролит сервис заказов, а не каждый клепает свой) в любом случае уже после получения данных придется их маппить во внутреннюю сущность, всегда нужно будет что-то добавить, что-то убрать
Это уже больше на распределенный монолит становится похоже. Если сервис заказов отвалится, то отвалятся все сервисы от него зависимые
Aleks
Ну не знаю, в озоне единые дто гоняются между гошными, джава и шарповскими сервисами и норм. Возможно это вопрос к организации межкомандного взаимодействия а не к языкам
Протобаф под все языки есть, хотя у нас больше json. Дело в задачах микросервисов, и архитектуре данных на входе и на выходе. Слишком разные чтоб так стандартизироватся.
Aleks
Это уже больше на распределенный монолит становится похоже. Если сервис заказов отвалится, то отвалятся все сервисы от него зависимые
Да, часто из за избыточных связей микросервисная архитектура теряет плюс плавной деградации. И мы на это нарвались. Разгребаем понемногу...
Duamel
Это уже больше на распределенный монолит становится похоже. Если сервис заказов отвалится, то отвалятся все сервисы от него зависимые
Будут копиться очередь в кафке, но ничего не упадет кроме заказов. Потому что только на этапе сборки нужна зависимость
Duamel
Да, часто из за избыточных связей микросервисная архитектура теряет плюс плавной деградации. И мы на это нарвались. Разгребаем понемногу...
Это если связи прямые образуются. Отделяйте событиями через кафку/другое что-то, тогда можно будет статусной моделью отпавшие сервисы отрабатывать - отправили событие - статус в обработке. Получили событие - обработано.
Aleks
Это если связи прямые образуются. Отделяйте событиями через кафку/другое что-то, тогда можно будет статусной моделью отпавшие сервисы отрабатывать - отправили событие - статус в обработке. Получили событие - обработано.
У нас много ситуаций когда данные нужны быстро "онлайн", их ждут на коннекте, кафка тут не помошник. Висит какбы транзакция по цепочке микросервисов. Кафка тоже есть как service bus.
Aleks
По этой причине микросервисы не могут отдать конект к базе в пул, дофига коннектов висит. И приходится использовать PgBouncer.
Aleks
Но сокращается критичное время ответа системы.
Duamel
Много сервисов - одна база?
Aleks
Худо бедно пытаемся следовать основам микросервисной архитектуры. :)
Duamel
Выглядит как архитектурная задача, вполне выполнимая. Всегда есть и инмемори кэши и куча других способов решить проблему. Кстати несколько похожие проблемы предлагают решать на архитектурном этапе в мэил
Aleks
Выглядит как архитектурная задача, вполне выполнимая. Всегда есть и инмемори кэши и куча других способов решить проблему. Кстати несколько похожие проблемы предлагают решать на архитектурном этапе в мэил
Редисы инмемори в системе есть тоже. И сильно кеширующие монги. :)
Aleks
И даже была идея вместо куска кафки использовать редис, но не помню сделали или нет, это джависты, мы к ним с питонистами глубоко не лезем. Там своя атмосфера. :)
Dima
Я сильно извиняюсь, а они объясняют нахрена так делают?
Аналогия.
18 000 классов Object-C в приложении для Facebook, 429 разработчиков работающих над месенджером.
Exhibit A: “iOS can’t handle our scale”
Aleks
Неудивительно что Маск придя в Твитер офигел от избыточности. :)
Aleks
Причем такая избыточность всей IT устраивает всех кроме бизнеса. :)
Anton
Бедный бизнес, все его обижают, а он нечего не может с этим поделать (
Aleks
Бедный бизнес, все его обижают, а он нечего не может с этим поделать (
Не, Твитер не бедный. :)
Aleks
Бедный бизнес, все его обижают, а он нечего не может с этим поделать (
Это скорее проблема всей цивилизации, с усложнением IT сферы с каждым годом снижается общий уровень квалификации. Также толпы вайтишников. Ну и сам бизнес хитроделанный типа: "Вот все лохи для архитектуры берут в штат архитекторов и сеньеров, деньги теряют, а я щас как джунов наберу..." :)))
Vladislav
Аналогия.
18 000 классов Object-C в приложении для Facebook, 429 разработчиков работающих над месенджером.
Exhibit A: “iOS can’t handle our scale”
Это типо не имей 18000 классов, а имей 18000 микросервисов?
Aleks
Причем я тут вакансию видел, почасовая оплата, цена в час ниже зарплаты джуна, ищут мидла, и хотят чтоб он архитектуру разработал, заложил основы будущего проекта . :)
Anton
Причем я тут вакансию видел, почасовая оплата, цена в час ниже зарплаты джуна, ищут мидла, и хотят чтоб он архитектуру разработал, заложил основы будущего проекта . :)
Это всегда так было. Если открыть вакансию сисадмина в малой конторе, там будет за 30к в месяц. С требованием эникейства, знание стека ОСИ, админство Актив Диретори, сервера на линухе, видеонаблюдение, прокладка лвс + сайт и 1С.
Владимир
Это уже больше на распределенный монолит становится похоже. Если сервис заказов отвалится, то отвалятся все сервисы от него зависимые
А тут два стула - или получаешь распределенный монолит и минимум синхронизаций или добро пожаловать делай синхронизацию/кеши с мастер-данными на 200 млн товаров
Владимир
Практика показывает, что кеши создают больше проблем, чем «распределенный монолит», поэтому их в озоне не любят
Vladislav
А тут два стула - или получаешь распределенный монолит и минимум синхронизаций или добро пожаловать делай синхронизацию/кеши с мастер-данными на 200 млн товаров
Ну хз, много умных людей книги писали, на конференциях выступали, практики описывали, паттерны. А все равно все через жопу сделали
Владимир
Ну хз, много умных людей книги писали, на конференциях выступали, практики описывали, паттерны. А все равно все через жопу сделали
Кажется, озон запилить сложнее, чем книжку написать и на конференции выступить.
Практика бьет теорию
Aleks
Ну хз, много умных людей книги писали, на конференциях выступали, практики описывали, паттерны. А все равно все через жопу сделали
Есть факт, что IT сфера настолько широка и многогранна, что в ней не существует идеальных решений на все случаи жизни. Все доклады и книги описывают применения некой методы или инструмента для некого сферического случая в вакууме (чтоб было понятно), но в реальности такого случая не бывает. Как и не бывает идеального кода без ошибок и т.п.
Владимир
Есть факт, что IT сфера настолько широка и многогранна, что в ней не существует идеальных решений на все случаи жизни. Все доклады и книги описывают применения некой методы или инструмента для некого сферического случая в вакууме (чтоб было понятно), но в реальности такого случая не бывает. Как и не бывает идеального кода без ошибок и т.п.
А еще вы обычно вообще не знаете, что делал автор книги/выступающий на конференции до того, как ее написать. Может, он инженер херовый, а писатель/оратор хороший.
Vladislav
Кажется, озон запилить сложнее, чем книжку написать и на конференции выступить.
Практика бьет теорию
Наверное для того чтобы чтото большое и сложное не было большим и сложным, его декомпозируют во чтото маленькое и простое. И вот я к тому что это чтото маленькое можно делать по правилам, а можно по зову сердца
Владимир
Наверное для того чтобы чтото большое и сложное не было большим и сложным, его декомпозируют во чтото маленькое и простое. И вот я к тому что это чтото маленькое можно делать по правилам, а можно по зову сердца
У озона есть набор правил и инструментов, которые позволяют делать вещи единообразно и массово.
На практике - этого достаточно.
Подходить к задачам исключительно шаблонно, причем, получая шаблоны исключительно извне - это не признак большого ума.
Aleks
Возможно некие фреймворки, или договор между командами загоняют в некие рамки не на благо архитектуры. Встречал такое. Типа выйдет конечно говно, но не нарушим договор. :)
Игорь
Здравствуйте, подскажите пожалуйста, если за плечами сейчас два вводных курса на степике по Golang, что лучше всего делать дальше, чтобы увеличить вероятность быстрее найти стажерскую или джуновскую позицию?
Aleks
Типа чтоб следовать правилам обмена, берем данные в микросервис, валидим, а потом в nil... :))
Alexey
Aleks
Здравствуйте, подскажите пожалуйста, если за плечами сейчас два вводных курса на степике по Golang, что лучше всего делать дальше, чтобы увеличить вероятность быстрее найти стажерскую или джуновскую позицию?
На джуновскую позицию только на удачу, типа в сбер и т.п. Такто джун это не тот кого учат за деньги компании, а кто может компании денег заработать решив задачу бизнеса.
Pavel
Dima
Здравствуйте, подскажите пожалуйста, если за плечами сейчас два вводных курса на степике по Golang, что лучше всего делать дальше, чтобы увеличить вероятность быстрее найти стажерскую или джуновскую позицию?
Напишите какой либо собственный проект. Который можно показать.
Lulztime
Напишите какой либо собственный проект. Который можно показать.
который не стыдно показать))
Dima
Это вторично. Просто чтоб хоть что-то было.
Aleks
В том и проблема, что джун пишет свой PET, потом показывает код и его сразу не берут. :)
Aleks
Иногда проще если просят ссылку на гит дать &git. :)))
Alexey
ни разу никто не смотрел и не спрашивал никаких личных проектов
Aleks
У меня был собес давно и не джуном. Там попросили накидать архитектуру проекта с нуля, а потом сказали что не сработаемся потому что у них другая архитектура устоялась. :) Ее мне не показывали, но потом видя я бы легко мог ей следовать. :))) Такие странные собесы бывают.
Alexey
откликайся на вакансии, проходи собеседования.
всё. больше ничего не нужно.
ну, разве что от проваленых собесов для себя усваивай что-нибудь, заполняй пробелы и продолжай дальше.
Aleks
И главное понимать, что с другой стороны на собесах дофига странностей, и не всегда проблема в кандидате.
Dima
И главное понимать, что с другой стороны на собесах дофига странностей, и не всегда проблема в кандидате.
Точное и важное замечание.
пока
Aleks
У нас так с 200 ответом на ошибку)
О, это еще та тема. :)) Теоритически если по самому http ошибки не было, то одни считают что даем всегда двести, а другие например 4xx. Причем это где как делают на Rest и на rpc.
Emin Zalaev
В том и проблема, что джун пишет свой PET, потом показывает код и его сразу не берут. :)
Когда и где от джунов ждут хороший код?
Aleks
Когда и где от джунов ждут хороший код?
Может работодатель хитроумный, и думает что он щас джуна возмет с уровнем как мидла. :) Таких кстати много. :)
Emin Zalaev
Без опыта работы?
Emin Zalaev
Если берут с опытом, то можно ждать, думаю
Emin Zalaev
Но а так это конечно оптимистичные ожидания