1. Но зачем тогда отдельный сервис который рулит базами? Не лучше ли обращаться в свою базу непосредственно из сервиса, без прослоек? Меньше оверхед, меньше проблем при последующем разнесении базы на разные сервера
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов
1. Но зачем тогда отдельный сервис который рулит базами? Не лучше ли обращаться в свою базу непосредственно из сервиса, без прослоек? Меньше оверхед, меньше проблем при последующем разнесении базы на разные сервера
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов.
Возникло несколько вопросов:
1. Почему для фасада базы используется отдельный сервис, если у каждого сервиса своя база? Выглядит как непонятный оверхед на пустом месте + слабое место в перспективе (и сложнее будет разносить базы в случае чего)
2. Вы точно уверены что жизенно необходимы по несколько нод каждого микросервиса? Я недавно замерял простые запросы к netcore серверу (вытащить данные из Redis кэша) — он тысячу запросов в секунду пережевывает спокойно. На рабочем ноутбуке, где сам Редис в докере и SQL Express подняты. Т.е. вероятность упереться в базу и/или кривой код на порядок выше. А там без горизонтального масштабирования уже не выйдет. Впрочем, уверен на 99% что это излишне. Вон stackoverflow живут без горизонтального масштабирования, а у них скорее всего нагрузки будут на порядки выше чем у практически любого приложения.
3. Вы точно уврены что данные у микросервисов действительно не пересекаются? Не выйдет ли так что завтра захотят получить агрегат данных из нескольких сервисов?
4. Подключать файл с секретами как-то сложно на вид. Не рассматривали иные альтернативы? Почему файлы секретов в сорс контроле хранятся, если вы всё равно их подключаете отдельно?
5. Давать прямой доступ к микросервисам — на мой взгляд сомнительное решение (в т.ч. с т.з. безопасности). Как я понял, у вас есть клиенты на мобильных приложениях = поддержка разных версий API, т.к. клиентов так просто не заставить обновить приложение. Как вообще реализовано версионирование АПИ (даже не внутри микросервисов, а именно для мобильных клиентов)? Это один из самых волнующих меня вопросов, т.к. универсального рецепта я не знаю.
6. Rabbit MQ используется для всех коммуникаций или нет? Из предложения в статье совсем непонятно. Субъективно, это нужно для асинхронных сообщений (возможно даже с отложенной доставкой) и тех, где важна устойчивость. Для всего остального более чем достаточно обычного хттп.
Так как вы собираетесь решать катастрофу вида «автобус с разработчиками ехавшими на тимбилдинг упал в пропасть»?
Лично мне кажется что останется лишь смириться с тем что разработка станет колом на какое-то время и искать не человека который работал с в точности таким стеком, а с человеком способным въехать в ваш проект, с достаточным опытом в разных фреймворках и проектах. И уж тут точно не стоит нанимать джунов первое время.
А говорить синьор программисту — «извини чувак, меня не колышет что ты работал с похожими фреймворками, меня интересует конкретно этот» — это как-то даже проявить неуважение и таким образом сказать «извини, я совершенно не верю в то что программисты способны обучаться и въезжать в технологии, поэтому мне нужен человек который будет в точности знать именно наш стек, а то что ему надо быстро въезжать в наш проект, так это просто мои тараканы в голове договориться не могут».
Не говоря о том, что если случилась именно катастрофа, то тут уже не приходится долго и нудно перебирать, надо брать первых попавшихся адекватных.
Тем более. Вы должны были выстроить процесс так чтобы они (беды, катастрофы) не случались. И уж точно случайный программист с улицы не будет в силах взять и разрулить всё «вотпрямщас».
Т.е. (реальный пример, хотя и не со мной) приходит к вам человек и вы его спрашивате:
— Вы работали с Git?
— Нет, но я работал с Mercurial
— Извините, но вы нам не подходите.
Что резко выдаёт уровень вашей квалификации как собеседующего. С тем же успехом можно просто фильтры выставить, будет на 2 порядка эффективнее.
Не взлетит.
1. Изрядная часть механизмов не должны работать на 100%. Пример — машины таксистов, которые умирают за крайне быстрый срок.
2. Это будет работать очень недолгое время и в малых коллективах. И даже там бывают такие мелкие и неприятные вещи как «плохо смыл за собой в туалете», что выливается во фрустрацию у кого-то другого. Как это работает — смотрим теорию разбитых окон.
3. Как собираются решать пиковые нагрузки? Когда утром и вечером всем нужны машины, когда после работы всем нужна приставка или компьютер? Это будет или простаивание ресурсов или жуткий дефицит этих самых ресурсов во время пиковых нагрузок.
Да в общем-то тоже ничего странного. Даже те кто тянутся зачастую не могут(не дают по работе)/ленятся делать всё правильно. Особенно когда язык не подталкивает к правильному пути(а зачастую наоборот).
Есть много случаев когда надо «здесь и сейчас», иногда просто лень и очень велик соблазн сделать мелкое изменение вместо рефакторинга этого куска кода(а то и всего проекта).
Все мы люди, и время от времени ошибаемся. Например у нас на проекте есть хорошее правило запускать тесты перед коммитом. Но где-то раз из 20ти я забываю это сделать(чаще всего когда делаю мелкие быстрые фиксы).
Или просто люди не знают как ьможно сделать лучше либо привыкли делать как раньше, им так может быть даже более-менее удобно
В общем, я не очень верю в людей которые никогда не совершают ошибок и пишут в соответствии со всеми правилами хорошего написания кода которые знают. Есть миллион причин чтобы «срезать углы», и многие из них даже объективны
А я ничего странного не вижу.
Будь лично я богом программирования с запредельной памятью и внимательностью, я бы глядишь никогда и не допускал подобных «глупых» ошибок(считаю изрядную часть их простой невнимательностью).
И вот тут как раз более надёжные языки, структуры данных и более высокоуровневые библиотеки типа linq дают огромное преимущество- в них просто бы не ошиблись в инициализации переменной цикла, потому что не стали бы писать цикл, а наваяли бы Select/foreach в котором такая проблема невозможна.
И вообще бы не стали втупую писать в файл, а например сериализовали бы объект/структуру данных.
Они хороши как раз тем что они позволяют избегать тупых ошибок по невнимательности:
1. Во-первых там скрыты детали реализации и код становится чище от них- написано ЧТО делать, а не КАК делать. Соответственно и мест для ошибки становится намного меньше.
2. Во-вторых некоторые высокоуровневые языки(сейчас смотрю F#) делают анализ кода в тех местах где раньше такое не делалось. Там по умолчанию not-null объекты, паттерн-матчинг(навороченный аналог switch-case) просто не скомпилируется если обработаны не все ветви. Т.е. отсекается огромный пласт ошибок еще на этапе компиляции. Вероятность того что программа будет работать и работать правильно амного выше
В общем, я очень понимаю почему программисты тянутся к высокоуровневым языкам и инструментам, допуская при этом глупые ошибки. Именно потому что люди не идеальны, хочется чтобы твой инструмент помогал написать правильный и надёжный софт, а не подставлял очередную возможность выстрелить себе в ногу.
В моем понимании приставка — это очень удобная вещь, которая позволяет поиграть после работы в хорошие игры
Попробуйте открыть для себя Steam.
При наличии нормального интернета всё еще проще чем в любой из консолей- просто жмёшь кнопочку «купить» и стим сам всё закачивает и устанавливает
Ну, дырку довольно быстро закрыли, хакеров застращали. Да и разве были простые способы установки полноценного линукса «для домохозяек» по типу джейлбрейка? А то что это сделают 3.5 хакера сони/МС не слишком расстроит. Проблема будет только в случае простого и массового средства установки альтернативных ОС, а такого скорее всего не сделают
Да нет, у нвидии процессоры есть только мобильные насколько я знаю. А интеловское видео как бы не слишком блещет и явно не подходит для некст-ген консолей.
Ключевое слово в той фразе было «нет»
Честное слово, я не понимаю, как так вышло, что ни Nvidia, ни Intel совсем не участвовали в битве за консоли нового поколения.
Всё просто- у нвидии нет подходящих процессоров, а у интела подходящего видео.
А лепить зоопарк проблемно: 2 чипа дороже, договариваться с двумя поставщиками сложнее и сложнее выбить из них скидки.
Имхо в идеале- вынести в отдельный метод с соответствующим названием. А уже этот метод нормально прокомментировать.
Но суть в том что комментарии придётся читать только если нужно выяснить как он там работает, а не просто в момент когда встречаешь его вызов.
Т.е. что-то типа «PrepareColorValue»(название можно придумать и получше чем у меня), а что там внутри нужно будет смотреть только когда надо действительно разобраться что там такое
Лучше называть методы нормально и код писать понятно, а тотальное комментирование приводит к наплевательскому отношению к их написанию.
В итоге получаем уродцев с автогенерированными комментариями типа
//Builds the Ext
public void BuildExt()
и так постоянно
Зато блин покрытие комментариями 100%, только это блин мусор. А натыкаясь на мусор перестаёшь видеть действительно стоящие комментарии.
Неожиданное и любопытное применение CI.
Всегда было любопытно как сис. администраторы разгребают возможные ошибки в скриптах, а тут такой вариант придумали.
Может быть для кого-то и громоздко, но у меня есть подозрение что оно себя действительно окупает за счет централизованности.
Да легко- протяните руку вперёд и двигайте ей в течении 20 минут туда-сюда постоянно.
Или поднимайте/опускайте руку со стола к монитору в течении нескольких часов с частотой раз в 15 секунд.
Просто вспомните школу, в которой писать что-то больше пары предложений на доске было довольно мучительно.
Нет, парочка маленьких фишек с тачем может и будут неплохи, но в десктопе это не может быть основным способом ввода, и затачивать интерфейс в первую очередь под тач — абсурд.
Metro- взрослый? Отличная шутка.
Этот интерфейс еще пилить и пилить до состояния когда он перестанет вызывать рвотные позывы у половины людей его увидевших, а потом еще пилить чтобы он стал нормально восприниматься на десктопах.
Заодно что-то сделать с привычками пользователей и наконец сделать какое-то различие между интерактивными элементами и просто текстом, потому что зачастую отличить одно от другого на вид невозможно, приходится наводить мышь и догадываться по изменению курсора(это оставили надеюсь?).
Не говоря о том, что интерфейс который требует от разработчиков огромного профессионализма в дизайне, иначе становится неюзабельным — это плохой интерфейс.
Интерфейс Metro можно назвать каким угодно, но никак не взрослым, у него еще миллион детских болезней, с которыми предстоит бороться.
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов
2. А сколько пользователей и какие нагрузки вы ожидаете, чтобы их одновременно не могли потянуть сервисы (при должном уровне написания) способные прожевать тысячи запросов в секунду, но при этом потянула база без горизонтального шардирования. По моему опыту, всё это куда быстрее упрётся в базу.
3. Понятно, спасибо
4. Понятно, спасибо.
5. А как жить с мобильными клиентами? Вы же не можете заставить их всех обновиться в одну секунду
6. А как быть в простом, но крайне реалистичном сценарии «послать в сервис какие-то параметры и получить от него результат». Может у вас своя специфика, но обычно это самый распространённый сценарий использования микросервисов.
1. Почему для фасада базы используется отдельный сервис, если у каждого сервиса своя база? Выглядит как непонятный оверхед на пустом месте + слабое место в перспективе (и сложнее будет разносить базы в случае чего)
2. Вы точно уверены что жизенно необходимы по несколько нод каждого микросервиса? Я недавно замерял простые запросы к netcore серверу (вытащить данные из Redis кэша) — он тысячу запросов в секунду пережевывает спокойно. На рабочем ноутбуке, где сам Редис в докере и SQL Express подняты. Т.е. вероятность упереться в базу и/или кривой код на порядок выше. А там без горизонтального масштабирования уже не выйдет. Впрочем, уверен на 99% что это излишне. Вон stackoverflow живут без горизонтального масштабирования, а у них скорее всего нагрузки будут на порядки выше чем у практически любого приложения.
3. Вы точно уврены что данные у микросервисов действительно не пересекаются? Не выйдет ли так что завтра захотят получить агрегат данных из нескольких сервисов?
4. Подключать файл с секретами как-то сложно на вид. Не рассматривали иные альтернативы? Почему файлы секретов в сорс контроле хранятся, если вы всё равно их подключаете отдельно?
5. Давать прямой доступ к микросервисам — на мой взгляд сомнительное решение (в т.ч. с т.з. безопасности). Как я понял, у вас есть клиенты на мобильных приложениях = поддержка разных версий API, т.к. клиентов так просто не заставить обновить приложение. Как вообще реализовано версионирование АПИ (даже не внутри микросервисов, а именно для мобильных клиентов)? Это один из самых волнующих меня вопросов, т.к. универсального рецепта я не знаю.
6. Rabbit MQ используется для всех коммуникаций или нет? Из предложения в статье совсем непонятно. Субъективно, это нужно для асинхронных сообщений (возможно даже с отложенной доставкой) и тех, где важна устойчивость. Для всего остального более чем достаточно обычного хттп.
Лично мне кажется что останется лишь смириться с тем что разработка станет колом на какое-то время и искать не человека который работал с в точности таким стеком, а с человеком способным въехать в ваш проект, с достаточным опытом в разных фреймворках и проектах. И уж тут точно не стоит нанимать джунов первое время.
А говорить синьор программисту — «извини чувак, меня не колышет что ты работал с похожими фреймворками, меня интересует конкретно этот» — это как-то даже проявить неуважение и таким образом сказать «извини, я совершенно не верю в то что программисты способны обучаться и въезжать в технологии, поэтому мне нужен человек который будет в точности знать именно наш стек, а то что ему надо быстро въезжать в наш проект, так это просто мои тараканы в голове договориться не могут».
Не говоря о том, что если случилась именно катастрофа, то тут уже не приходится долго и нудно перебирать, надо брать первых попавшихся адекватных.
— Вы работали с Git?
— Нет, но я работал с Mercurial
— Извините, но вы нам не подходите.
Что резко выдаёт уровень вашей квалификации как собеседующего. С тем же успехом можно просто фильтры выставить, будет на 2 порядка эффективнее.
1. Изрядная часть механизмов не должны работать на 100%. Пример — машины таксистов, которые умирают за крайне быстрый срок.
2. Это будет работать очень недолгое время и в малых коллективах. И даже там бывают такие мелкие и неприятные вещи как «плохо смыл за собой в туалете», что выливается во фрустрацию у кого-то другого. Как это работает — смотрим теорию разбитых окон.
3. Как собираются решать пиковые нагрузки? Когда утром и вечером всем нужны машины, когда после работы всем нужна приставка или компьютер? Это будет или простаивание ресурсов или жуткий дефицит этих самых ресурсов во время пиковых нагрузок.
Есть много случаев когда надо «здесь и сейчас», иногда просто лень и очень велик соблазн сделать мелкое изменение вместо рефакторинга этого куска кода(а то и всего проекта).
Все мы люди, и время от времени ошибаемся. Например у нас на проекте есть хорошее правило запускать тесты перед коммитом. Но где-то раз из 20ти я забываю это сделать(чаще всего когда делаю мелкие быстрые фиксы).
Или просто люди не знают как ьможно сделать лучше либо привыкли делать как раньше, им так может быть даже более-менее удобно
В общем, я не очень верю в людей которые никогда не совершают ошибок и пишут в соответствии со всеми правилами хорошего написания кода которые знают. Есть миллион причин чтобы «срезать углы», и многие из них даже объективны
Будь лично я богом программирования с запредельной памятью и внимательностью, я бы глядишь никогда и не допускал подобных «глупых» ошибок(считаю изрядную часть их простой невнимательностью).
И вот тут как раз более надёжные языки, структуры данных и более высокоуровневые библиотеки типа linq дают огромное преимущество- в них просто бы не ошиблись в инициализации переменной цикла, потому что не стали бы писать цикл, а наваяли бы Select/foreach в котором такая проблема невозможна.
И вообще бы не стали втупую писать в файл, а например сериализовали бы объект/структуру данных.
Они хороши как раз тем что они позволяют избегать тупых ошибок по невнимательности:
1. Во-первых там скрыты детали реализации и код становится чище от них- написано ЧТО делать, а не КАК делать. Соответственно и мест для ошибки становится намного меньше.
2. Во-вторых некоторые высокоуровневые языки(сейчас смотрю F#) делают анализ кода в тех местах где раньше такое не делалось. Там по умолчанию not-null объекты, паттерн-матчинг(навороченный аналог switch-case) просто не скомпилируется если обработаны не все ветви. Т.е. отсекается огромный пласт ошибок еще на этапе компиляции. Вероятность того что программа будет работать и работать правильно амного выше
В общем, я очень понимаю почему программисты тянутся к высокоуровневым языкам и инструментам, допуская при этом глупые ошибки. Именно потому что люди не идеальны, хочется чтобы твой инструмент помогал написать правильный и надёжный софт, а не подставлял очередную возможность выстрелить себе в ногу.
Попробуйте открыть для себя Steam.
При наличии нормального интернета всё еще проще чем в любой из консолей- просто жмёшь кнопочку «купить» и стим сам всё закачивает и устанавливает
Ключевое слово в той фразе было «нет»
Всё просто- у нвидии нет подходящих процессоров, а у интела подходящего видео.
А лепить зоопарк проблемно: 2 чипа дороже, договариваться с двумя поставщиками сложнее и сложнее выбить из них скидки.
Но суть в том что комментарии придётся читать только если нужно выяснить как он там работает, а не просто в момент когда встречаешь его вызов.
Т.е. что-то типа «PrepareColorValue»(название можно придумать и получше чем у меня), а что там внутри нужно будет смотреть только когда надо действительно разобраться что там такое
В итоге получаем уродцев с автогенерированными комментариями типа
//Builds the Ext
public void BuildExt()
и так постоянно
Зато блин покрытие комментариями 100%, только это блин мусор. А натыкаясь на мусор перестаёшь видеть действительно стоящие комментарии.
Всегда было любопытно как сис. администраторы разгребают возможные ошибки в скриптах, а тут такой вариант придумали.
Может быть для кого-то и громоздко, но у меня есть подозрение что оно себя действительно окупает за счет централизованности.
Или поднимайте/опускайте руку со стола к монитору в течении нескольких часов с частотой раз в 15 секунд.
Просто вспомните школу, в которой писать что-то больше пары предложений на доске было довольно мучительно.
Нет, парочка маленьких фишек с тачем может и будут неплохи, но в десктопе это не может быть основным способом ввода, и затачивать интерфейс в первую очередь под тач — абсурд.
Этот интерфейс еще пилить и пилить до состояния когда он перестанет вызывать рвотные позывы у половины людей его увидевших, а потом еще пилить чтобы он стал нормально восприниматься на десктопах.
Заодно что-то сделать с привычками пользователей и наконец сделать какое-то различие между интерактивными элементами и просто текстом, потому что зачастую отличить одно от другого на вид невозможно, приходится наводить мышь и догадываться по изменению курсора(это оставили надеюсь?).
Не говоря о том, что интерфейс который требует от разработчиков огромного профессионализма в дизайне, иначе становится неюзабельным — это плохой интерфейс.
Интерфейс Metro можно назвать каким угодно, но никак не взрослым, у него еще миллион детских болезней, с которыми предстоит бороться.