Тази статия е насочена към екипи, които използват ограничени архитектури и искат да надстроят след това, за да осигурят мащабируемост на приложението.
Най-често срещаното монолитно приложение е нещо подобно:
Това е най-разпространената архитектура за този тип продукти, понякога нещо може да се промени като промяна на монолитна база данни към база данни на обединяване (или функционално разделяне). Може да използва специален кеш сървър като Redis или да има реплики на SQL база данни.
Но основният проблем не е точно това, по-големият проблем е надграждането на архитектурата, ако имате голямо количество неочаквани потребители, мярката за сигурност вероятно ще бъде да актуализирате всички сървърни машини (сериозно нарастващи разходи)или просто гледате как приложението се срива при пиков достъп.
Както сигурно сте си представяли, първата стъпка за по-качествена архитектура е да се даде мащабируемост на това приложение, как точно ще бъде това?
Голям отказ от отговорност
- Това не е сребърен куршум за всички случаи, но би трябвало да работи в повечето случаи(сребърният куршум е приказка);
- Последователността е това, което внася организация в проекта, не променяйте кода, без първо да планирате промените;
- Някои промени могат да причинят големи проблеми, ако бъдат направени без внимание. Силно препоръчвам да имате автоматизирани тестове, преди да излезете и да промените начина на работа на системата.
Първи стъпки към висококачествена архитектура
Премахнете всички централизирани зависимости на приложението. В примерното приложение, ако има просто забавяне във всяка точка, всички приложения ще бъдат засегнати и това е наистина лошо!
Ако вашето приложение вече има интегрирана кеш система, по-добрият начин е да се преместите за независим сървър, нещо като външна база данни на Redis или подобно.
Статични активи като CSS, JS и изображения, които са в публични/активи в основния проект. Уверете се, че всичко това се сервира минимизирано на клиента и след това преместете всичко в CDN услуга, динамични изображения като профилни изображения или публикации могат да бъдат преместени в S3 услуга без проблеми.
В този момент вашето приложение вероятно няма да има нужда от централна услуга, тогава трябва да започнете да преработвате архитектурата на вашите сървъри.
Пример за това как трябва да изглежда вашата архитектура в момента
Копаем по-дълбоко
В този момент имате приложение с минимална мащабируемост в сървъра, но много критична централизирана база данни, имаме няколко различни области за атака.
Работа с реплики за четене на SQL
Когато конфигурирате SQL реплики, можете да направите балансиране на вашата база данни без вертикално мащабиране, в този случай всички оператори за избор, които изпращате към връзка с реплика, и само вмъкване, актуализиране и изтриване, които трябва да изпратите към вашата главна база данни.
В повечето системи по-големият проблем е вътре в изразите за избор, няма голям проблем, ако вашият формуляр отнема 30 или 40 секунди, за да запази данните, но ако имате това забавяне на началната страница, вероятно ще загубите потребителя си или поне ще дразни го.
Представете си административен панел, който има забавяне от 30 секунди на всеки екран, който използвате, наистина е лошо да се използва, ако изпратите тези заявки до реплики, можете да подобрите вашата база данни, така че това да не се случи.
Преместване на бавни операции към асинхронна услуга
Това вероятно е най-лесната задача в тази статия, ако използвате добра рамка, в повечето случаи вече имате интегрирана система за опашка. Всичко, което трябва да направите, е да преместите всички бавни операции към услуга за опашка и да не задържате потребителя си по време на тези операции.
Някои бавни операции, които могат да бъдат превърнати в асинхронни:
- Трета част бавни интеграции, които могат да изпращат уеб кукички;
- Тежки заявки в админ панелите;
- Актуализации на таблото за управление;
- Изпращайте имейл/sms известия.
В този случай можете да върнете само съобщение: „Нашият сървър обработва тази заявка, след няколко секунди тя ще бъде достъпна!“.
Преглед на всички API, които могат да бъдат кеширани
Не е твърде лесно да се направи, но има много голямо въздействие върху използването на базата данни. В приложения, които имат много динамично съдържание с малки промени, е задължително да имате добър кеш.
Представете си, че блог при всяко търсене на публикация трябва да търси данни в SQL базата данни, това е доста глупаво. Правилният начин е да кешира тези данни и в случай на промени да направи невалиден конкретния кеш на тази публикация, за да можете да поддържате другите кешове да работят добре.
Така че трябва само да намерите тези „критични“ точки и да създадете кеш, след което вашата SQL база данни ще бъде щастлива!
Пример за това как е вероятно да изглежда вашата архитектура
След тези стъпки със сигурност ще имате мащабируема и надеждна архитектура.
