Сделали прием файлов от пользователей? Сливайте их в максимально надежную и максимально безразмерную трубу. s3 оптимальный вариант. Не забудьте подумать про максимальные размеры файлов и нагрузку. ООМы это реальность, потоковая обработка немного сложнее зато надежнее.
По клику пользователя делайте минимум вещей. Если можно не ходить во внешний сервис не ходите. Если можно обойтись одним походом в sql базу, а все остальное сделать асинхронно потом то так и делайте. Всегда помните что любой внешний сервис иногда ломается и подумайте что делать в этом случае.
Вас будут спамить в любой метод который это в теории позволяет. Все что позволяет сделать запись которую увидит другой пользователь подходит для спама. Защититесь от всех самых невероятных вариантов заранее.
Клиенты любят писать скрипты к вашему АПИ. Иногда они пишут плохие скрипты. Выдать 1000 рпс с одного компа можно вообще без проблем. Подумайте и защититесь заранее.
И тому подобное. И это только про внешние взаимодействия. Не касаясь архитектуры кода вообще.
Из архитектуры кода мое любимое: Любой вечный таймаут рано или поздно окажется на самом деле вечным. Даже если этого не может быть вообще никогда. Сделайте разумное время ожидания везде. И напишите хоть какой-нибудь обработчик на случай если оно вышло.
А скажите, пожалуйста, насколько спроектированное решение должно приходить в команду имплементации? Вплоть до классов-интерфейсов или что-то более верхнеуровневое?
Очень любопытно, потому что не приходилось работать в таком ключе.
Ален Голуб "Веревка достаточной длины, чтобы выстрелить себе в ногу" - концептуальная книга не только о С++, содержит глубокие мысли о программировании в общем.
Шень. "Программирование - теоремы и задачи", 1995. Краткое и в тоже время интенсивное введение в алгоритмы. Почти все книги уже выкинул и раздал, эту оставил.
Вообще, список можно накидать на пару страниц. Хороших книг очень много.
Угу, в моем случае книгами сильно изменившими представления о программировании (я самоучка) оказались:
«Совершенный код» Макконела;
«Чистый код»/«Чистая архитектура» дядюшки Боба;
«Код. Тайный язык информатики» Петцольда.
Факт, так и происходит в Германии. Только государство успешно справилось с проблемой финансирования, переложив ее на плечи среднего класса, который платит в обязательную медстраховку по максимуму, а наслаждаются процессом по итогу страховые компании, практикующие врачи, у которых всегда есть куча пациентов, как бы плохо они не исполняли свои обязанности, потому что у хороших такие очереди, что попасть работающему человеку нереально, и всякие симулянты, у которых много свободного времени. Например, пенсионеры ходят в крачу в среднем около 60 раз в год, то есть, чаще, чем каждую неделю. Мне кажется, что даже у страховой медицины должны быть какие-то тормоза и хотя бы частичное финансовое участие, чтобы исключить злоупотребления бесплатными услугами.
У меня добавления по нищебродской экономии. Но, два доллара — это два доллара.
1. Новым пользователям слабенькую виртуалку дают на год бесплатно. Если на ней включить swap — она работает и держит как минимум 100К посетителей в день. Из системного диска можно сделать публичный образ и через год повторить.
НО исходящий трафик за деньги. Для VPN не подходит.
2. Резервированные инстансы это дешево и хорошо.
НО Амазон через год не шлёт никаких писем, и о том что резервирование давно тю-то — можно вспомнить через пол-года.
3. В S3 есть штатная функция удаления файлов по времени. Очень удобно для бекапов. Чуток покликал мышкой и у тебя есть бекапы за последние 30 дней. старые стираются сами.
НО диалоги работают не очень понятно и путь, указанный как "/", вовсе не означает верхний уровень. Нужно проверять как оно удаляется, иначе могут быть сюрпризы.
4. В том же S3 есть зеркалирование в другой регион. Это на случай, если мы с Америкой поссоримся а, с Сингапуром еще нет.
НО за трафик вы заплатите. проще лить с сервера в два региона по очереди.
5. Тип хранения, о котором говорит автор, в S3 можно задать при закачивании файла.
6. Амазон очень терпеливый. Три месяца не выключал машину, пытаясь списать деньги с уже не существующей карты. Истеричными письмами не забрасывал.
Начинаешь читать про облака и амазон и аж глаза разбегются, ну типа всё, можно всё из кубиков собирать. Начинаешь подсчитывать стоимость и челюсть падает. К пример — бэкапы лучше хранить в васаби (ценник сопоставим с гласиром, так ещё и доступ нахаляву), видео пережимать телестримом, вместо вычислительных нод — hetzner. Вот и выходит, что облака полезны только если нагрузка появляется на 5-10% времени и нужно какой-нибудь отчёт сформировать (но и тут амазон обделался со своим редшифтом — куда выгоднее snowflake юзать и платить максимум за объём в S3… но и в нём — очереди стоят невменяемых денег, проще пачку серверов/виртуалок под kafka поставить).
Короче — если стоит задача сэкономить именно в AWS — статью нужно изучать. Но обычно стоит задача впринципе сэкономить, и тогда нужно просто поспрашивать по знакомым, чем кто пользуется (бывает дешевле купить башенок десктопных и гонять вычисления на них, эникейшики в РФ недорого берут)
вы чего, какой керосин? Это только в лабе для металлического лития и то вазелин лучше. Коего лития в батарейке только в солях. Металлического в чистом виде нет. там вообще полимерный компаунд слоями.
И горят они за счет набора что там в комплекте, окислитель не требуется, им что под водой, что в азоте - так что керосин будет интересным добавлением, осталось туда пенопласта положить и будет напалм..
потому и переработать годных способов нет, причем даже на горизонте. Изменить состав батарейки - тоже нельзя, там все на пределе удельной емкости, стойкости и веса - те что для машин и телефонов.Плюс дендриты и прочие проблемы неизученные толком. и так лет 40. Пока - тупик.
Лично для меня, мораль истории прежде всего в том, что если нет достаточного опыта и знаний в подобной деятельности, не надо браться руководить проектом такого уровня
Наверно, это старость подкралась, но лично для меня мораль в том, что сначала развиваем технологии, а уже потом суёмся туда, где без них будет очень плохо (особенно, если мотивы для этого какие-то невнятные, типа, «Достигни полюса, будь полярником!»). И Амундсен в свете этой идеи ненамного умнее выглядит.
Мне нравится метафора программирования, как написания книг.
То есть запрограммировать отдельную штуку не очень сложно, как и писать. Маленькая программа — сочинение, большая — роман, крутые программисты в соавторстве десятков человек совместно пишут антологию в единой вселенной.
Просто представьте, что к вам приходит заказчик и говорит, что требования изменились, и теперь Анна Каренина должна стать сильной и решительной а Вронский — не офицер, а преуспевающий юрист. И теперь нужно поправить в тексте все моменты, где Каренина проявляла слабость, у Вронского должны измениться привычки, а в конце она должна не погибнуть, а уехать в закат с ироничной улыбкой. Тут же сразу несложно представить, почему возникают баги…
Например, до 8 версии PHP, если при обращении к любому файлу использовать схему "phar://", интерпретатор будет воспринимать содержимое файла как Phar-архив: попытается найти в нем метаданные и десериализовать их. Если ваше приложение принимает от пользователей путь до файла и не проверяет схему, то это может в некоторых случаях привести к возможности исполнения произвольного кода на вашем сервере.
Пару лет назад пытался воспроизвести эту недокументированную фичу на ubuntu server. Пришлось менять несколько дефолтных настроек. Версии 5.6 и 7.(не помню). С дефолтными не раб.
Простенький стайлгайд это совсем не архитектура.
Архитектура это что-то вроде правил:
Сделали прием файлов от пользователей? Сливайте их в максимально надежную и максимально безразмерную трубу. s3 оптимальный вариант. Не забудьте подумать про максимальные размеры файлов и нагрузку. ООМы это реальность, потоковая обработка немного сложнее зато надежнее.
По клику пользователя делайте минимум вещей. Если можно не ходить во внешний сервис не ходите. Если можно обойтись одним походом в sql базу, а все остальное сделать асинхронно потом то так и делайте. Всегда помните что любой внешний сервис иногда ломается и подумайте что делать в этом случае.
Вас будут спамить в любой метод который это в теории позволяет. Все что позволяет сделать запись которую увидит другой пользователь подходит для спама. Защититесь от всех самых невероятных вариантов заранее.
Клиенты любят писать скрипты к вашему АПИ. Иногда они пишут плохие скрипты. Выдать 1000 рпс с одного компа можно вообще без проблем. Подумайте и защититесь заранее.
И тому подобное. И это только про внешние взаимодействия. Не касаясь архитектуры кода вообще.
Из архитектуры кода мое любимое: Любой вечный таймаут рано или поздно окажется на самом деле вечным. Даже если этого не может быть вообще никогда. Сделайте разумное время ожидания везде. И напишите хоть какой-нибудь обработчик на случай если оно вышло.
А скажите, пожалуйста, насколько спроектированное решение должно приходить в команду имплементации? Вплоть до классов-интерфейсов или что-то более верхнеуровневое?
Очень любопытно, потому что не приходилось работать в таком ключе.
Ален Голуб "Веревка достаточной длины, чтобы выстрелить себе в ногу" - концептуальная книга не только о С++, содержит глубокие мысли о программировании в общем.
Шень. "Программирование - теоремы и задачи", 1995. Краткое и в тоже время интенсивное введение в алгоритмы. Почти все книги уже выкинул и раздал, эту оставил.
Вообще, список можно накидать на пару страниц. Хороших книг очень много.
«Совершенный код» Макконела;
«Чистый код»/«Чистая архитектура» дядюшки Боба;
«Код. Тайный язык информатики» Петцольда.
Факт, так и происходит в Германии. Только государство успешно справилось с проблемой финансирования, переложив ее на плечи среднего класса, который платит в обязательную медстраховку по максимуму, а наслаждаются процессом по итогу страховые компании, практикующие врачи, у которых всегда есть куча пациентов, как бы плохо они не исполняли свои обязанности, потому что у хороших такие очереди, что попасть работающему человеку нереально, и всякие симулянты, у которых много свободного времени. Например, пенсионеры ходят в крачу в среднем около 60 раз в год, то есть, чаще, чем каждую неделю. Мне кажется, что даже у страховой медицины должны быть какие-то тормоза и хотя бы частичное финансовое участие, чтобы исключить злоупотребления бесплатными услугами.
1. Новым пользователям слабенькую виртуалку дают на год бесплатно. Если на ней включить swap — она работает и держит как минимум 100К посетителей в день. Из системного диска можно сделать публичный образ и через год повторить.
НО исходящий трафик за деньги. Для VPN не подходит.
2. Резервированные инстансы это дешево и хорошо.
НО Амазон через год не шлёт никаких писем, и о том что резервирование давно тю-то — можно вспомнить через пол-года.
3. В S3 есть штатная функция удаления файлов по времени. Очень удобно для бекапов. Чуток покликал мышкой и у тебя есть бекапы за последние 30 дней. старые стираются сами.
НО диалоги работают не очень понятно и путь, указанный как "/", вовсе не означает верхний уровень. Нужно проверять как оно удаляется, иначе могут быть сюрпризы.
4. В том же S3 есть зеркалирование в другой регион. Это на случай, если мы с Америкой поссоримся а, с Сингапуром еще нет.
НО за трафик вы заплатите. проще лить с сервера в два региона по очереди.
5. Тип хранения, о котором говорит автор, в S3 можно задать при закачивании файла.
6. Амазон очень терпеливый. Три месяца не выключал машину, пытаясь списать деньги с уже не существующей карты. Истеричными письмами не забрасывал.
7. Неиспользуемые elastic-ip стоят денег. Несуразно больших.
8. В s3 есть версионность. Если она вам не нужна а вы ее включили — это экономически больно. Удалять старые версии файлов — через gui тоже трудновато…
9. Дисковые операции EBS учитываются. У меня что-то слетело и писало в логи десятками раз в секунду. Было ощутимо дорого.
Короче — если стоит задача сэкономить именно в AWS — статью нужно изучать. Но обычно стоит задача впринципе сэкономить, и тогда нужно просто поспрашивать по знакомым, чем кто пользуется (бывает дешевле купить башенок десктопных и гонять вычисления на них, эникейшики в РФ недорого берут)
вы чего, какой керосин? Это только в лабе для металлического лития и то вазелин лучше. Коего лития в батарейке только в солях. Металлического в чистом виде нет. там вообще полимерный компаунд слоями.
И горят они за счет набора что там в комплекте, окислитель не требуется, им что под водой, что в азоте - так что керосин будет интересным добавлением, осталось туда пенопласта положить и будет напалм..
потому и переработать годных способов нет, причем даже на горизонте. Изменить состав батарейки - тоже нельзя, там все на пределе удельной емкости, стойкости и веса - те что для машин и телефонов.Плюс дендриты и прочие проблемы неизученные толком. и так лет 40. Пока - тупик.
Наверно, это старость подкралась, но лично для меня мораль в том, что сначала развиваем технологии, а уже потом суёмся туда, где без них будет очень плохо (особенно, если мотивы для этого какие-то невнятные, типа, «Достигни полюса, будь полярником!»). И Амундсен в свете этой идеи ненамного умнее выглядит.
То есть запрограммировать отдельную штуку не очень сложно, как и писать. Маленькая программа — сочинение, большая — роман, крутые программисты в соавторстве десятков человек совместно пишут антологию в единой вселенной.
Просто представьте, что к вам приходит заказчик и говорит, что требования изменились, и теперь Анна Каренина должна стать сильной и решительной а Вронский — не офицер, а преуспевающий юрист. И теперь нужно поправить в тексте все моменты, где Каренина проявляла слабость, у Вронского должны измениться привычки, а в конце она должна не погибнуть, а уехать в закат с ироничной улыбкой. Тут же сразу несложно представить, почему возникают баги…
Пару лет назад пытался воспроизвести эту недокументированную фичу на ubuntu server. Пришлось менять несколько дефолтных настроек. Версии 5.6 и 7.(не помню). С дефолтными не раб.
Вспоминаются байки про оптику на спутниках, позволявшую читать заголовки передовиц и считать звёздочки на погонах.
Вопрос хранения информационного наследия зело плачевен.