[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1622862338006.jpg -(235675 B, 783x1200) Thumbnail displayed, click image for full size.
235675 No.191189  

Собственно сабж.

Интересует вопрос как спроектированы всякие телеграмы/фейсбуки в архитектурном плане.

Как обеспечивается быстрый отклик в групповых чатах, поисковые выдачи, отображение отсортированного контента при гигантском количестве данных и числе пользователей.

Реквестируется литература на базовые принципы организации такой структуры, так же особенно хочется видеть реальные живые примеры.

Гуглеж в основном выдает ответы в стиле "проект Y использует технологии X". А хотелось бы конкретики со всеми поторохами. Что-то вроде истории разработки и развития какого-нибудь большого сервиса с техническими подробностями.

>> No.191193  
File: 1622884591842.jpg -(990350 B, 714x1000) Thumbnail displayed, click image for full size.
990350

>>191189
Какой-то единственно верной архитектуры не существует, отсюда и ответы в стиле "проект Y использует технологии X", чтобы кратко описать что же там под капотом. Но если тебе хочется каких-либо подробных примеров, то можешь посмотреть в сторону википедии, это более чем высоконагруженный проект и в то же время они публикуют подробную информацию о своих потрохах:
https://meta.wikimedia.org/wiki/Wikimedia_servers
https://wikitech.wikimedia.org/wiki/Main_Page

>> No.191202  

>>191193

Ну я не совсем про это спрашивал.

Может я неправильно сформулировал. Я интересуюсь гайделанами по структурной организации в отрыве от конкретной реализации, в том числе реализации какой-то специфичной логики проекта. То есть не суть важно на чем написано(это такой массовый идиотический запрос, который сдвигает суть решения проблемы к конкретным инструментам реализации), а важна сама идея архитектуры.

Ну как аналогия - вопрос "как построить дом". А какой не важно - одноэтажный или небоскреб. Суть принципов проектирования и расчетов от этого не изменится. Вот такой вменяемый гайделан ищу, только для хайлоад.

По вики хороший пример, спасибо почитаю.

>> No.191203  
File: 1622904335996.jpg -(441804 B, 900x919) Thumbnail displayed, click image for full size.
441804

>>191202

> Ну как аналогия - вопрос "как построить дом". А какой не важно - одноэтажный или небоскреб. Суть принципов проектирования и расчетов от этого не изменится.

Но в том то и дело, что одноэтажный дом и небоскреб строятся по совершенно разным приницпам проектирования. Кроме для одноэтажных домов существует еще и несколько приницпиально разных подходов. С высоконагруженными приложениями тоже самое.

>> No.191205  
File: 1622911797062.png -(612632 B, 1488x945) Thumbnail displayed, click image for full size.
612632
>высоконагруженных приложений
>телеграмы/фейсбуки

предлагаю оштрафовать ОПа

>> No.191206  

>>191205
Мне показалось, или ычан изменился?

>> No.191209  
File: 1622918221750.jpg -(6384001 B, 3185x4800) Thumbnail displayed, click image for full size.
6384001

>>191189
Поправте меня, если я скажу сейчас глупость, но ничего фактически не измелилось за многие годы. По сути все просто покупают дополнительное железо и делают реплику своего сервиса оптимизированную под регион, или вроде того. Как не оптимизируй, а в это всё потом упирается.

Для меня лично эта тема довольно скучная. Эдакая цифровая логистика. А из интересного раньше было популярно обсуждать масштабирование. Когда ещё нормальных и доступных инструментов не существовало толком.
Помню, где-то в конце нулевых были какие-то разговорчики о том, что архитектура должна быть такой чтобы масштабирование происходило горизонтально, а не вертикально. То есть, чтобы просто можно было купить ещё одну дешевую железку, а не думать потом откуда же взять ОДНУ серверную машину поддерживающую овер 9000Гб RAM. То есть, это когда-то давно было актуальным. Сейчас уже нет. Просто следуешь существующим практикам и всё. Если не интересуешся исследованиями новых видов велосипедов.

>> No.191210  

>>191209

>Просто следуешь существующим практикам и всё.

А сейчас что, докер?

>> No.191211  

>>191210
Я не сильно интересуюсь трендами. Вроде как эти докер контейнеры для подобных задач пачками разпихивают по кластерам и управляют ими вот этой
https://ru.wikipedia.org/wiki/Kubernetes
хреновиной.
Если будешь вникать в это, то ничему не удивляйся и помни, что этим всем в основном занимаются девопсы.

>> No.191212  
File: 1622920881504.png -(975066 B, 1000x1204) Thumbnail displayed, click image for full size.
975066

>>191209

> То есть, это когда-то давно было актуальным. Сейчас уже нет.

Сейчас это очень распространенная практика. Еще одна распространная практика делать приложения stateless, чтобы их можно было масштабировать простым увеличением количества запущенных копий приложения.

>> No.191213  

>>191211

>ничему не удивляйся

Я когда слышу докер, так и делаю. До сих пор не въехал, что такое девопс.

>> No.191214  

>>191213
Везде об этом очень заумно пишут. Потому что работа скучная, а кадры где-то брать нужно. Прям как с ДэЙтАсойЕНс вот сейчас. Раньше это какие-то чуваки сидели в банках и институтах, писали скучные, навороченные калькуляторы на R. А сейчас посмотри что маркетологи творят. Професия будущего, лол.
Вот и тогда придумали такое, что это не сисадмины, оказывается, ползают по серверной с сальными волосами, ковыряют конфиги и пишут скрипты. А девопсы!

Кстати, раньше в этом всём какая-то романтика хоть была. В сисадминстве. А сейчас всё автоматизировали. Докер — это по сути средство которое позволяет написать один скрипт для развертывания твоего барахла на неважно какой машине, потому что развернуто оно будет в контейнере. Всё везде одинаково, один скрипт (докерфайл) работает везде одинаково хорошо. А раньше писали на perl, на python и даже на баше скрипты чтобы подготовить всё и поднять солюшон.

>> No.191215  

>>191214

>не сисадмины, оказывается, ползают по серверной с сальными волосами

А я бы и не против поползать по серверной с сальными волосами, странные какие-то маркетологи, напридумывали всякого. Как теперь на работу то устроиться без вороха ключевых слов в резюме?

>> No.191216  

>>191214
Акшчуалли, книга по сис. админству >>189479 указанная здесь, говорит, что devops это специализация системного администратора и человек с такой специализацией. И вот что там говорится: DevOps is not so much a specific function as a culture or operational philosophy. It aims to imporove the efficiency of building and delivering software, especially at large sites that have many interrelated services and teams.
Organizations with a DevOps practice promote integration among engineering teams and may little or no destinction between development and operations.
Experts who work in this area seek out inefficient processes and replace them with small shell scripts or large and unwienldy Chef repositories.

>> No.191391  
File: 1623449542789.png -(44635 B, 480x320) Thumbnail displayed, click image for full size.
44635

>>191189
На этот вопрос нельзя осмысленно ответить не зная специфики данных, как они будут читаться, как они будут записываться и как долго будут хрнаиться, а так же какие у них будут вторичные применения.

Но если хочешь немного газированной лужи, то:

В самом общем случае всё сводится к шардированию/федерированию. От локалити-регионов до партитиций пространства ключей. Отдельную партитицию отдельной федерации можно реплецировать, реализовать как имеющий кворум локальный кластер, если даунтаймы нежелательны -- тогда при аккуратной разработке ноды в том числе можно будет по одной заменять и апдейтить.

Партитированная/кластеризованная архитектура может быть в том числе и рекурсивной, конечные k/v могут использоваться в доменно-специфично партитированном сервисе, доменно-специфичные сервисы могут представлять локальный сайт федерации, локальный сайт федерации может быть частью региональной, etc.

С точки зрения общей архитектуры всё достаточно просто и очевидно.

На уровне моделей данных, особенно в случае с запилом поиска может потребоваться паралельная инфраструктура для поддержки кешей и индексов, но тут опять же не зная специфики данных и какие n-арные индексы можно задействовать, дальше того же logn не уедешь.

Настоящие сложности начинаются с реализацией такой архитектуры на практике, тут помешать могут в первую очередь административные сложности, например меняющиеся требования - в какой-то момент продуманную и замоделенную архитектуру могут начать хотеть использовать для неподходящих ей задач. Тут по-хорошему может быть нужно тотальное переосмысление, рефакторинг и реструктурирование, а ресурсов на это может не быть. Или неверифицируемая разработка - без полноценных тестовых-пердпродовых-клонопродовых площадок, повсеместного покрытия тестами апишек-кода и прогонов на самых разных конфигурациях и наборах данных, уложить что-то в даунтайм на проде очень легко. А мотивировать штат QA/девопсов в несколько раз больше разработки может быть не всегда просто.

К сожалению практически любой, в том числе высоконагруженный проект представляет собой большой конгломерат из не всегда корректно подходящих под задачу, но всёравно используемых компонент, которые рефакторят но нормальные реализации только по очень большой необходимости. А могут и не тестировать полноценно и ловить всякие неожиданные эджкейзы. Очередь на перепроектирование может формироваться просто из сортировки по числу, северности и продолжительности ошибок/тормозов в метриках, а до тех пор затыкаться сервисмешами с горячим кешем запросов где возможно.

Как правило вместо того чтобы моделировать супербыстрые индексы под фиксированную часть датасета и мешить их на разных уровнях, полезней думать оказывается о том как быть в курсе того что тормозит и того что валится -- покрывать что можно без ущерба рантайму метриками, конечными сервисами пробрасывать трейсинг, держать девопосов которые будут за этим всем следить и делать алерты как что-то пошло деградировать, пускать канареек с частью трафика прода, в свободные интервалы симулировать ошибки -- всё что бы иметь возможность отловить и точно локализовать ошибки, как в коде, так и архитектуре.

Ну и ещё при всеобщей партитированности данных возникает вопрос их консистентности, тут может быть несколько подходов, от коорданатора(ов) до распределённых транзакций и очередей. И тут уже никакой серебряной пули быть не может, только трейдоффы. Или потеря части транзакций, или атомарности, или минимальности раундтрипов, или децентрализации, или ресурсов. В общем случае наверное координатор будет наименее оверхедным и легко масштабируемым решением -- можно обьединять группы доменов под локальным координатором например, но в зависимости от специфики данных, альтернативы могут быть удачней.

>>191211
Врядли в последние лет пять много у кого-то была возможность деплоится куда-то ещё. Если конечно не какой мастадон который с 90х свою инфрструктуру с нуля, но и те потихоньку переползают, всё же проще поддерживать фосс с кучей готовых проектов и запланированной расширяемости, а своих освободившихся девелоперов на что-то фичевое отправить. Если конечно не банк какой, они те ещё консервахи с живым миниксом и спарками. Но им и понятно что 90% оверхеда затанковать проще чем что-то менять.

>>191212
Олсо не имеющий персистенси сервис != stateless. Stateless сам по себе - это FP, очень красиво, но очень бесполезно. А как только появляются точки взаимодействия с реальным миром, то там-то всё и рушится на доступности данных.

Другое дело чтобы изолировать места где нужно вобще что-то персистить и там уже накручивать партитиции-реплики и прочее. Но как правило это достаточно самоочевидно, что какому-нибудь апи-гейтвею не нужна своя бд, а нужен допустим отдельный сервис аутентификации, который может в свою очередь иметь бд именно аутентификационных/авторизационных данных, которая в своём кластере и наборе реплик.

>> No.191400  
File: 1623479627389.jpg -(801830 B, 999x768) Thumbnail displayed, click image for full size.
801830

>>191391

> Олсо не имеющий персистенси сервис != stateless.

Но обычно именно так их и обзывают. Собственно они хороши как раз тем, что как правило очень легко скейлятся горизонтально, из-за чего на них имеет смысл вынести максимум нагрузки, разгрузив stateful сервисы вроде бд, котрые уже так легко не отскейлить.

>> No.191416  

>>191214

>А девопсы!

Шатают докер. Могут еще k8s даже если он вам не нужен.

>>191215

>Как теперь на работу то устроиться без вороха ключевых слов в резюме?

Да пиши больше, походу разберешься.

>>191391

> Или неверифицируемая разработка - без полноценных тестовых-пердпродовых-клонопродовых площадок, повсеместного покрытия тестами апишек-кода и прогонов на самых разных конфигурациях и наборах данных

Поскольку заказчикам не нужны тесты (читай лишние расходы) только такой в основном и занимаюсь. Аджайл во все поля на хуяк-хуяках.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]