|
|
Публикувано в 25.09.2019 г. 16:11:58 ч.
|
|
|
|
Традиционно система, която обработва милиард транзакции на ден, може да изисква стотици виртуални машини, PayPal прави всичко с едва 8 виртуални машини и осигурява бърз отговор при 90% натоварване на процесора – плътност на транзакциите, каквато PayPal никога досега не е постигал, а процесът отнема 1/10 от времето, за да се постигне процесът, което помага на организацията да поддържа растежа си без да се налага да разширява изчислителната си инфраструктура и същевременно намалява разходите. Как се прави това?
PayPal мигрира системата си към режим Actor, базиран на Akka. В статията Squbs: PayPal прилага нов реактивен подход към създаването на приложения (Входът към хиперлинк е видим.PayPal обяснява всички тънкости на процеса. Сега те са направили Squbs с отворен код и го публикуват в GitHub (Входът към хиперлинк е видим.)。
Когато проектът трябва да предприеме практически подход, моделът на държавно обслужване все още не получава достатъчно внимание. За да научите повече за stateful услугите, препоръчваме да прочетете причините да продължите да изграждате мащабируеми stateful услуги сега (Входът към хиперлинк е видим.), тази статия е базирана на реч на Кейти Маккафри. Ако тази статия не ви убеждава, има и WhatsApp, който използва конкурента на Akka, Erlang, за изключително висока пропускателна способност: архитектурата на Facebook на стойност 19 милиарда долара (Входът към хиперлинк е видим.)。
Причината да препоръчвам горната статия е, че PayPal не предоставя подробно въведение в архитектурата, а отделя повече време на причините, поради които са избрали Akka и ползите от миграцията към Akka. Но тази статия все пак предоставя ценна подкрепа и демонстрация за практиката на "отклонение от утъпкания път".
Какво лошо има в използването на голям брой виртуални машини за дадена услуга?
- Пуснете услугата с много ниска пропускателна способност, изключително малки виртуални машини. Най-голямото предимство на реактивните системи, базирани на актьори, е, че те могат да използват по-ефективно изчислителните ресурси, което значително намалява размера на системата и избягва "простото и грубо" автоматично скалиране на традиционните практики.
- Това натоварва много мрежата и инфраструктурата за маршрутизиране. Тъй като услугите обикновено са по-взаимосвързани, заявките може да се наложи да преминават през голям брой мрежови преходи, което увеличава латентността и влошава потребителското изживяване.
- Колкото по-голям е, толкова по-скъп е. Услугите със стотици виртуални машини имат високи присъщи разходи по отношение на управление, мониторинг и неефективно кеширане.
- Колкото по-малък е, толкова по-пъргав е. Внедряването на услуги на стотици виртуални машини е процес, отнемащ много време.
- Извличайте повече от повече процесор на всяка виртуална машина. Тъй като процесорите не могат да бъдат допълнително ускорени, инфраструктурата трябва да може да използва по-ефективно повече процесори във всяка виртуална машина.
- Микросървизите трябва да се изграждат с слабо свързани наноуслуги, които са лесни за поддръжка и бързи за изграждане. Никой не иска да се занимава със сложна система с много слоеве, и е нужна по-голяма видимост за ролята на различните услуги, без да се навлиза дълбоко в слоеве код.
С оглед на тези фактори, PayPal искаше да изгради система, която:
- Мащабируеми не само за хоризонтално мащабиране до стотици възли, но и за мащабиране до повече процесори, за да постигнат целта за обработка на милиарди заявки на ден.
- Ниска латентност и може да се контролира с изключително фина детайлност.
- Бъдете устойчиви пред лицето на провали.
- Гъвкава корекция на границите на услугата.
- Насърчаване на мащабируемостта и простотата чрез програмни модели и култура, както и чрез по-прости механизми за управление на грешки и грешки.
Няма съмнение, че PayPal иска да използва по-"тънък" стек и не иска техният стек да съдържа много технологии и движещи се части на различни нива. Общо взето, Akka и системите, базирани на състояния, са много подходящи за тази нужда, което позволява стекът от големи компоненти да бъде "разбит" в една технология. PayPal избра Akka пред Erlang, защото имат повече опит с Java, която работи върху Java. За много хора ученето на Ерланг от нулата не е реалистично.
С Akka те могат:
- Пишете код, който е по-лесен за обяснение
- Пишете код, който е по-лесен за тестване
- Сценариите на грешки и повреди се обработват по-естествено от традиционните режими с JVM
- Пишете по-бърз, по-устойчив и по-прост код, за да обработвате грешките по-плавно и да намалите броя на грешките
PayPal веднага създаде собствена рамка, базирана на Akka, наречена Squbs, използвана за римуване с "Cubes". Това ви позволява да създадете модулен технологичен слой за изграждане на NanoService, наречен "Cube". Кубовете са симетрични, а зависимостите между различните кубове също са симетрични и свободни, като разкриват само интерфейсите за съобщения, които Akka вече предоставя.
Той също така описва трудностите, с които програмистите могат да се сблъскат при приемането на AKKA код, тъй като може да се наложи да наемете и човек, обучен в Akka/Scala.
Тъй като повечето услуги имат сходни цели: получаване на заявки, обаждане и четене и запис на бази данни, извикване на други услуги, активиране на машини за правила, получаване на данни от кешове, запис в кешове... В резултат на това услугите могат да бъдат абстрахирани чрез модели като Orchestrator Pattern и Perpetual Stream.
Squbs се е превърнал в стандартна практика за PayPal да създава реактивни приложения, базирани на Akka. Ако екипът ви все още не е обмислял системи със състояние, вероятно си струва да опитате, тъй като работят добре в PayPal, Facebook, Uber и Microsoft.
|
Предишен:Три фактора, които ме карат да пренебрегвам ChromeСледващ:vs създавам папка, а при генериране на решението няма никой под bin файла
|
