Резюме:Распределенные системы, несомненно, давняя горячая тема, но на самом деле, если в этом нет крайней необходимости, настоятельно не рекомендуется входить в распределенное поле. В централизованной ситуации многие проблемы будут намного проще. Если вы хотите предоставлять услуги, Вы также должны трансформировать свои собственные продукты. Вы должны тщательно оценить, необходимо ли это. Не используйте технологию ради технологии. Тогда в случае распределенного распространения (доступ, хранилище или количество разработчиков) распределенное поле Что технологии, которыми должен овладеть квалифицированный архитектор?Об этой теме пойдет речь в данной статье.
Распределенные системы, несомненно, давняя горячая тема, но на самом деле, если в этом нет крайней необходимости, настоятельно не рекомендуется заходить в распределенное поле. В случае централизованных многие проблемы будут намного проще. Если вы хотите предоставлять услуги , вы также должны преобразовать свои собственные продукты. Вы должны тщательно оценить, необходимо ли это. Не используйте технологию ради технологии. Затем, в случае, если она должна быть распределена (объем доступа, хранения или количество разработчиков), распределенное поле Какими технологиями должен овладеть квалифицированный архитектор?Об этой теме пойдет речь в этой статье.
Просто повторите мои нормативы для архитекторов.Самое главное для архитектора не начертить несколько ящиков и соединить несколько линий(это основное требование),а контролировать технические риски.Контролировать технические риски это явно не смотреть на несколько структурных элементов.PPT может учиться.
коммуникация
Поскольку это распределенная система, технология межсистемных коммуникаций для освоения неизбежной.
Прежде всего, вы должны освоить некоторые базовые знания, такие как сетевые коммуникационные протоколы (такие как TCP/UDP и т. д.), сетевой ввод-вывод (блокирующий ввод-вывод, неблокирующий ввод-вывод, асинхронный ввод-вывод), сетевые карты (мультиочередность, и т. д.); больше прикладного уровня, необходимо изучить, например, мультиплексирование соединений, сериализацию/десериализацию, RPC, балансировку нагрузки и т. д.
Изучив эти базовые знания, вы в принципе можете написать простой модуль связи в распределенной системе, но этого далеко не достаточно.Теперь, когда вы вошли в распределенное поле, уже нет низких требований к масштабу, обычно также Это означает, что что Нужна коммуникационная программа, которая может поддерживать большое количество соединений, высокую степень параллелизма и низкое потребление ресурсов.
Обычно есть два способа для большого количества подключений:
1. К серверу подключается большое количество клиентов
Сейчас, когда NonBlocking-IO настолько зрелый, написать сервер, поддерживающий большое количество клиентов, не так уж и сложно, но в случае масштабных и обычно долговременных подключений есть один момент, на который стоит обратить особое внимание , то есть при зависании сервера При этом невозможно всем клиентам инициировать переподключение в один момент времени, что в принципе является катастрофой.Я видел несколько подобных случаев без опыта.По достижении масштаба клиент, то сервер сразу сбросится, как только перезапустится.Большое количество входящих подключений перегружено (конечно, очередь невыполненных заказов сервера сначала должна быть немного больше).Обычно, метод, который можно использовать заключается в том, что клиент засыпает в течение случайного времени перед повторным подключением, а другой заключается в том, чтобы принять алгоритм предотвращения для интервала повторного подключения.
2. Клиент подключается к большому количеству серверов
В некоторых сценариях необходимо подключить большое количество серверов, в этом случае также необходимо обратить внимание на то, чтобы не строить все соединения одновременно, а строить их пачками в пределах мощности.
Помимо установления соединений, также важно отметить, что то же самое верно и для одновременной отправки запросов.Мы должны хорошо поработать над ограничением тока, иначе легко вызвать взрыв памяти из-за некоторой медлительности.
Эти проблемы необходимо учитывать с точки зрения технических рисков и отражать в дизайне и реализации кода, иначе при увеличении масштаба проблемы какое-то время будет непросто решить.
Высокий уровень параллелизма требует владения CAS, общими алгоритмами без блокировок, блокировками чтения-записи, знаниями, связанными с потоками (такими как взаимодействие потоков, пулы потоков) и т. д. Высокий уровень параллелизма на уровне связи — это самое важное в случае неблокирующих. Ввод-вывод Обратите внимание на то, чтобы свести к минимуму время, занимаемое пулом потоков ввода-вывода в общем дизайне и реализации кода.
Что касается низкого потребления ресурсов, то в основном это сделал сам NonBlocking-IO.
Масштабируемость
Распределенные системы в основном означают, что масштаб не мал. Для таких систем вопросы масштабируемости должны учитываться при проектировании. Для любой точки, нарисованной на диаграмме архитектуры, если количество запросов или данных продолжает увеличиваться, как это можно сделать? решается путем добавления машин.Конечно, этот процесс не требует рассмотрения бесконечных сценариев.Если у вас есть опытные архитекторы от относительно небольших до очень больших, очевидно, что преимущества не маленькие, и это также будет становиться все более и более дефицитным.
Проблема масштабируемости решается в следующих двух сценариях:
1. Сценарии без гражданства
Для сценариев без сохранения состояния относительно просто добавить поддержку машин по мере роста количества.В этом случае необходимо решать только проблемы, обнаруженные узлами.Обычно это можно сделать на основе балансировки нагрузки, аппаратной или программной;
В сценарии без состояния в БД обычно помещается много состояний, и после того, как эквивалент достигнет определенного этапа, необходимо будет ввести сервитизацию, чтобы облегчить ситуацию со слишком большим количеством подключений к БД.
2. Сценарии с отслеживанием состояния
На самом деле, так называемые данные состояния, обычно Sharding для достижения масштабируемости, Sharding различных реализаций, так мало общего:
2.1 Разделение правил
Разделение данных о состоянии на основе определенных правил. Например, таким образом часто используются подбаза данных и подтаблица. Этот метод поддерживает масштабируемость, но обычно также требует очень сложного управления, перемещения данных о состоянии и даже сложных бизнес-функций. , такие как глобальные соединения, транзакции между таблицами и т. д.
2.2 Консистентный хэш
Последовательная схема хеширования снизит стоимость добавления машин, а давление может быть более сбалансированным.Например, часто используется распределенный кеш, который в основном аналогичен проблеме, вызванной обычным шардингом.
2.3 Auto Sharding
Преимущество Auto Sharding заключается в том, что вам в основном не нужно беспокоиться о перемещении данных, и можно добавлять машины по мере увеличения объема, но обычно в случае Auto Sharding будут относительно высокие требования к тому, как использовать это, и это, как правило, вызывает некоторые ограничения.Такая схема, как HBase.
2.4 Copy
Копирование, которое часто встречается в ситуации, когда операций чтения гораздо больше, чем операций записи, при реализации будет иметь в конечном счете согласованное решение и глобально согласованное решение. такие, как zookeeper/etcd, и не только. Трудно достичь глобальной согласованности и высокой возможности поддержки записи.
Даже сегодня проблема масштабируемости в методе шардинга по-прежнему является большой проблемой, и ее очень трудно решить.
Вышесказанное в основном лишь направление решения.Нетрудно судить, что это архитектор, который решает слишком много масштабных сценических задач, когда дело доходит до деталей. :)
стабильность
Как распределенная система, вы должны подумать, как поступить в случае отказа любой точки во всей системе (при достижении определенного масштаба машины нормально зависать несколько машин каждый день). состояние:
1. Сценарии без гражданства
Для сценариев без сохранения состояния это обычно легко обработать. Можно использовать только механизм обнаружения, такой как сердцебиение, в механизме обнаружения узлов. Из опыта следует, что полагаться на 4-уровневое обнаружение недостаточно для бизнеса, обычно это должно быть сделано в 7 слоев, конечно., чтобы сделать 7 слоев, вы должны иметь дело с проблемой после того, как масштаб большой.
2. Сценарии с отслеживанием состояния
Для stateful сценариев это более хлопотно.Это нормально, если требования к согласованности данных не высоки, и в принципе можно использовать основные и резервные типы решений.Конечно, не так просто добиться успеха в активных и резервных решениях. Такого рода схема, в случае, если основная и резервная схемы не очень удобны, типа HBase, это означает, что одна зависнет, и потребуется некоторое время, чтобы другая приняла ее, что оказывать определенное влияние на доступность;
В сценарии с глобально согласованным типом, если одна машина выходит из строя, это обычно означает, что должен быть механизм выбора, чтобы решить, какая из других машин станет главной, например, реализация, основанная на paxos.
ремонтопригодность
Ремонтопригодность — это часть, которую легко упустить, но на самом деле это очень важная часть для распределенных систем, например, то, как вся системная среда должна быть построена, развернута, поддерживающие инструменты обслуживания, точки мониторинга, точки тревоги, локализация проблемы и обработка проблемы. стратегия и др.
Из навыков, которые необходимо освоить выше, вы можете понять, почему так сложно найти квалифицированного архитектора в распределенной области.Более того, вышеперечисленное является лишь общими техническими моментами в распределенной области, но обычно все, что вам нужно, это архитектор в конкретной распределенной области, такой как распределенная файловая система, распределенный кеш и т. д., архитектор в конкретной области должен иметь знания и навыки в конкретной области на основе вышеперечисленных технических моментов, что еще сложнее .
С развитием интернета многие технологии в распределенной сфере взрослеют.Вспомните как проектировалась масштабируемость крупного сайта 8 или 9 лет назад.На самом деле структура всем известна,а хороших систем еще много с открытым исходным кодом, так что многие вещи, требующие опыта, также были ускорены.При поддержке различных хороших продуктов с открытым исходным кодом сложно построить распределенную систему в будущем.Оно определенно будет уменьшаться все более и более значительно, и облако будет ускорить этот процесс.
ps: В процессе написания этой статьи я обнаружил, что судить о том, насколько силен технарь, несложно.Просто попросите ТА написать или рассказать обо всех технологиях, которые, по их мнению, они понимают, и посмотрите, насколько толсто они могут написать или говорить.Как долго... Нелегко писать толсто или долго говорить, хотя я не отрицаю, что нелегко писать ясно или объяснять ясно, но надо сначала толсто, а потом тонко.
Автор: Али Биксуан