Даже опытным специалистам бывает не просто определить, часть ли это контракта и где границы коспозиции. Но самое главное, Я бы сказал, даже не это. Регулярно бывают ситуации, когда контракт сформулирован правильно, с этим все согласны, а потом прилетают такие изменения в требованиях, которые никто не предполагал. Ну и текущие абстракции никто не отменял ведь.
1 - в статье не описано, какие задачи должна решать написанная система, но возможно что юнит-тесты им и не нужны. Для тестирования юзер флоу зачастую достаточно api тестов, а юнит-тесты используются для покрытия редких участков сложного кода, содержащего алгоритмические вычисления, а также в качестве документации для валидации входных данных.
Удивительно, сразу после написания комментария пришло письмо от М.Видео - Выписка по бонусному счету.
1) Улучшенный дизайн выглядит подозрительно с точки зрения создания юнит-тестов. У вас есть юнит-тесты? Не интеграционные, а именно юнит-тесты. Написание тестируемого кода накладывает "ограничения" на дизайн. Отсутствие репозитория сразу бросается в глаза, как это тестировать.
2) Декоратор, который приведен в статье мог использоваться для "быстрого фикса", с последующим рефакторингом, то есть возвращению обратно к простому дизайну.
3) Стиль дизайна определяется плотностью запросов реализации новых фич (требоаний, реквариментов), выше плотность - больше паттернов/компонентов. Чем размельченнее код, тем время внедрения новых фич в код более линейно, или даже еще лучше. Характер заказчика играет в этом роль.
4) Граница между разными сервисами проходит там, где можно выделить независимую и заменяемую часть логики.
5) "потому что ты не знаешь непосредственно, какой конкретно код будет исполняться. Тебе сначала нужно проверить, какие реализации существуют в интерфейсе, а затем разобраться, какая конкретно применяется во время исполнения." - интерфейс вводится для того, чтобы "не знать", какая будет реализация - важен контракт использования.
Если немного подумать. то зависимости между микросервисами это тот же спаггети код монолита, которые точно также нуждаются в отладке и могут резко вырасти в сложности и превратитьтся в зиккурат.
Красавцы. Все делают микросервисы, чтобы легче управлять зависимостями и тестировать отдельные модули. А вы собрали монолит, который в себе будет содержать дополнительную сложность.
Истина где-то посередине. С одной стороны 5 слоев абстракций конечно во вред. И лишние интерфейсы не нужны. С другой стороны они позволяют избежать спагетти кода, и внятно и коротко описать и протестировать логику работы, прочитать и быстро понять код.
Но при проектировании все не учтешь. Потому сначала пишется решение которое работает, а потом причесывается и разбивается на блоки так, чтобы было легко дальше поддерживать.
а еще, из живого примера, старые могут уйти сами. Недавно ушел разраб, с 30и летним опытом, т.е. собственно он один знает что зачем в системе, по причине "я устал объяснять, что "это не будет работать, и почему"". Свежие светлые идеи очень часто валят всю систему или большие её части, в случае, когда "специалист", не в курсе, что в компании существуют другие подразделения, работающие с системой по другому
Неопытный разработчик всегда имеет полярную точку зрения на абстракции - он или их избегает, или фанатично применяет.
Абстракции это простейший инструмент для описания неопределенности. Если человек пишет код для одной и той же предметной области несколько лет, и видит повторяемость-порядок, то немудрено, что это приводит к тому что абстракции становятся избыточны и появляется "простой код". Для разработчика главное, что бы его не деформировало это, иначе он может "сломаться" и посчитает, что "простой код" можно проецировать на любую предметную область. Вывод: Все очень относительно, я бы на вашем месте не был так категоричен на счет абстракций.
Только обычно мало у кого, как у автора статьи, хватает храбрости удалять старые ненужные абстракции и паттерны, написанные неопытными разработчиками много лет назад. Так они и существуют засоряя код.
Ну в принципе всё правильно. Абстракции ради абстракций и паттерны ради паттернов - это те вещи, которые сразу выдают неопытных разработчиков.
Но обычно с годами это проходит. После Х лет опыта люди снова начинают писать простой код. И, как правило, он работает намного быстрее и надёжнее нагромождений абстракных фабрик декораторов шаблонных обсерверов :)
NVMe вроде хвалят за низкую латентность. Если ядро часто переключает контекст и латентность переключения много больше NVMe, то подозреваю, что наоборот, разница между SATA SSD и NVMe будет труднее обнаружить.
Кстати, вот пример сравнения Baremetal https://elibsystem.ru/node/503 с Hyper-V, KVM на SATA SSD c древним контроллером, но и там довольно хорошо видна сильная зависимость производительности от гипервизора.
Вообще надо понять что тестировать-то хочется.
Абстрактную производительность NVMe? Производительность NVMe в Hyper-V в одиночной ВМ (не убивает ли оверхед Hyper-V низкую задержку NVMe)? Производительность NVMe при большом количестве ВМ, все из которых одновременно генерируют нагрузку по сравнению с SATA (качественное сравнение есть ли разница при большой нагрузке в условиях конкуренции кучи ВМ за CPU и NVMe)? Во всех трех случаях очевидно методика тестирования разная.
Более того, от того пишутся ли данные синхронно или последовательно тоже результаты бенчмарка зависят, а тут сюрприз, SSD часто нужны для баз данных, а РСУБД пишут часто последовательно (потому-что в журнал) малым количеством потоков с частыми fsync. Т.е. базы данных даже близко не выдают максимально возможные IOPS-ы на запись.
Дальше надо понимать, что NVMe хороши низкой задержкой. Но! Но когда 100500 ВМ генерируют параллельно нагрузку и утилизируют SSD в полку, общая пропускная способность конечно будет высокой (у SSD чем больше одновременных потоков - тем больше IOPS и мегабайт), но вот задержки начнут сильно нарастать, а в статье задержки вообще не представлены! Т.е. при миллионе IOPS задержки какие? Вот для примера про латентность от Intel:
Поэтому зная, что все зависит от всего (производительность от нагрузки случайная/последовательная, размера кластера, как часто fsync шлется, размера очереди, конкуренции за CPU множества ВМ, драйверов, ФС, гипервизора, writeback, способности ВМ читать из ОЗУ вместо диска из-за виртуализации и т.д.) надо, ну если хочется во всех этих аспектах посмотреть что происходит, делать не один тест, а на каждую из задач по тесту.
Естественно, синтетика с большим количеством очередей может совершенно не походить по профилю нагрузки на поведение баз данных. Так что логично поинтересоваться у клиентов какие базы гонять собираются и побенчмаркать базы на NVMe/SATA и посмотреть, есть ли разница. Естественно начинаются приколы, что SATA будет контроллер использовать и он тоже может и свои настройки иметь и задеркжи и т.д.
Итого: непростое это дело производительность дисковой подсистемы измерять!
Ну а Вы сильно недооцениваете. Про микроскоп замечательно, оцените сами время изучения чипа 20 слоев размера 20х30 мм. Или книжку покажите, где опыт разработки таких чипов описан. Все немного проще - у команды 10 лет опыта разработки физдизайна в среднем.
Вы говорите про микроархитектуру процессора ("поплясать") или что-нибудь другое?
(архитектура = система команд, вид процессора с точки зрения программиста; микроархитектура = строение конвейера, вид процессора с точки зрения проектировщика)
Проблема в том, что VLIW архитектура Эльбруса делает эффективную микроархитектуру нереальной. Когда идея VLIW только возникла (еще в 1980-х), ожидалось, что оптимальный порядок инструкций в программе будет определяться компилятором. Это работает на статической памяти с быстрым доступом (как было 40 лет назад), но к сожалению, VLIW ломается, когда он скрещивается с трехуровневым кэшем, в котором время (в тактах) доступа к памяти может меняться от нескольких тактов до более сотни (при промахе всех уровней кэша).
Так что Эльбрус против Байкал или там RISC-V от Ядра - это как покалеченный спортсмен против молодого. Оба могут быть в текущий момент не очень, но у первого есть фундаментальная причина, почему он никогда не победит на олимпиаде процессоров общего назначения, а вот второй может и победить, если нарастить мускулы (предсказатель переходов получше поставить, конвейеры load-store, дополнительные конвейеры ALU итд).
Kunpeng выпустили уже 2 года назад и в топовой версии там 64 ядра, там выше частота, больше каналов памяти и больше кэша, 7нм тех процесс обеспечивает большую энергоэффективность чем у 16 нм Байкала, по цене Kunpeng за счет огромной массовости будет существенно дешевле Байкала, с революцией вы поторопились, Байкал-S не сможет конкурировать ни в одном сегменте рынка и в Сбере его ждет судьба Эльбрусов, тоесть констатация абсолютной непригодности.
Никто не будет выбрасывать Xeon Gold 6148 и замещать их Байкалами, а если встанет вопрос закупки новых серверов очевидно выбираться будут современные гораздо более мощные и эффективные решения, а не аналог процессора 2017 года и то аналог с большой натяжкой, так как однопотоке он и рядом не стоит с Xeon Gold 6148, а подход взять и нашлепать ядра работает не везде.
Этот слайд для тех кто arm-мами не пользовался. Если кратенько, то тот факт что софтинка успешно собирается под и запускается на, ещё не означает production level не разу. Особенно когда уповают на количество посредственных ядер, бутылочным горлышком становится память и кэши в самых необычных местах. И если под 86 даже топорный код ещё как-то крутиться, то под каждый арм приходится заморачиваться с оптимизацией индивидуально. Имеющиеся наработки имеются там где у гугла и китайцев есть интерес, и это совсем не серверный софт :-)
В общем, для кота в мешке, камушек дороговат, его не корректно сравнивать даже с хуавеем, пользователи которого могут много интересного о нём рассказать.
Я только за. Вряд ли в Сбере не тестировали throughput, ограничившись только latency. И если при сравнимой нагрузке Xeon "валит на все деньги" и просит еще (как там частота упадет при дальнейшем увеличении, это еще надо смотреть) - а Эльбрус "сдувается" то ли по архитектурным причинам, то ли из-за терморегуляции - то Эльбрус хуже чем Xeon.
Ну, и так и так бывает, вопрос то сложный.
Даже опытным специалистам бывает не просто определить, часть ли это контракта и где границы коспозиции.
Но самое главное, Я бы сказал, даже не это.
Регулярно бывают ситуации, когда контракт сформулирован правильно, с этим все согласны, а потом прилетают такие изменения в требованиях, которые никто не предполагал.
Ну и текущие абстракции никто не отменял ведь.
1 - в статье не описано, какие задачи должна решать написанная система, но возможно что юнит-тесты им и не нужны. Для тестирования юзер флоу зачастую достаточно api тестов, а юнит-тесты используются для покрытия редких участков сложного кода, содержащего алгоритмические вычисления, а также в качестве документации для валидации входных данных.
Удивительно, сразу после написания комментария пришло письмо от М.Видео - Выписка по бонусному счету.
1) Улучшенный дизайн выглядит подозрительно с точки зрения создания юнит-тестов. У вас есть юнит-тесты? Не интеграционные, а именно юнит-тесты. Написание тестируемого кода накладывает "ограничения" на дизайн. Отсутствие репозитория сразу бросается в глаза, как это тестировать.
2) Декоратор, который приведен в статье мог использоваться для "быстрого фикса", с последующим рефакторингом, то есть возвращению обратно к простому дизайну.
3) Стиль дизайна определяется плотностью запросов реализации новых фич (требоаний, реквариментов), выше плотность - больше паттернов/компонентов. Чем размельченнее код, тем время внедрения новых фич в код более линейно, или даже еще лучше. Характер заказчика играет в этом роль.
4) Граница между разными сервисами проходит там, где можно выделить независимую и заменяемую часть логики.
5) "потому что ты не знаешь непосредственно, какой конкретно код будет исполняться. Тебе сначала нужно проверить, какие реализации существуют в интерфейсе, а затем разобраться, какая конкретно применяется во время исполнения." - интерфейс вводится для того, чтобы "не знать", какая будет реализация - важен контракт использования.
Если немного подумать. то зависимости между микросервисами это тот же спаггети код монолита, которые точно также нуждаются в отладке и могут резко вырасти в сложности и превратитьтся в зиккурат.
Красавцы. Все делают микросервисы, чтобы легче управлять зависимостями и тестировать отдельные модули. А вы собрали монолит, который в себе будет содержать дополнительную сложность.
Истина где-то посередине. С одной стороны 5 слоев абстракций конечно во вред. И лишние интерфейсы не нужны. С другой стороны они позволяют избежать спагетти кода, и внятно и коротко описать и протестировать логику работы, прочитать и быстро понять код.
Но при проектировании все не учтешь. Потому сначала пишется решение которое работает, а потом причесывается и разбивается на блоки так, чтобы было легко дальше поддерживать.
а еще, из живого примера, старые могут уйти сами. Недавно ушел разраб, с 30и летним опытом, т.е. собственно он один знает что зачем в системе, по причине "я устал объяснять, что "это не будет работать, и почему"". Свежие светлые идеи очень часто валят всю систему или большие её части, в случае, когда "специалист", не в курсе, что в компании существуют другие подразделения, работающие с системой по другому
Неопытный разработчик всегда имеет полярную точку зрения на абстракции - он или их избегает, или фанатично применяет.
Абстракции это простейший инструмент для описания неопределенности. Если человек пишет код для одной и той же предметной области несколько лет, и видит повторяемость-порядок, то немудрено, что это приводит к тому что абстракции становятся избыточны и появляется "простой код". Для разработчика главное, что бы его не деформировало это, иначе он может "сломаться" и посчитает, что "простой код" можно проецировать на любую предметную область. Вывод: Все очень относительно, я бы на вашем месте не был так категоричен на счет абстракций.
Иногда храбрость есть, а вот начальство говорит "мы не будем тратить на это время".
Только обычно мало у кого, как у автора статьи, хватает храбрости удалять старые ненужные абстракции и паттерны, написанные неопытными разработчиками много лет назад. Так они и существуют засоряя код.
Ну в принципе всё правильно. Абстракции ради абстракций и паттерны ради паттернов - это те вещи, которые сразу выдают неопытных разработчиков.
Но обычно с годами это проходит. После Х лет опыта люди снова начинают писать простой код. И, как правило, он работает намного быстрее и надёжнее нагромождений абстракных фабрик декораторов шаблонных обсерверов :)
У админов-сетевиков есть фраза "проблема всегда в DNS". У админов виртуализации видимо аналог - "проблема всегда в NUMA" :)
NVMe вроде хвалят за низкую латентность. Если ядро часто переключает контекст и латентность переключения много больше NVMe, то подозреваю, что наоборот, разница между SATA SSD и NVMe будет труднее обнаружить.
Кстати, вот пример сравнения Baremetal https://elibsystem.ru/node/503 с Hyper-V, KVM на SATA SSD c древним контроллером, но и там довольно хорошо видна сильная зависимость производительности от гипервизора.
Вообще надо понять что тестировать-то хочется.
Абстрактную производительность NVMe? Производительность NVMe в Hyper-V в одиночной ВМ (не убивает ли оверхед Hyper-V низкую задержку NVMe)? Производительность NVMe при большом количестве ВМ, все из которых одновременно генерируют нагрузку по сравнению с SATA (качественное сравнение есть ли разница при большой нагрузке в условиях конкуренции кучи ВМ за CPU и NVMe)? Во всех трех случаях очевидно методика тестирования разная.
Более того, от того пишутся ли данные синхронно или последовательно тоже результаты бенчмарка зависят, а тут сюрприз, SSD часто нужны для баз данных, а РСУБД пишут часто последовательно (потому-что в журнал) малым количеством потоков с частыми fsync. Т.е. базы данных даже близко не выдают максимально возможные IOPS-ы на запись.
Дальше надо понимать, что NVMe хороши низкой задержкой. Но! Но когда 100500 ВМ генерируют параллельно нагрузку и утилизируют SSD в полку, общая пропускная способность конечно будет высокой (у SSD чем больше одновременных потоков - тем больше IOPS и мегабайт), но вот задержки начнут сильно нарастать, а в статье задержки вообще не представлены! Т.е. при миллионе IOPS задержки какие? Вот для примера про латентность от Intel:
Поэтому зная, что все зависит от всего (производительность от нагрузки случайная/последовательная, размера кластера, как часто fsync шлется, размера очереди, конкуренции за CPU множества ВМ, драйверов, ФС, гипервизора, writeback, способности ВМ читать из ОЗУ вместо диска из-за виртуализации и т.д.) надо, ну если хочется во всех этих аспектах посмотреть что происходит, делать не один тест, а на каждую из задач по тесту.
Естественно, синтетика с большим количеством очередей может совершенно не походить по профилю нагрузки на поведение баз данных. Так что логично поинтересоваться у клиентов какие базы гонять собираются и побенчмаркать базы на NVMe/SATA и посмотреть, есть ли разница. Естественно начинаются приколы, что SATA будет контроллер использовать и он тоже может и свои настройки иметь и задеркжи и т.д.
Итого: непростое это дело производительность дисковой подсистемы измерять!
А не подскажите где в РФ серийное производство по 32нм? Вроде последнее что говорили, что скоро будет 65нм на микроне, но с тех пор тишина.
И второй вопрос - насколько производство по этим техпроцессам зависит от материалов, которые не производятся в РФ?
Я к тому что с подходом "все или ничего" будет "ничего".
Ну а Вы сильно недооцениваете. Про микроскоп замечательно, оцените сами время изучения чипа 20 слоев размера 20х30 мм. Или книжку покажите, где опыт разработки таких чипов описан. Все немного проще - у команды 10 лет опыта разработки физдизайна в среднем.
Вы говорите про микроархитектуру процессора ("поплясать") или что-нибудь другое?
(архитектура = система команд, вид процессора с точки зрения программиста; микроархитектура = строение конвейера, вид процессора с точки зрения проектировщика)
Проблема в том, что VLIW архитектура Эльбруса делает эффективную микроархитектуру нереальной. Когда идея VLIW только возникла (еще в 1980-х), ожидалось, что оптимальный порядок инструкций в программе будет определяться компилятором. Это работает на статической памяти с быстрым доступом (как было 40 лет назад), но к сожалению, VLIW ломается, когда он скрещивается с трехуровневым кэшем, в котором время (в тактах) доступа к памяти может меняться от нескольких тактов до более сотни (при промахе всех уровней кэша).
Так что Эльбрус против Байкал или там RISC-V от Ядра - это как покалеченный спортсмен против молодого. Оба могут быть в текущий момент не очень, но у первого есть фундаментальная причина, почему он никогда не победит на олимпиаде процессоров общего назначения, а вот второй может и победить, если нарастить мускулы (предсказатель переходов получше поставить, конвейеры load-store, дополнительные конвейеры ALU итд).
Kunpeng выпустили уже 2 года назад и в топовой версии там 64 ядра, там выше частота, больше каналов памяти и больше кэша, 7нм тех процесс обеспечивает большую энергоэффективность чем у 16 нм Байкала, по цене Kunpeng за счет огромной массовости будет существенно дешевле Байкала, с революцией вы поторопились, Байкал-S не сможет конкурировать ни в одном сегменте рынка и в Сбере его ждет судьба Эльбрусов, тоесть констатация абсолютной непригодности.
Никто не будет выбрасывать Xeon Gold 6148 и замещать их Байкалами, а если встанет вопрос закупки новых серверов очевидно выбираться будут современные гораздо более мощные и эффективные решения, а не аналог процессора 2017 года и то аналог с большой натяжкой, так как однопотоке он и рядом не стоит с Xeon Gold 6148, а подход взять и нашлепать ядра работает не везде.
Этот слайд для тех кто arm-мами не пользовался. Если кратенько, то тот факт что софтинка успешно собирается под и запускается на, ещё не означает production level не разу. Особенно когда уповают на количество посредственных ядер, бутылочным горлышком становится память и кэши в самых необычных местах. И если под 86 даже топорный код ещё как-то крутиться, то под каждый арм приходится заморачиваться с оптимизацией индивидуально. Имеющиеся наработки имеются там где у гугла и китайцев есть интерес, и это совсем не серверный софт :-)
В общем, для кота в мешке, камушек дороговат, его не корректно сравнивать даже с хуавеем, пользователи которого могут много интересного о нём рассказать.
А направление вообще правильное.
Я только за. Вряд ли в Сбере не тестировали throughput, ограничившись только latency. И если при сравнимой нагрузке Xeon "валит на все деньги" и просит еще (как там частота упадет при дальнейшем увеличении, это еще надо смотреть) - а Эльбрус "сдувается" то ли по архитектурным причинам, то ли из-за терморегуляции - то Эльбрус хуже чем Xeon.