2018-03-26 Technopolis Typical Architecture.md

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

<p>
# Лекции Технополиса. Проектирование высоконагруженных систем (осень 2017).
Tags: читательский дневник, высоконагруженные системы, конспект, спойлеры
</p>

<p>
[Статья на хабре](<a href="https://habrahabr.ru/company/odnoklassniki/blog/347798/" class="urlextern" target="_blank" title="https://habrahabr.ru/company/odnoklassniki/blog/347798/" rel="nofollow noopener">https://habrahabr.ru/company/odnoklassniki/blog/347798/</a>)
</p>

<p>
[Лекция #2. HIGHLOAD. Типовые архитектуры | Технострим](<a href="https://www.youtube.com/watch?v=m9S37qxbvN8" class="urlextern" target="_blank" title="https://www.youtube.com/watch?v=m9S37qxbvN8" rel="nofollow noopener">https://www.youtube.com/watch?v=m9S37qxbvN8</a>)
</p>

<p>
Докладчик проходится по следующим темам построения архитектуры бэкенда:
- развитие от толстых клиентов (приложение) в тонкие (web) и обратно в толстые (web)
- ресурсы серверов, способы оптимизации одного ресурса за счет другого
- переход от вертикального масштабирования серверов к горизонтальному, как распределить бэкенд при горизонтальном масштабировании
- работа с централизованной БД и переход к распределенным БД
- ACID, CAP, проблемы кешей
- очереди
- микросервисная архитектура
</p>

<p>
Перечислены плюсы, минусы и стоимость перехода на более сложную архитектуру, описаны типовые проблемы обеспечения консистентности и их решения.
</p>

<p>
Доклад хорошо воспринимается на скорости х1,5
</p>

<p>
Далее вольный конспект.
</p>

<p>
***
</p>

<p>
#### Сравнение архитектур
</p>

<span class='np_break'> </span>
<div class="table-responsive sectionedit1"><table class="inline table table-bordered table-hover table-condensed">
	<tr class="row0">
		<td class="leftalign">			</td><td class="col1">Толстый клиент </td><td class="leftalign">Тонкий клиент(web)	</td><td class="col3"></td>
	</tr>
	<tr class="row1">
		<td class="col0">—-</td><td class="col1">—-</td><td class="col2">—-</td><td class="col3">—-</td>
	</tr>
	<tr class="row2">
		<td class="leftalign">Трафик			</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row3">
		<td class="leftalign">Задержки		</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row4">
		<td class="leftalign">Кэширование		</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row5">
		<td class="leftalign">Постоянное соединение	</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row6">
		<td class="leftalign">Пуши			</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row7">
		<td class="leftalign">Работа в оффлайн	</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row8">
		<td class="leftalign">Сервер без состояния	</td><td class="leftalign"> + 		</td><td class="leftalign"> -			</td><td class="col3"></td>
	</tr>
	<tr class="row9">
		<td class="leftalign">Обновление		</td><td class="leftalign"> - 		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
	<tr class="row10">
		<td class="leftalign">Совместимость API	</td><td class="leftalign"> - 		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
	<tr class="row11">
		<td class="col0">Консистентность состояния</td><td class="leftalign"> - 		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
	<tr class="row12">
		<td class="leftalign">Локализация		</td><td class="leftalign"> - 		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
	<tr class="row13">
		<td class="leftalign">Эксперименты		</td><td class="leftalign"> - 		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
	<tr class="row14">
		<td class="leftalign">Скорость разработки	</td><td class="leftalign">		</td><td class="leftalign"> +			</td><td class="col3"></td>
	</tr>
</table>
<span class='np_break'> </span>
</div>
<p>
###### Проблемы производительности (при росте продукта):
 - Пропускная способность. Увеличивается объемы трафика, нужно чтобы сеть и оборудование могло с объемом справляться
 - Ошибки. Пользователь не должен получать ошибки, при горизонтальном масштабировании нужно уметь повторять запросы и уметь определять в каком месте произошла ошибка (что трудно, когда много серверов, либо когда один запрос обрабатывает несколько сервисов)
 - Время обслуживания. В 99.9 процентиле, запрос пользователя должен обрабатываться менее, чем за 300мс. При внедрении микросервисов нужно учитывать повышение латентности обработки запроса, по сравнению с монолитом
</p>

<p>
Нужно уметь считать потребление основных ресурсов сервера: память, процессор, диск, сеть и понимать, что один ресурс можно менять на другой.
</p>

<p>
Нужно понимать сколько пользователей вашего сервиса поместится в память (актуально для демонов с БД в памяти), за счет применения других структур данных можно сократить потребление памяти за счет потребления процессора. Память работает не так быстро, как процессор, за счет больших вычислений и меньшего обращения к памяти - можно повысить утилизацию процессора.
</p>

<p>
У процессора можно определить процент полезной работы вашего кода от системного времени ОС(system) и времени ожидания IO (iowait). Возможно, стоит ускорить работу за счет тюнинга/настройки ОС, либо определить что алгоритм не оптимально обращается к системе (слишком много ждет).
</p>

<p>
Так как гигагерцы уже так сильно не растут, следует уделять внимание многопоточному программированию.
</p>

<p>
Стоит учитывать возможные объемы дискового пространства сервера, латентность доступа к диску и количество операций/байт с диском.
</p>

<p>
У сети тоже нужно знать латентность и объем доступной полосы пропускания, в ДЦ она на порядок ниже, чем доступ к диску. Также не стоит забывать о возможном лимите на количество сетевых пакетов, т.к. это нагружает сетевой стек.
</p>

<p>
###### Оптимизации утилизации ресурсов. Можно обменивать в разные стороны:
 - процессор/память. С помощью более вычислительно-емких структур данных сократить объем данных в памяти (например, применить сжатие). С помощью избыточных данных в памяти производить меньше расчетов на CPU (например, расширить структуру данных предрасчитанными полями или кешем).
 - память/диск. Кэшировать данные с диска в памяти. Переносить редко-используемые данные на диск.
 - процессор/объем. Пропускная способность/задержка. Обрабатывать запросы/данные пачками (векторные операции в cpu, запись нескольких запросов на диск одним большим блоком, группировка запросов, перед отправкой в сеть) - увеличит пропускную способность системы, но повысит время ожидания обработки одного запроса.
Часто за счет этих оптимизаций происходит неверное трактование результатов бенчмарков. Например, БД отдает данные быстрее, чем может их читать с диска (или записать), либо пакетная обработка запросов работает быстрее, чем способен выдержать сетевой стек при одном запросе на пакет. Нужно учитывать эти допущения при исследовании.
</p>

<p>
###### Разделение бэкенда:
 - Веб сервер &lt;→ сервер логики. Позволит делать разные "фронтенды" к логике (веб-сервер, API-сервер, клиент для мобилок), проще тестировать, поможет в архитектурном разделении кода.
 - Шардирование по веб-серверам. Средняя сложность. Требуется маршрутизирование до веб-сервера. Если на веб-сервере есть состояние, то клиента нужно закреплять за веб-сервером, либо выносить состояние на внешний сервис.
 - Функциональный сервис. Малая сложность. Если БД будет внешняя, то можно реализовать собственную функцию шардирования на веб-сервере и больше проблем не будет.
 - БД. Максимальная сложность. Проблема единой точки отказа, лага в репликации, отсутствия атомарности при обновлении нескольких БД.
</p>

<p>
###### Проблема отказов. Если сервер, при выполнении запроса клиента возвращает ошибку, что показывать клиенту?
 - Сдаваться, нельзя повторять (at most once) - отобразить ошибку клиенту, пусть он сам решит что с ней делать
 - Сдаваться нельзя, повторять (at least once) - повторять запрос, пока он не выполнится
Проблема в том, что при отказе непонятно, выполнился запрос (например, была ли запись в БД) или нет. Возможно, что дублирующий запрос продублирует данные.
Для этого нужно реализовать идемпотентные операции (повтор которых не приводит к порче или дублировании информации).
Например, перед отправкой запроса на добавление нового сообщения в чат, получить от сервера ID нового сообщения. В этом случае, при повторной отправке, по ID сообщения, БД сможет понять есть ли у нее уже это сообщение.
</p>

<p>
###### Оптимизации работы с СУБД:
 - построить индексы по всем использующимся запросам
 - использовать только короткие транзакции (не выполнять долгие операции в коде, между началом и окончанием транзакции, например сетевой запрос)
 - денормализировать данные для более быстрого доступа к ним
 - минимализировать логику, хранящуюся в СУБД
 - минимум Foreign Key (???)
</p>

<p>
###### Проблемы распределенных БД:
 - Мастер-слейв. При синхронной репликации, отказ слейва приводит к неработоспособности мастера, либо к неконсистентности слейва. При асинхронной репликации данные на слейве будут запаздывать. Возможна проблема, когда после запроса на запись к мастеру идет запрос на чтение к слейву и данные не находятся, лечится отправкой близжайших запросов на чтение к мастеру, а лаг других клиентов, выполняющих чтение считается допустимым.
 - Мастер-мастер. Проблема конфликтов. Лечится кворумом (большинство право), либо работой с разрешением конфликтов: автоматически last win в Cassandra, либо вручную: Vector Clock в Voldemort/Riak, с помощью оптимистичной блокировки (CAS, compare and swap), paxos, структурами данных без конфликтов (Conflict-free replicated data type CRDT, умеет не все).
</p>

<p>
###### Проблемы кэширования:
 - холодный старт. При рестарте кеша с потерей состояния БД может не справиться с количеством запросов. Решение: система кэширования должна сохранять состояние на диск.
 - отказы при обновлении кеша. В БД информацию обновили, а при обновлении кеша произошла ошибка. Решается отдельным процессом обновления значений в кеше: сохранение timestamp изменений в БД и вычитывании свежих изменений фоновым процессом и применение его в кеш, либо посылка лога репликации на сервер кеша и его применение к кешу. Допускается лаг обновления данных в кеше, зато данные в конечном счете придут.
</p>

<p>
###### Очереди.
 - низкое время обработки запросов
 - масштабируемость обработчиков
 - эластичность. Скачки количества запросов не приведут к отказам, просто увеличится время их выполнения
 - отказоустойчивость
 - последовательность обработки. Для исключения проблем конкуренции, можно использовать очередь для последовательной обработки запросов
</p>

<p>
Фишки:
 - cпособ хранения: память, диск, распределенные
 - гарантии доставки
 - queue/Topic. Можно читать по событию из очереди, а можно подписываться на события
 - отложенная доставка
 - протухание. Иногда необработанные события теряют свою актуальность
 - пакетная обработка. Сбор пачки событий для более производительной обработки
</p>

<p>
Проблемы:
 - не избавляет нас от проблем атомарности в распределенных системах: если агент обработки очереди сделал запись в БД и БД отпала - непонятно обработалась ли запись в очереди. Все аналогично с проблемой отказов
 - требуется мониторить очередь, отследить ее переполнение и ситуации, когда обработка очереди не поспевает за новыми запросами (есть хорошая лекция по поводу проблем очередей <a href="https://www.youtube.com/watch?v=CvT1v7xiRS0" class="urlextern" target="_blank" title="https://www.youtube.com/watch?v=CvT1v7xiRS0" rel="nofollow noopener">https://www.youtube.com/watch?v=CvT1v7xiRS0</a>)
</p>

<p>
###### Микросервисы
Фишки:
 - масштабирование
 - простота разработки: быстрая компиляция и запуск, меньше связанность, проще тестирование, гибкий цикл релизов
 - простота развертывания
 - изоляция отказов
</p>

<p>
Минусы:
 - производительность
 - сложность разработки: удаленные вызовы, discovery, сложная отладка
 - сложность развертывания
 - больше точек отказа
</p>

<p>
Боль:
 - конфигурация
 - сбор логов
 - сбор статистики
 - мониторинг
</p>

<p>
###### Выводы:
 - отказы всегда есть и будут, нужно учитывать их при проектировании архитектуры. Другими словами, если нет необходимости дробить сервисы - не дробите, не привнесете туда проблем
 - физические ограничения нужно знать и понимать. При завышенных показателях бенчмарков - нужно понимать за счет чего это достигается
 - CAP теорема - не бывает идеальных распределенных БД
 - при усложнении архитектуры бэкенда и технологий, проблемы не уходят, а трансформируются в другие, более сложные. Но при росте проекта это необходимо
</p>

<p>
~~OWNERAPPROVE~~
</p>
<!-- EDIT1 TABLE [1820-] -->