|
|
Опубликовано 15.03.2018 10:03:44
|
|
|
|
В предыдущем разделе мы говорили о двух самых низких концепциях Service Fabric: Node Type и Node на аппаратном уровне. Другая — это применение.
Тип узлов — это коллекция узлов, которые представляют собой концептуальные абстракции машин, развёртывающих машины. Для Service Fabric узел может быть физической машиной, виртуальной машиной или даже самым популярным контейнером сейчас.
На типе узла выполняется Application. Это абстрактное понимание на уровне системного программного обеспечения. В приложении есть несколько микросервисов. Даже все базовые сервисы Service Fabric, такие как FailoverManager Service и Naming Service, являются микросервисами.
Все распределённые функции Service Fabric соответствуют развертываниям Micro Service. Мы можем динамически регулировать количество экземпляров, которые нужно запускать микросервис на скольких узлах, чтобы распределять нагрузку или выполнять резервные копирования после аварийного восстановления. Каждый экземпляр прослушивает отдельный порт, а уровень балансировки нагрузки распределяет запросы между разными экземплярами.
Реальный сценарий
Государственное обслуживание — одна из микрослужб.
Прежде чем мы начнём внедрять Stateful Service, давайте рассмотрим следующие распространённые бизнес-сценарии.
Вы думаете о внедрении функции корзины для покупок на вашем сайте. После входа пользователи помещают некоторые товары в корзину для покупок.
В следующий раз, когда пользователь войдёт в систему, страница ресепшена вызовет сервис корзины, и ему нужно будет перечитать сохранённые данные корзины с этой службы и отобразить их.
Если да, то как бы вы этого добились?
Если количество пользователей не слишком велико, мы добавляем таблицу корзин в базу данных и связываем её с пользовательской таблицей. В таблице корзины будет поле user ID и будет записывать большое количество данных пользовательского корзины.
Тогда возникнут последующие проблемы.
Если число пользователей продолжит расти, производительность таблиц базы данных будет продолжать снижаться.
Данные таблицы базы данных необходимо регулярно резервировать на случай потери данных
Если возникает проблема с производительностью базы данных, таблицу необходимо опровергнуть или даже разделить на раздел
Сама система корзин для покупок должна справляться с любыми изменениями в базе данных, и, возможно, потребуется балансировка нагрузки
Корень этой проблемы в том, что сама система изначально не предназначена для масштабирования. Кроме того, базы данных представляют потенциальное узкое место и угрозу производительности.
Государственная служба
Давайте рассмотрим такую совершенно новую архитектуру.
С самого начала система корзин для покупок имела 36 подсервисов, обрабатывающих все запросы (36, потому что инициалы идентификатора пользователя — 0-9 a-z, всего 36).
Запрос пользователя обрабатывается согласно исходному хэшу идентификатора пользователя для конкретного подсервиса.
Субсервис хранит данные корзины для покупок внутри себя через лёгкую базу данных и сохраняет их на собственном устройстве хранения.
Каждый подсервис также имеет 3 резервных копии, которые постоянно синхронизируют хранящиеся данные, и эти резервные копии всегда выполняются на разных узлах.
В то же время только одна резервная копия отвечает за обработку запросов в состоянии активации, и при проблеме с активацией резервного копирования две другие резервные копии активируют одну в соответствии с алгоритмом планирования.
Подсистема аварийного восстановления создаёт новую резервную копию, чтобы у подсервиса всегда было 3 здоровых резервных копия.
Государственное обслуживание — одно из таких решений.
Возвращаясь к вышеуказанному сценарию, система корзин для покупок является сервисом с состоянием.
36 подсистем — это 36 экземпляров этого Stateful Service, который мы называем Partitions.
Резервная копия под каждой подсистемой — это Replica, и в разделе есть 3 реплики.
Активная резервная копия — Активная реплика, а две неактивные резервные копии — Вторичная реплика.
Каждая реплика одного и того же Партиона должна работать на разном узле.
Код Stateful Service использует <T>интерфейсы, такие как IReliableCollection, IReliableDictionary< T1 и T2 >для сохранения данных и внутренней синхронизации.
Кроме того, Stateful Service может реализовать следующие функции:
Все вышеуказанные числа можно сбросить, и в системе картридж можно создать сотни разделов для увеличения нагрузки. Можно даже иметь 5 и более реплик на раздел, чтобы обеспечить большую надёжность.
Внешние системы не заботятся о том, сколько разделов у Stateful Service — они вызываются по ключу раздела. Ключ раздела и соответствующий раздел разрешаются базовой MicroService of Service Fabric. Например, в вашем бизнесе у вас может быть несколько миллионов пользователей, но вы настроите только 5 разделов. При вызове корзины для покупок Stateful Service внешняя система должна указать только идентификатор пользователя (ключ раздела) и сохранённые данные. Этот запрос автоматически отображается в один из пяти разделов на основе user ID и хеш-алгоритма.
Операции с данными в Stateful Services поддерживают транзакции. Так что при неудачах можно откатить
Надеюсь, вышеописанное введение поможет вам лучше понять государственное обслуживание.
В следующих разделах мы рассмотрим примеры кодов для государственной службы. |
Предыдущий:Надеюсь, вы сможете обсудить это друг с другомСледующий:Сорок семь способов оптимизировать программу на C#
|
