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