Има някои проблеми при кръстосаното публикуване поради диалекта на маркировката в оригиналната публикация. Особено диаграмите не са показани, които съществуват в оригиналния пост. Така че, моля, проверете и оригинала, ако се интересувате. Мисля, че оригиналът е по-разбираем

Надстройка на HBase върху извора на събития и архитектурата CQRS за 3 седмици

TL; DR

Използвахме синьо-зелена стратегия за внедряване за надстройката на версията на HBase върху системата за извор на събития и архитектура CQRS.
Подходът за внедряване работи доста добре и отне само 3 седмици общо за постигане на целта на проекта. Това преживяване беше ново и вълнуващо за нас. Така че искам да го споделя :)

Относно надстройката на базата данни

Надстройката на базата данни винаги е обезпокоителна и винаги, когато се справяте с подобни обстоятелства в производствените сценарии, ще бъдете супер нервен (бих казал 100 пъти в сравнение с други производствени операции, с които се занимавате) .

Това чувство е трудно да се сподели с хора, които нямат опит или експозиция в работата със средите на базата данни. И мисля, че 99,9% от хората биха се съгласили, ако имате опит и сте преминали през трудни времена в справянето с операции, свързани с базата данни. Това е рисковано и струва много, но самото надграждане не означава, че предоставя нова стойност на продукта и въпреки че не е приоритетно в много случаи, освен ако няма някаква спешна причина.

В същото време е огромен скрит риск, ако базата данни стане „недосегаема“ и как да се справим с този проблем е тема навсякъде, много разработчици и оператори се борят с подобни ситуации

Подход за надграждане

Като цяло ще имате два избора.

непрекъснато надграждане

Единият е подвижен ъпгрейд. Надграждане на версията на базата данни една по една по последователен начин.
Тук намерих добро обяснение. Моля, прочетете това, ако не сте запознати с думата.

Какво означава непрекъснато надграждане при разработката на софтуер?

Плюсове
- Данните са на едно място. Така че не е нужно да мислите как да синхронизирате данните между различни клъстери и как да гарантирате, че синхронизирането работи перфектно.
Минуси
- След като надстройката приключи, няма лесен начин за връщане. Така че, ако надстройката предизвика проблем с производителността по някакъв начин, ще имате големи проблеми.
- Дългосрочната база данни има някакво неочаквано състояние, което не можете да възпроизведете в тестовата среда. Понякога трябва да се справите с проблема, що се отнася до производството. И тази възможност наистина те изнервя.

синьо-зелено внедряване

Другият е синьо-зелено разгръщане. В този случай трябва да осигурите отделно надстроения клъстер на базата данни и в даден момент да превключите приложението, за да използва новото.
Моля, проверете тази публикация в блога, ако не сте запознати с думата „синьо-зелено внедряване“.

BlueGreenDeployment

Мисля, че този подход е широко разпространен при внедряването на уеб приложения, но ако замените думата „рутер“ с „приложение“ и „уеб сървър“ с „база данни“, същият подход може да се приложи и за надграждане на база данни.

Плюсове
- Не докосвате работещата производствена база данни, докато надграждате. Това прави живота ви много лесен в сравнение с подхода за непрекъснато надграждане.
- Можете лесно да се върнете към стария клъстер, когато възникне някакъв неочакван проблем. Освен това можете да разпределите заявките постепенно, така че да можете да сведете до минимум обхвата, в случай че имате някакъв проблем (за да направите това, както в „Против“, трябва обаче да синхронизирате данни от нов клъстер към стар)
- Поради фактора по-горе можете донякъде да съкратите тестването на натоварване на тестовата среда и да продължите бързо с проекта.
Против
- Трябва да се уверите, че данните са синхронизирани между двата клъстера на базата данни. Не само от стар клъстер към нов клъстер, но и от нов клъстер към стар клъстер, ако искате да имате лесен начин за връщане след надстройката. Но взаимното възпроизвеждане на данни е доста трудно в много случаи. Възможно е да се записва в два клъстера за всяка операция, но трябва да се подготвите, когато само един клъстер не работи и операцията само към този клъстер е неуспешна. Това манипулиране би било наистина сложно.
- Трябва да имате сървъри с двоен размер, докато изпълнявате и двата клъстера. Това ще струва малко пари и може да бъде трудно, ако системата ви не е в облачна инфраструктура.

Нашият подход

По принцип нашият подход е синьо-зелено разгръщане. И тъй като имаме Kafka отпред като шина за източник на събития, беше много по-лесно да се справим с проблема със синхронизирането на данни в „Против“, изброени по-горе.

Текуща архитектура

Първо, нека ви представя основната архитектура. Между другото, ние наричаме цялата подсистема за съобщения в чат "Falcon". Ето защо иконата на сокола е на диаграмата.

когато краен потребител публикува чат съобщение, write-api поставя данни за съобщението в Kafka
read-model-updater („rmu“ накратко) извлича данни от Kafka, преобразува ги в read-model и ги поставя в HBase.
когато краен потребител чете съобщения за чат, read-api изтегля данни за съобщения от HBase

Не обяснявам защо избираме CQRS в тази публикация. Така че, моля, проверете слайдовете по-долу, ако искате да знаете подробно или ако не сте запознати с концепцията за CQRS.
Kafka Summit SF 2017 – Световни мащабируеми и устойчиви услуги за съобщения с Kafka и Kafka потоци
Световни мащабируеми и устойчиви услуги за съобщения чрез CQRS и източници на събития с помощта на Akka, Kafka Streams и HBase

Поток за надграждане на база данни

Сега ще обясня как направихме надстройката на базата данни върху тази архитектура

Стъпка 1: Подгответе нови клъстери и направете първоначално възстановяване от архив.

Стъпка 2: Подгответе друг потребител (rmu2 в тази диаграма) за синхронизиране на данни от Kafka към нов клъстер от база данни. Ще възпроизвеждате отново стари събития на Kafka, започвайки от преди първоначалното възстановяване. Уверете се, че прилагате идемпотентност към вашия потребител. Искам да кажа, че системата трябва да работи правилно, дори ако едно и също събитие се използва повече от веднъж.

Стъпка 3: Когато новият потребител (rmu2) е настигнал най-новите съобщения на Kafka, подгответе друг API за четене, изтеглящ данни от новия клъстер на базата данни. И изпращайте заявки към нов read-api постепенно.

Ще има някаква разлика в състоянието между стария клъстер и новия клъстер, дори ако синхронизирането на данни приключи за няколко милисекунди. Имахме малък проблем поради тази разлика, така че трябва да потвърдите и изпълните проверка за оценка, за да видите какъв вид проблем може да се задейства чрез разликата между клъстерите и логиката на приложението ви предварително. Или ако имате някои добри слоеве пред read-api, за да разпределите заявката според потребителския атрибут или нещо подобно (например маршрутизиране чрез Nginx или Envoy като прокси), можете просто да зададете правилното правило там и разликата може да бъде обработена ефективно и няма да е проблем.

И в ретроспективата на този проект забелязахме, че ако можете да отразявате заявките от съществуващ API към нов API, можете да направите тестване на натоварването, използвайки производствен трафик, без да засягате крайните потребители.

Стъпка 4: Превключете към нов read-api 100% и изключете старите клъстери и приложения, когато сте сигурни, че всичко работи перфектно.

Защо смятам, че този подход е по-добър

Нека обясня разликата с нормалния синьо-зелен подход. Един проблем в нормалното синьо-зелено е, че трябва да се уверите, че данните са синхронизирани и в двата клъстера, в идеалния случай не само преди надстройката, но и след надстройката. При този подход, вместо да се използва функционалност за репликация, която предоставя базата данни, актуализациите на базата данни се прилагат отделно чрез приложението, което пишем и подготвяме. Този подход ни носи много предимства.

Първо, тъй като те работят отделно, не е нужно да се интересувате как данните се синхронизират във всяка фаза. По-специално, ще ви трябват някои допълнителни (и доста трудни в повечето случаи) усилия за синхронизиране на данни от нов клъстер към стария клъстер, ако искате да имате лесен начин за връщане след надстройката. Но при този подход те просто работят независимо. Така че можете просто да се върнете към използването на стари, в случай че след надстройката започне да се случва някакъв неочакван проблем.

Второ, не е нужно да се притеснявате за съвместимостта на версиите между стари и нови клъстери. Ако използвате функционалност за синхронизиране на клъстерни данни, която базата данни предоставя, ще има някои ограничения на версията и проблем със съвместимостта, които могат да възникнат в някои крайни случаи. Но при този подход всичко, което трябва да направите, е да подготвите независимо приложение, което въвежда данни във всяка база данни. Мисля, че това е проблемът, който в повечето случаи можете да решите много по-лесно. И на теория, не само актуализирате версията на базата данни, но също така можете да превключите новия клъстер към напълно различен (например DynamoDB), като използвате същия подход. В този случай не можете да използвате резервните данни за първоначална настройка и трябва да подготвите първоначална програма за миграция на данни. Това ще отнеме известно време, но мисля, че това е разумният елемент за справяне.

Заключение

Темите за CQRS и източници на събития често се обсъждат в софтуерната архитектура. От оперативна гледна точка наличието на още един слой като шина за събития увеличава сложността на инфраструктурата и оперативните разходи. Честно казано, преди не ми харесваше този подход от тази гледна точка. Но забелязахме, че това също променя начина, по който оперираме с инфраструктурата и ни носи спокойствие в работата на базата данни. И да, сега съм много забавен от CQRS и източници на събития :)

Следващо предизвикателство

Може би се чудите какво бихме надградили Kafka (автобус за извор на събития)? Да, това ще бъде следващото ни предизвикателство. Надявам се, че съществува по-добър подход от нормалното подвижно надграждане и синьо-зелено внедряване. Животът на инженера продължава!