Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать web API. Что такое веб-сервер На чем работают сервера

27.06.2020

Ниже мы приводим адаптированный перевод статьи The non-techie’s guide to servers Кеннена Чандрасегарана (Kannan Chandrasegaran), разработчика из компании Panopto. Просим обратить внимание, что статья рассчитана на новичков, которые мало знакомы с понятием серверной части приложения и серверов.

Из жизни офиса

Сложно быть «не-технарём» в ИТ-компании, уж поверьте! Маркетологи, менеджеры по продажам, бухгалтеры - не суть важно - время от времени они сталкиваются со своими технически подкованными коллегами. Это могут быть программисты или системные администраторы.... В любом случае, "не-технари" чувствуют себя так, будто им ампутировали важную часть мозга. Или они высадились на неизвестную планету с разумной негуманоидной жизнью. Или…

Иногда, конечно, всё заканчивается благополучно. Вот, например, девушка-« », идёт по коридору. Ничто не предвещает беды: она направляется налево, вы – направо, и как можно быстрее… Нет, в этот раз не пронесло. Вы уже сидите с ней за столом, и пытаясь побороть неловкое молчание, спрашиваете: «А...чем именно ты занимаешься?». Она начинает рассказывать что-то, но вы не сразу врубаетесь, о чём она. Вроде бы и слова знакомые: пользовательский интерфейс, приложения, и - точно, Facebook - это сайт. Ага, там есть кнопочки, меню… Вы кое-как разобрались в хитросплетениях её работы, киваете ей на прощание и ваши пути расходятся в коридорах большого офиса.

Но рано или поздно вам не так повезёт: вы встретите инженера по серверам. Или бек-энд разработчика. Не зная в какие дебри сейчас попадёте, вы наивно задаёте тот же вопрос и... получаете абракадабру в ответ. Слышите уйму иностранных слов, а в голове пробегают мысли: «Прилично ли спросить, что такое API?», «Мы всё время используем «бэдэ» (DataBase), правда, что ли?», «Кто такой, чёрт побери, этот Джейсон (JSON)??». Ваш знакомый инженер пытается рассказать вам о серверах, но не понимает, насколько вам сложно понять его наполненную профессиональными терминами речь. Вероятно, вы уже слышали слово "сервер" раньше, но его употребляют в настолько разных контекстах, что осознать его значение крайне сложно. Что ж попробуем разобраться с этим термином.

Вниз по кроличьей норе

Когда обычный человек (в смысле, не программист или админ) использует приложение, всё, что он видит - это интерфейс, картинку, которая реагирует на какие-то очевидные (чаще всего) действия. На самом деле то, что пользователи понимает под «приложением» обычно - его фронт-енд, то есть, лицевая, часть, обёртка, с которой они взаимодействуют. А вот о том, что внутри, то есть о том, что заставляет приложение работать, пользователи знают крайне мало. Скажем, вы отправляете мне сообщение, например, по Whatsapp или Viber. Это выглядит так, будто сообщение идет с вашего смартфона на мой. Давайте посмотрим на этот процесс внимательнее. Скажем, вы отправляете мне сообщение, когда мой телефон выключен, а затем вы сами выключаете свой смартфон. И вот, я включаю свой телефон, и все-таки получаю ваше сообщение, хотя наши телефоны одновременно не работали. Похоже, мы что-то упустили! Это «что-то», пропущенный нами компонент - бек-энд или сервер.

Говоря о фронт-энде и бек-энде, программисты обычно подразумевают разделение пользовательской части приложения от программной логики. Итак, фронт-энд (front-end) - это интерфейсная часть приложения, а бек-энд (back-end) - его серверная часть.

Серверы

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

Хранилища или системы хранения данных

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

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

Это позволяет ответить на многие вопросы. Например:

  • Сколько пользователей лайкнули этот ресторан?
  • Какие рестораны нравятся этому пользователю?
  • Блюда какой кухни нравятся сразу нескольким пользователям?
Информация и связи между данными хранятся в базе данных (БД). Существует множество видов баз данных, но все они:
  • могут хранить информацию
  • могут хранить связи между данными
  • могут получать запросы об информации и отвечать на них как единичными данными или набором данных, в зависимости от запроса.
Существует много видов баз данных, каждая из которых имеет свои преимущества и недостатки. Если вы слышите такие термины как SQL, MySQL, MongoDB, CouchDB, Redis, то знайте - речь идет о базах данных.

Взаимодействие

Ключевая задача сервера - взаимодействие с приложением и другими серверами.

Многие задачи приложения требуют взаимодействия с сервером. Например, если пользователь что-то ищет, поисковый запрос посылается на сервер и оттуда приходит результат. Если пользователь шлет сообщение другому пользователю, оно сначала приходит на сервер. А затем оттуда отправляется на приложение другого пользователя, чаще всего в виде отправленного уведомления. Интерфейсы, которые предоставляет сервер для того, чтобы приложения могли с ним взаимодействовать, обычно называются API . Ну а какие-то функции интерфейса можно сопоставить с конечными точками (endpoints), например, с поиском или авторизацией на сайте. Непосвященным такое взаимодействие может показаться странным. Двумя наиболее распространенными форматами взаимодействия являются JSON и XML.

XML слева, JSON справа На первый взгляд форматы выглядят трудночитаемыми. Важно понимать, что сервер - это просто компьютер, как ваш ноутбук или смартфон. Приложение на вашем телефоне принимает пользовательский ввод в голосовом или текстовом виде, с помощью распознавания голоса или касания к экрану. Приложение обрабатывает эту информацию, а затем дает ответ в виде изображения на экране. Смартфон -компьютер, который взаимодействует с человеком, поэтому ввод и вывод предоставляются в удобной для человека форме. Сервер - вычислительная машина, которая взаимодействует только с другими компьютерами. Человек воспринимает информацию благодаря таким вещам как: размер шрифта, цвет текста и форматирование. Но это ничего не значит для компьютера.

Серверное приложение

Если вы хотите создать приложение, которое будет работать на вашем телефоне, вам также понадобится приложение, которое будет работать на сервере. Серверные приложения создаются с помощью серверных языков программирования и фреймворков, популярными вариантами которых являются Java , Ruby on Rails , Node.js , PHP , ASP.NET .

Можно сказать, что API - это «двери» вашего сервера и приложение знает, что в них надо стучать. База данных хранит всю вашу информацию. А серверное приложение – это «мозг», который связывает все вместе. Оно получает и отвечает на запросы, которые поступают ему через API, добавляет и извлекает информацию из базы данных, и принимает решения. Например, когда пользовательское приложение отправляет информацию для входа, запрос поступает через API, правильная информация для входа хранится в базе данных. Задачей серверного приложения сравнить их и соответственно ответить приложению, используя API.

Аппаратное обеспечение

Когда вы слышите слово «сервер», скорее всего, вы представляете такую картинку: шкафы с мерцающими лампочками в закрытой комнате. Вероятно, для полноты картины, не хватает только Тома Круза, который спустится с потолка и что-нибудь крадёт. Многие большие компании владеют собственными серверами и целыми центрами обработки данных (те самые огромные комнаты с мерцающими шкафами). У Facebook и Google сотни серверов по всему миру. Когда вы руководите огромным сервисом с миллионами пользователей, содержание собственных серверов может быть значительно дешевле и это обеспечит более высокую производительность. Вместо того чтобы содержать свои собственные сервера многие разработчики используют облачные сервисы. Такие сервисы как Amazon Web Services, Azure и Digital Ocean предлагают возможность использования «виртуальных серверов». Эти сервисы владеют и обслуживают аппаратное обеспечение, а разработчик просто загружает на него серверное приложение. Некоторые провайдеры услуг предоставляют бекэнд как сервис, позволяя вам иметь простой бэкенд без необходимости писать серверное приложение самостоятельно.

Всем ли приложениям нужен бэкенд?

Большинство знакомых вам приложений, скорее всего, имеют бэкенд-компонент. Конечно, можно найти программы без серверной части. Например, некоторые приложения для продуктивности. Легкий способ выяснить есть ли у приложения бэк-енд выглядит так: Если ответ «нет», это означает что у приложения точно есть бекэнд-сервер.

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

Все больше предприятий малого бизнеса могут оценить преимущества наличия сети

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

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

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

«Я вижу все больше небольших организаций, в которых работают серверы, даже в офисах с одним сотрудником», - говорит Лора ДиДио (Laura DiDio), аналитик малого бизнеса в консалтинговой компании The Yankee Group из Бостона. - «Они позволяют получить больше прибыли на доллар, вложенный в технологии».

Все дороги ведут к серверу
Обратимся к причинам, которые побуждают малый бизнес устанавливать серверы (серверы - это компьютеры, которые обеспечивают службы, команды и централизованное управление для рабочих станций, именуемых «клиентами»). Но сначала посмотрим, почему сети с серверами уже работают в офисах пользователей.

Возьмем уже знакомую нам Лору ДиДио. Часть времени она работает в своем загородном доме и хочет извлечь максимальную пользу от своих затрат на технологии. «У меня дома два переносных компьютера, два скоростных подключения, три телефонные линии и сервер, работающий под управлением Microsoft Small Business Server», - говорит Лора.

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

«Сервер позволяет мне работать более гибко, устанавливать все, что я хочу, и создает мне профессиональный идидж», - говорит Лора.

Еще один сторонник серверов - Гарри Брелсфорд (Harry Brelsford), консультант-реселлер по технологиям и технический писатель из Бэйнбридж Айленд, штат Вашингтон. У него в офисе работают три клиентских ПК и сервер. Здесь он предоставляет консалтинговые услуги по технологиям примерно 20 компаниям, а также пишет книги по этой тематике (он уже написал 10 таких книг).

«Сервер и сеть очень помогают мне в работе», - говорит Брелсфорд. - «Если мне нужен какой-то файл, я точно знаю, где его искать. У меня также больше уверенности в стабильности системы, независимо от того, что я делаю. Просто вы выполняете работу лучше и без переделок. Вы можете забыть о недостатке места на диске, беспорядке в файлах, недостаточной мощности процессора и потерях данных».

ДиДио и Брелсфорд говорят о серверах Dell и Hewlett-Packard, которые стоят не более 1,000 долл.. На них работает новое программное обеспечение Microsoft Windows Small Business Server 2003 (599 долл. за Standard Edition). Такой комплекс весьма привлекателен для менеджеров, умеющих считать свои деньги. Версия Standard Edition также включает Microsoft Exchange Server 2003.

С этим согласен Рэй Боггс (Ray Boggs), вице-президент по развитию малого бизнеса и домашних офисов в IDC, компании технического консалтинга из Фрэмингхэма, штат Массачусетс. Он говорит, что, хотя преимуществами от перехода на технологии клиент/сервер могут пользоваться все малые организации, наибольшие выгоды получают те из них, у которых 15 ПК или больше. Это достигается за счет новых аппаратных средств и программного обеспечения, предназначенных специально для этого рынка, и резко возрастающего числа сделок.

«Цены на серверы продолжают падать, а их функциональные возможности продолжают улучшаться», - говорит Боггс.

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

  1. Вы наведете порядок в хаосе. Централизуя данные на сервере, можно лучше управлять важной деловой информацией. Общий доступ к файлам и другим данным со всех ПК существенно упрощается по сравнению с перемещением данных с одного ПК на другой. И, как отмечает ДиДио, более старые ПК могут обрести новую жизнь, если их файлы и данные загрузить на сервер. «Многие покупают серверы и не спешат избавляться от своих старых ПК и переносных компьютеров», - говорит она.
  2. Лучшая защита данных. В Windows Small Business Server 2003 имеются две функции, которые позволяют пользователям лучше защитить информационные активы, упрощая архивацию и восстановление критических данных. Это мастер настройки архивации и теневое копирование тома.
  3. Лучшее сотрудничество при ведении бизнеса. Сеть, поддерживаемая сервером - это не только облегчение общего доступа к данным. Windows, Small Business Server 2003 поставляется со службами Windows SharePoint Services, программным обеспечением, которое позволит вашим сотрудникам и другим членам команды организовать совместную работу через Интернет. Установив SharePoint, вы получаете портал внутренней сети компании с дружественным интерфейсом, обеспечивающим общий доступ к данным и их организацию. Службы поставляются со справочными документами и ресурсами. Сервер также обязателен, если требуется поддержка на нескольких ПК жизненно важных для деятельности предприятия приложений, таких как финансовые решения Microsoft Business Solutions.
  4. Повышение мобильности персонала. Серверы позволяют получать удаленный доступ к сети и данным уполномоченным сотрудникам, находящимся вне офиса, в пути или работающих в локальных подразделениях. С помощью функции рабочего места в Интернете пользователи Windows Small Business Server 2003 могут получать доступ к данным на сервере через Интернет. Сотрудники вне офиса могут также подключаться к внутренней сети компании через SharePoint
  5. Совместное использование высокоскоростного доступа. «Настоящий катализатор сбыта серверов в среде малого бизнеса - это высокоскоростной доступ к Интернету для всех компьютеров сети», - говорит Боггс из IDC. - «Если в бизнесе используется три и больше учетных записей удаленного доступа, - самое время купить сервер и перейти на скоростной доступ. Возврат вложений будет очень быстрым за счет роста производительности труда».
  6. Быстрая настройка новых компьютеров, добавление пользователей и развертывание новых приложений. Планируете развитие своего дела? Управляя данными из общего центра, легче координировать добавление новых ПК, программ и лицензий на них. Можно также лучше управлять брандмауэрами и контролировать угрозы данным, разворачивать антивирусную защиту и обнаруживать вторжения.
  7. Увеличение вычислительной мощности. Сервер расширяет возможности сети, позволяя хранить большие массивы данных, освобождая память и повышая эффективность использования отдельных ПК. «Малый бизнес сегодня нуждается в дополнительных вычислительных мощностях для использования веб-служб, управления веб-узлами, выполнения рассылок информации по электронной почте и применения более совершенных инструментальных средств и приложений», - говорит ДиДио. (Боггс добавляет, что недалек тот день, когда у многих дома будут работать серверы, помогая студентам с помощью ПК выполнять учебные задания, а подросткам - покупать в Интернете игры и другие сложные программы.)
  8. Создайте профессиональный имидж своему бизнесу и расширьте взаимодействие с клиентами. Серверное программное обеспечение, такое как Windows Small Business Server 2003, позволяет объединять учетные записи электронной почты (AOL, Yahoo!, Hotmail и т.д.) в одну учетную запись компании, усиливая ваш имидж среди клиентов и партнеров. «Вы можете иметь несколько псевдонимов одного корневого адреса электронной почты», - говорит Брелсфорд. - «Сервер может придавать вес вашему бизнесу». ДиДио: «Это не только приносит вам больше прибыли на вложенный доллар, но и делает ваш имидж более профессиональным в глазах тех, с кем вы хотите иметь дело».
Как узнать, что пора покупать сервер?
  • В вашем бизнесе используется две или больше учетных записей удаленного доступа.
  • Вы хотите централизовать и организовать данные (не всегда можете найти то, что вам нужно).
  • Вы хотите создать общий доступ к аппаратным средствам, таким как принтеры и факсы для двух или больше ПК (при использовании для этой цели одноранговых сетей требуется большое количество шнуров и проводов).
  • Вы хотите упростить резервное копирование, чтобы обеспечить лучшую защиту данных.
  • Многим вашим сотрудникам, которые часто находятся в пути, вне офиса или работают в локальных подразделениях, требуется подключаться к сети.
  • Вы хотите весь свой бизнес охватить внутренней сетью (сотрудники, которые находятся вне офиса, не всегда помнят о том, что время от времени нужно с вами связываться).
  • Вам нужно много места для хранения данных (и ваши перегруженные ПК содрогаются и стонут при добавлении новых данных).
  • Вы хотели бы запускать финансовое программное обеспечение или другие важные для вашего бизнеса приложения на нескольких ПК.
  • Ваша компания растет, и вы планируете принять новых сотрудников и добавить компьютеры (поздравляем!).
  • У вас скромный бизнес, и вы хотели бы выглядеть профессионально (и больше, чем есть на самом деле).
  • Ваши ПК очень старые, и вы хотели бы избавиться от них. Сервер сделает процедуру перехода безболезненной.
  • Ваши ПК очень старые, но вы хотели бы сохранить их. Сервер примет нагрузку с ПК на себя.

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Обзор

  • Сервер - это почти два миллиона строк кода на Java. Для соединения с сервером и отображения красивой картинки используется клиент, написанный на C++.
  • Свой вклад в серверный код внесли полсотни программистов. Код писался в течение многих лет лучшими специалистами российского «православного» геймдева. В нем собраны все самые удачные идеи со всего мира.
  • На текущий момент у нас написано около 5200 автоматических тестов, налажен continuous integration и нагрузочное тестирование с помощью ботов.
  • Сервер умеет запускаться и работать на десятках и сотнях серверов, поддерживать игру сотен тысяч человек одновременно. Мы решили отказаться от традиционной для MMO техники шардирования и запустить всех игроков в один большой мир.

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

Сервисная архитектура

Одна из основных особенностей разработки состоит в том, что мы не знаем, сколько у нас будет игроков. Может быть, всего один - сам разработчик, а может, 100000 одновременно. Поэтому сервер должен уметь запускаться в маленькой конфигурации, на ноутбуке, и растягиваться при необходимости на десятки и сотни мощных серверов.

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

Третья большая проблема - это многопоточность. Как известно, лучший способ сладить с многопоточностью - это избежать ее. Deadlock, livelock, lock contention и другие милые сердцу программиста проблемы можно обойти, если архитектура сервера будет избавлять вас от необходимости синхронизировать потоки вручную. В идеале программист вообще должен писать простой однопоточный код и не задумываться о такого рода вещах.

Отсюда родилась наша универсальная структура сервера, которая используется в Skyforge:

  • Существует пул физических серверов, на которых будет запускаться игра. Этот набор серверов и наше серверное приложение, которое на них запущено, называется Realm.
  • На каждом сервере запускается серверное приложение (JVM), называемое ролью. Роли бывают разные: аккаунт-сервер, игровая механика, чат и т.д. Каждая роль берет на себя большой кусок функционала. Некоторые роли существуют в единственном числе, некоторые запускаются в нескольких экземплярах.
  • Роль состоит из набора сервисов. Сервис - это обычный поток (thread), который занимается своей, специфичной для него задачей. Примером сервиса может служить сервис авторизации, сервис резервирования имен, балансировщик нагрузки и т.п. Каждый сервис ничего не знает о физическом расположении других сервисов. Они могут быть рядом, а могут быть на другой физической машине. Сервисы взаимодействуют через систему сообщений, которая скрывает от них такого рода подробности.
  • Каждый сервис состоит из набора модулей. Модуль - это «кусок функциональности», у которого есть один метод tick(). Примером модуля может быть модуль статистики, модуль исполнения транзакций, модуль синхронизации времени. Вся работа сервиса заключается в том, чтобы в бесконечном цикле поочередно вызывать метод tick() у своих модулей. Один такой цикл называется «кадр сервера». Мы считаем показатель хорошим, если кадр сервера колеблется в пределах от 3 до 20 мс.
  • Вся эта структура описывается в XML-файлах. Системе запуска надо просто «скормить» название роли. Она найдет соответствующий файл, запустит все нужные сервисы и отдаст им списки модулей. Сами модули создадутся с помощью java reflection.

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

Основные сервисы

Есть некоторый набор сервисов, который несет основную игровую нагрузку. Каждый из серверов должен уметь масштабироваться. В идеале - до бесконечности. К сожалению, писать серверы так, чтобы они масштабировались, это непростая задача. Поэтому мы начали с того, что сделали основные сервисы масштабируемыми, а всякую дополнительную мелочь, которая не несет основной нагрузки, оставили на потом. Если у нас будет очень много пользователей, то и их нам придется улучшать для обеспечения возможности масштабирования.
  • Аккаунт-сервис. Отвечает за авторизацию и подключение новых клиентов.
  • Сервер игровой механики. Тут происходит, собственно, сама игра. После прохождения авторизации клиент подключается сюда и тут играет. С другими сервисами клиент напрямую не взаимодействует. Таких сервисов можно и нужно запускать несколько десятков, а то и сотен. Именно эти сервисы несут основную нагрузку.
  • Сервисы баз данных. Эти сервисы выполняют операции над данными игровых персонажей, их предметами, деньгами, прогрессом развития. Их обычно запускается несколько штук. Подробнее об архитектуре баз данных можно прочитать в моем прошлом докладе. (habrahabr.ru/company/mailru/blog/182088)
  • Чат. Занимается роутингом сообщений чата между пользователями.
  • Все остальные сервисы. Их несколько десятков, и они обычно не создают сильной нагрузки, поэтому не требуют обособленных серверов.

Сеть

Под словом «сеть» я подразумеваю систему доставки сообщений от одного сервиса к другому или от одного объекта к другому. Исторически так сложилось, что у нас существует сразу две такие системы. Одна основана на сообщениях. Вторая система основана на удаленном вызове процедур (RPC). В Skyforge система сообщений применяется внутри сервиса игровой механики, чтобы послать какое-то сообщение от аватара к мобу, а также для общения клиента и сервера. RPC используется для общения между сервисами.

Сообщения
Все объекты, которые хотят посылать или принимать сообщения, называются абонентами. Каждый абонент регистрируется в общей директории и получает уникальный идентификатор - адрес. Любой, кто хочет послать сообщение какому-либо абоненту, должен указать адреса «откуда» и «куда». Сетевой движок знает, где находится абонент, и доставляет ему сообщение. Сообщение - это Java-объект, у которого есть метод run(). При отправке этот объект сериализуется, прилетает к целевому абоненту, там десериализуется, а затем вызывается метод run() над целевым абонентом.

Такой подход очень удобен тем, что позволяет реализовывать простые команды типа «нанести удар», «выдать анлок», «запустить фаербол». Вся эта логика оказывается внешней по отношению к объекту, над которым выполняется действие. Большой минус этого подхода в том, что если логика команды требует выполнения какого-либо кода на нескольких абонентах, то нам потребуется сделать несколько сообщений, которые будут посылать друг друга по цепочке. Логика оказывается фрагментирована на несколько классов, и цепочки сообщений часто довольно долго и сложно распутывать.

RPC
Удаленный вызов процедур или RPC появился, чтобы решить проблему цепочек сообщений.
Основная идея заключается в использовании кооперативной многозадачности (Coroutine, Fibers). Тому, кто не знаком с это концепцией, для понимания темы советую заглянуть в «Википедию». en.wikipedia.org/wiki/Coroutine .
Сервис, который хочет, чтобы его могли вызывать через удаленный вызов процедур, должен реализовывать специальный интерфейс и зарегистрировать в специальной директории. Тогда любой желающий может попросить директорию дать ему интерфейс этого сервиса, и директория вернет специальный враппер над сервисом. Вызывать сервисы по RPC можно только внутри файбера (coroutin), т.е. специального контекста исполнения, который можно прерывать и возобновлять в точках разрыва. При вызове методов враппера он будет посылать RPC вызовы на удаленный сервис, прерывать текущий файбер в ожидании ответа и возвращать результат, когда удаленный сервер ответит.

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

Сериализация
Чтобы у нас работала система посылки сообщений и удаленный вызов процедур, нам нужен клиент-серверный протокол и способ сериализации/десериализации объектов. Напомню, что у нас есть необходимость пересылать команды и данные с клиента на сервер, т.е. из C++ в Java и обратно. Для этого мы по Java-классам генерируем их копии в C++, а также генерируем методы для сериализации и десериализации объектов в байтовый поток. Код для сериализации встраивается прямо внутрь классов и обращается к полям класса напрямую. Таким образом, сервер не тратит процессорное время на обход классов с помощью reflection. Все это мы генерируем с помощью самописного плагина для IntelliJ IDEA. Внутрисерверный протокол для общения между сервисами полностью аналогичен клиент-серверному протоколу.

При сериализации какого-либо класса в байтовый поток, сначала пишется id класса, потом данные полей этого класса. На другой стороне считывается id, выбирается соответствующий класс и у него вызывается специальный конструктор, который восстанавливает класс из байтового потока.

Игровая механика

Основной сервис, который был бы вам интересен, это сервис игровой механики. Именно там выполняется весь код, непосредственно связанный с игрой, именно там моделируется весь игровой мир, летают фаерболы и «грабятся корованы».
Карты и балансировка нагрузки
На серверах игровой механики создаются карты, на которых, собственно, находятся игроки, мобы и происходит все веселье. У каждой карты есть лимит на количество игроков, которые могут на ней находиться. Например, лимит может быть равен единице для персональных приключений, 10–30 для групповых активностей и 250 для больших карт. Что происходит, если на карту захочет попасть еще один игрок, когда лимит исчерпан? Тогда будет создана еще одна копия той же самой карты. Игроки с этих карт не будут видеть друг друга, не будут друг другу мешать. Т.е. в каком-нибудь игровом городе могут быть тысячи человек, но там не будет тесно. Такой способ организации игроков называется «каналы».

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

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

Аватары и мобы
Аватар - это персонаж, которым управляет игрок, моб - это монстр, которого игрок убивает. Это весьма разные, но часто очень похожие сущности. И моб, и аватар умеют ходить по карте, у них есть здоровье, они могут использовать заклинания и т.п. Только аватаром управляет игрок, а у моба есть свой мозг. Кроме того, на картах есть множество всяких сундуков, растений и других интерактивных сущностей. Очень часто нужно делать некую функциональность и цеплять ее к разным сущностям. Для этих целей мы используем компонентный подход, собирая игровую сущность из набора функциональностей. Поясню на примере. Допустим, у игрока и моба есть показатель здоровья. В таком случае мы оформляем элемент «здоровье» как отдельный Java-класс, в котором описываем, как здоровье себя ведет: как оно может уменьшаться, как восстанавливаться, какие есть таймеры и т.п. Потом мы просто складываем все функциональности в специальную HashMap внутри сущности и берем ее оттуда по необходимости. Таких компонент у нас существуют сотни, на них собрана половина игровой механики.

Так как серверное приложение очень сложное, неизбежно возникновение ошибок. Нужно сделать так, чтобы возникновение ошибки, даже необработанного NullPointerException, не приводило к падению сервера. Можно ошибку просто залогировать и пойти дальше, но если ошибка возникнет посреди какого-то длинного действия над аватаром, то аватар может оказаться в сломанном и неконсистентном состоянии. Тут нам на помощь приходит концепция под названием «локаль». Локаль - это контекст, внутри которого объекты могут ссылаться друг на друга. Объекты из одной локали не могут ссылаться на объекты из другой. Если из локали вылетает необработанное исключение, то локаль удаляется целиком. Аватары, мобы и другие сущности являются локалями, удаляются целиком и не могут держать ссылок на других аватаров и мобов. Поэтому все взаимодействие между аватарами и мобами идет через систему сообщений, хотя они находятся вместе на одной машине и в теории могли бы держать друг на друга прямую ссылку.

Репликация
Моделировать игровой мир нужно не только на сервере, но и частично на клиенте. Например, клиенту нужно видеть других игроков и мобов, которые находятся рядом с ним. Для этого используется механизм клиент-серверной репликации, когда с сервера клиентам рассылаются обновления окружающего игрового мира. Делается это с помощью генератора кода, который встраивает отсылку обновлений в сеттеры серверных Java-объектов. Вокруг игрока создается круг определенного радиуса, и если кто-то, например другой аватар, попадает в этот круг, он начинает реплицироваться на клиент. С репликацией есть фундаментальная проблема. Если в одном месте столпится N аватаров, то на каждого из них нужно будет посылать N реплик. Таким образом возникает квадратичная зависимость, что ограничивает количество аватаров, которые могут собраться в одном месте. Именно из-за этой фундаментальной квадратичности клиенты всех ММО тормозят в столицах. Мы избегаем этой проблемы, ограничивая количество игроков на карте и распределяя их по каналам.
Ресурсная система
В игре существуют сотни и тысячи заклинаний, предметов, квестов и других подобных сущностей. Как вы, наверное, догадываетесь, программисты не пишут все сотни квестов, это делают геймдизайнеры. Программист разрабатывает один Java-класс квеста, а описания всех квестов с их логикой, задачами и текстами содержатся в XML-файлах, называемых ресурсами. При старте сервера мы загружаем эти ресурсы и на их основе собираем Java-классы с описанием мира. Этими классами уже может пользоваться сервер. Примерно такая же система существует и на стороне клиента, только там ресурсы не грузятся из XML-файлов, а просто загружается заранее созданный «кусок памяти», содержащий все нужные объекты и ссылки между ними. Ресурсных файлов у нас существует несколько сотен тысяч, но их загрузка на сервере занимает около двух минут. На клиенте же все грузится за секунды. Система очень навороченная, поддерживает такие фичи, как прототипы и наследование, вложенные описатели и т.п. Поверх ресурсной системы у нас созданы специализированные программы для редактирования карт и остальных игровых сущностей.

Сервер в действии

Давайте теперь на примерах рассмотрим несколько сценариев того, как работает вся эта система в действии.
Убить собачку
Классический тест, который мы всегда проводим, если сильно изменили инфраструктуру и хотим проверить, что все работает, называется «Убить собачку». Нужно зайти клиентом на сервер и убить там какого-либо моба. Этот тест покрывает практически все основные моменты сервера и служит прекрасным примером для того, чтобы сложить все вышесказанное вместе. Давайте по пунктам разберем, что и как происходит при убиении несчастной собачки. Конечно, некоторые шаги упрощены, но это не критично для понимания.
  • Клиент посылает на аккаунт-сервер сообщение: «Хочу войти в игру».
  • Аккаунт-сервер запрашивает базу данных, проводит авторизацию и запрашивает у балансировщика карту, на которой игрок был в последний раз.
  • Балансировщик выбирает карту из уже загруженных или создает новую на наименее загруженном сервере игровой механики.
  • Клиент подключается к той механике, где для него была создана карта. Пока он подключается, для него загружается его аватар.
  • Сервер начинает реплицировать все объекты вокруг аватара на клиент. Клиент рисует шикарную картинку и посылает на сервер команды, которые посылает игрок.
  • Игрок начинает бегать по карте, а сервер перемещает его по миру и реплицирует изменения окружающей действительности. Игрок находит какого-либо моба и нажимает кнопку «ударить».
  • Команда «удар» прилетает на сервер, на сервере выполняется проверка, что удар возможен, и мобу отправляется сообщение о нанесении повреждений.
  • Команда «нанести повреждения» отрабатывается на мобе, просчитывает все резисты и другие подобные вещи, потом берет функциональность «здоровье» и списывает какое-то количество.
  • Клиенту посылается ответ с подтверждением нанесения урона, клиент рисует удар.
Масштабирование
Давайте зайдем с другой стороны и посмотрим, как сервер ведет себя под нагрузкой.
  • 0 клиентов. Если на сервере никого нет, его можно запускать одним приложением с минимальными настройками и без карт. На сервере нет никакой активности, и большую часть времени он простаивает.
  • 1 клиент. Для одного клиента приходится создавать карту, мобов, серверные объекты, которые начинают потреблять память и процессорное время для своей жизни.
  • 500 клиентов. 500 клиентов обычно уже достаточно много, чтобы процессорного времени одной персоналки не хватало для работы сервера. Приходится запускать realm на нескольких машинах или на более мощных серверах.
  • 10000 клиентов. 10000 клиентов требуют уже нескольких серверов. Так как большая часть нагрузки приходится на игровые механики, нужно запускать realm с дополнительными сервисами игровой механики.
  • 100000 клиентов. При 100000 одновременных игроков больше половины серверов заняты игровой механикой.
  • Клиентов больше, чем железа. Если вдруг игроков станет еще больше, а железо у нас вдруг кончится, то придется ограничивать вход людей в игру, пока подвозят новые серверы. Для этого существует очередь на вход, которая заставляет игроков ждать, когда сервер будет готов их принять. Эта очередь гарантирует, что одновременно один realm не может содержать игроков больше, чем мы готовы принять. В очередь игроков могут начать ставить и в том случае, если из-за бага или еще по каким-либо причинам сервер вдруг стал работать медленнее определенного порога. Лучше сделать приемлемый сервис для ограниченного числа клиентов, чем упасть для всех.

Заключение

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

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Веб-сервер – это сервер, который принимает запросы от пользователя и выдает им ответы - документ, страницу или сайт.


Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

Любой компьютер можно сделать сервером. Для этого нужно установить специальную оболочку.

Требования к технической части определяются количеством размещенных ресурсов и требованиями к скорости. Чем они больше, тем мощнее должен быть компьютер.
Чтобы было понятно, приведем аналогию. Вы заходите в библиотеку и просите выдать вам книгу. Библиотекарь находит нужную и передает вам. Библиотека - это сервер, в ней хранятся все данные. Библиотекарь - это оболочка, которая приняла запрос и направила ответ. Вы - клиент.
Можно отправить библиотекаря за дополнительной информацией – аналогично щелчку по ссылке. Разница в том, что один и тот же ресурс в интернете могут одновременно читать неограниченное число пользователей.
Обслуживание клиента производится по схожему принципу: приходя за книгой, мы можем задать вопрос библиотекарю (поисковая система) или заглянуть в указатель (ЯндексКаталог). Это помогает найти нужную информацию.

Что делает веб-сервер

Его главная задача – хранение информации. Страницы, файлы, изображения, текстовый контент.
Задачи:

  • Получать запросы.
  • Запускать программы на специальных языках программирования (серверных).
  • Формировать веб страницы.
  • Отправлять их назад пользователю.
  • Защищать информацию.
  • Проводить идентификацию посетителей.
  • Вести журнал обращений.
  • Обслуживать запросы других типов: mailto, и т.д.

Чтобы понять, как работает веб-сервер, надо иметь представление о принципах передачи информации в сети. В основе лежат правила, называемые протоколами: любой URL начинается с указания типа (ftp, http://, https:// и пр.).
Hyper Text Transfer Protocol – протокол передачи . Страницы сайта всегда имеют вид гипертекстового документа. Это конечный результат работы любой серверной или клиентской программы.

  • Когда пользователь вводит адрес или нажимает ссылку, браузер передает запрос, кодируя информацию по этим правилам.
  • Хост, к которому привязан этот адрес, запускает программы сервера. Каждая из них выполняет свои функции.
  • Полученные данные расшифровываются, команды выполняются.
  • Формируется гипертекст, кодируется и отправляется обратно.
  • Браузер получает ответ, преобразовывает код в html и показывает на экране страницу.

Что нужно для веб-сервера

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

Есть специальные компании, которые предоставляют услуги хостинга. Сервер вы арендуете. Вам дается квота для размещения файлов сайта.
Но если у вас простенький сайт, то можно обойтись своими силами.

Когда решен вопрос с сервером, надо привязать к нему статический IP-адрес.

Сайт становится доступен на веб-сервере после того, как зарегистрировано доменное имя, выполнено преобразование адресов службой DNS - связывание IP-адреса (например, 111.111.111.111) и доменного имени (www.site.com).

Самые распространенные сервера

Apache

Это бесплатный, свободно распространяемый продукт, у которого есть масса преимуществ:

  • Постоянная поддержка разработчиков.
  • Модули для работы с серверными языками программирования PHP, Perl, Python, Ruby, ASP и т.д.
  • Открытый код. Доработкой под свои нужды занимаются разные программисты. Например, русскоязычное сообщество адаптирует его к русской кодировке.
  • . Изначально был создан под Unix, но сейчас поддерживается Windows, Mac OS, BSD, Linux, OS/2 и Novell NetWare.
  • Безопасность.

При инсталляции укажите имя вашего хоста, например, localhost. В папку htdocs, которая лежит внутри папки Apachex.x (где x.x – номер версии) скопируйте любую html-страницу. Или создайте ее в блокноте, введя любой текст и сохранив с расширением html.

Когда в папке появился файл, откройте браузер и наберите адрес: localhost://ИМЯ СТРАНИЦЫ.html. На экране появится ваш текст – страница открыта с сервера. Если вы увидели ошибку «Не удается получить доступ к сайту», значит не запущен Apache. Его значок находится в трее.
Нажмите на него и выберите «Play». После этого все заработает.

NGNIX

Доля работающих на нем активных площадок составляет 21,13% (исследования Netcraft). Его в основном используют крупные компании и профессиональные разработчики: Yandex, Mail.ru, Rambler и пр. NGNIX выдерживает огромную нагрузку посетителей, надежен, безопасен и продуман.
Распространяется свободно, но появились платные версии Plus, стоимость от 2,500 $.

IIS

Его известность обеспечена громким именем разработчика. Представляет собой набор веб служб и интегрирован с Windows. Родной платформой программирования является ASP.NET, но можно внедрить и альтернативу, например, РНР.

Для полноценного хостинга требуется установка серверной операционной системы от Microsoft – Windows Server. 6-я версия вообще не была предназначена для хостинга, полноценная поддержка началась в 7-й. Приобретается он автоматически вместе с операционной системой и зависит от ее характеристик.

Установочные пакеты

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

  • OpenServer. Портативная среда разработки, включающая множество баз данных, языков программирования и их версий, а также дополнительные сервисы. Например, интерфейс работы с БД PhpMyAdmin. На сегодняшний день это самый популярный инсталляционный набор. Работает даже с флешки. Бесплатно скачивается на низкой скорости. За 100 рублей скорость увеличивается в разы.
  • Xampp. Активно поддерживаемый пакет: Apache, Php, Perl, MariaDB и пр. Имеет панель управления. Скачивается бесплатно.
  • . Очень удобный набор всех нужных инструментов, включающий Apache, PHP, MySQL, PhpMyAdmin. К сожалению, последняя версия включает устаревшие дистрибутивы. В целом для обучения подойдут и они. Судя по форуму проект больше не поддерживается.

Контроль ошибок при написании кода

Мониторинг сайта в поисковых системах

Создание эскиза будущего проекта

Онлайн-сервисы для решения задач дизайна и веб-разработки

  • Работа с сервером

Установка сервера Apache

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

Установка и настройка PHP

Когда все работы по установке и кофигурированию сервера Apache остались позади, можно приступать к установке на компьютер PHP и его настройке для дальнейшей работы.

Установка и настройка сервера баз данных (MySQL)

Если Вы собираетесь делать сайты с использованием баз данных (а так скорее всего и будет), то для полноценной работы помимо Apache и PHP понадобится установить и настроить сервер баз данных - в нашем случае это MySQL. Об этом и будет идти речь в данной статье.

Установка и настройка phpMyAdmin

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