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