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