Я хочу написать такое, но не знаю как?

Мое раннее определение масштабируемости

Еще в 2015 году, когда я пришел на работу, я слышал эту фразу во многих объявлениях о вакансиях: «Уметь писать масштабируемый код». Это требование было для меня столь же несущественным, как «S должно быть хорошо с MS-Office». Считалось само собой разумеющимся, что какой бы код я ни написал, многие люди смогут его запустить. Я постараюсь сохранить временную сложность моего кода на уровне O (1) или max O (n), и если каким-то образом он станет O (n2), он не масштабируется, поскольку больше людей будут использовать этот блок кода, время для запуска этого цикла будет больше и, следовательно, никакой масштабируемости. Ага, это была моя идея масштабируемости !!! Смейтесь сколько угодно, но есть люди, которые все еще думают так же. Потому что масштабируемость для меня означала, что ее сможет запустить несколько человек. Как код на фейсбуке. У более чем 1 миллиарда человек есть учетная запись в Facebook, и они, должно быть, написали замечательный код. Это правда, но возможность одновременно обслуживать, скажем, 20 миллионов человек, зависит не столько от кода PHP / React / C ++, который они написали, сколько от его части Ops. Сколько серверов, сколько подключений и какое время задержки. Не заблуждайтесь, они проделали потрясающую работу с бэкэндом и фронтендом, но определение масштабируемости немного отличается в разных местах.

1. Масштабируемость на уровне сервера:
Я бы объяснил на примере трех программ, влияющих на масштабируемость сервера, и объяснил, что подразумевается под масштабируемостью, когда вы говорите о сервере как о ресурсе.
Масштабируемость на стороне сервера по сути означает легкость обновления при увеличении количества входящих запросов. Итак, если вчера вы получали 100 обращений в секунду на своем сервере, а сегодня вы получаете 10000 обращений в секунду. Как легко было бы тебе

а. запустите свой сервер и

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

Прежде чем мы углубимся в детали, я просто хочу объяснить два термина, которые я буду использовать
Вертикальная масштабируемость: Вертикальный означает, что возьмите машину и продолжайте увеличивать ее размер (ОЗУ, вычислительная мощность, жесткий диск ), чтобы обрабатывать больше нагрузки / данных. У этого есть свой недостаток, так как вы можете получить очень тяжелый сервер.
Горизонтальная масштабируемость: означает наличие более дешевых серверов и распределение нагрузки между ними.
Теперь давайте рассмотрим эти три аспекта, и я постараюсь быть максимально точным, поскольку каждая тема здесь заслуживает отдельного сообщения в блоге.
1. MongoDB vs MySQL
2 . Nginx против Apache
3. NodeJS против Java

1. MongoDB против MySQL:
MongoDB более масштабируема, чем MySQL. В частности, MongoDB более горизонтально масштабируемо, чем MySQL. Как? Потому что MongoDB отказался от идеи объединений, из-за чего идея горизонтальной масштабируемости казалась кошмаром для администраторов баз данных MySQL / разработчиков серверных приложений. Вместо этого он использует концепцию, называемую жесткостью, которая по существу упрощает распространение небольших экземпляров БД по серверам.
2. Nginx против Apache и Node.Js против Java
Я объединяю эти два, потому что идея масштабируемости в Node.js и Nginx проистекает из шаблона проектирования программного обеспечения, который называется Событийное программирование. что отвергает идею потоков, используемых Apache и Java. Как программирование, управляемое событиями, оказывается более надежным, чем программирование на основе потоков (в случаях, когда количество операций ввода-вывода ›› вычислительная сложность), я оставлю вас, ребята, узнать об этом.

2. Масштабируемость на уровне кода
1. Написание масштабируемого кода означает, что, если к вам придут новые требования, насколько они изменятся, вы сможете адаптироваться к этому требованию. Чем меньше требуется строк, тем более масштабируемый код.
Для Ex. : Допустим, вы пишете Node.js для Mac OSX, и теперь вам нужно перейти к написанию того же для системы на основе Linux / Debian. Код будет считаться масштабируемым в зависимости от того, сколько строк кода необходимо изменить, чтобы адаптировать код Mac к коду Linux.

2. Код, который имеет меньше всего повторяющихся частей, также считается масштабируемый.
Для Ex. Если нужно сказать, отправьте 4 типа электронной почты. Один из них - активация учетной записи, подтверждение учетной записи, информационный бюллетень и платежные реквизиты, если таковые имеются. Вы можете написать код отправки по электронной почте 4 раза или написать его один раз в функции и использовать его по-разному в зависимости от некоторых аргументов, отправленных в функции. Последний подход называется написанием масштабируемого кода.

3. Допустим, вы создаете студенческий портал и в своем первоначальном дизайне рассматривали трех заинтересованных сторон. Студенты, преподаватели и вспомогательный персонал. Приложение создано и работает уже около 6 месяцев. Теперь неожиданно вам звонят, и вам также необходимо познакомить родителей с заинтересованными сторонами. Насколько легко вам было бы изменить дизайн базы данных / программного обеспечения и интегрировать его с вашим серверным приложением для обеспечения масштабируемости? Измените ли вы все приложение, потому что в БД добавлена ​​еще одна таблица, или с минимальными изменениями вы заставите ее работать.
Возможно, доступны и другие виды масштабируемости кода, но я считаю эти три
1. Написание кода, не зависящего от ОС,
2. Написание фрагмента кода в моем программном обеспечении только один раз.
3. Дизайн базы данных
- мои основные направления при написании масштабируемого программного обеспечения.

Как написание масштабируемого кода делает вас лучшим разработчиком?
Написание масштабируемого кода - это само по себе искусство, и его следует освоить как можно раньше. Мне нравится работать с людьми, которые ставят масштабируемость программного обеспечения в приоритет, а не просто заставляют его работать, а позже проводят часы, пытаясь сделать его масштабируемым. Это действительно заставляет вас задуматься о том, как программное обеспечение может использоваться вашими пользователями, и сделать его перспективным таким образом, чтобы, если это требование будет выполнено, все, что мне нужно сделать, просто изменить эту переменную, и она будет работать для и те случаи.

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

Если вы пишете масштабируемый код и проживаете в Бангалоре, Индия, поблагодарите автора, который является руководителем программного обеспечения в стартапе по подключению автомобилей под названием Vehico, и посмотрите, сможем ли мы в любом случае продолжить обсуждение. Вы можете связаться со мной по адресу [email protected]