Англійська для розробників NATS Messaging

NATS зростав у популярності як легка, високопродуктивна система обміну повідомленнями для розподілених систем і мікросервісів. Якщо ви працюєте з NATS у міжнародній команді, вам потрібна чітка англійська мова, щоб описати предмети, гарантії доставки і постійність потоку. Цей підручник містить основні слова для розробників повідомлень NATS.

Ключовий словник

** Subject ** — рядок, який використовується для адресування повідомлення у NATS, подібний до теми, за якою підписники отримують повідомлення. “Ми публікуємо події замовлення на тему orders.created, а наша служба розрахунків підписується на orders.>, щоб захопити всі події, пов’язані з замовленням.”

** Опублікувати- підписатися ** — основний шаблон повідомлень NATS, за якого видавець надсилає повідомлення суб’ єкту, а будь- яка кількість підписників може отримати це повідомлення. “З publish-subscribe, додавання нової служби, якій потрібні події замовлення, не вимагає зміни видавця взагалі — вона просто підписується.”

** JetStream ** — рівень постійності, побудований на основі NATS, додає зберігання повідомлень, повторне відтворення і гарантії доставки принаймні один раз. “Ядро NATS працює за принципом “стріляй і забудь”, тому ми використовуємо JetStream, коли нам потрібні повідомлення, щоб пережити тимчасове відключення абонентів.”

** Потік ** — конструкція JetStream, яка зберігає повідомлення, опубліковані для одного або декількох суб’ єктів, зберігаючи їх відповідно до налаштованого правила. “Ми створили поток, який захоплює всі теми під orders.* і зберігає повідомлення протягом тридцяти днів.”

** Consumer ** — об’ єкт, який читає повідомлення з потоку JetStream, відстежуючи своє власне розташування, щоб його можна було відновити після перезапуску. “Кожна служба виконує свій власний постійний споживач у потоці замовлень, отже перезапуск однієї служби не впливає на роботу інших.”

** Підтвердження (ack) ** — сигнал, який користувач відсилає назад до JetStream, підтверджуючи, що він успішно обробив повідомлення, що дозволяє принаймні одну доставку.

• “Якщо споживач зазнає аварії перед підтвердженням повідомлення, JetStream передоставляє його після того, як споживач знову з’ єднається.” *

** Підписка з підказками ** — підписка, яка використовує * або > для пошуку відповідності декількох предметів одночасно, наприклад, одного рівня або всіх інших рівнів. “Ми підписуємося на orders.*.updated, щоб отримувати події оновлення для будь-якого типу замовлення в одній підписці.”

** Група черги ** — набір підписників, які мають спільну назву, де NATS доставляє кожне повідомлення лише одному члену групи, що уможливлює балансування навантаження.

• “Ми розмістили всі екземпляри нашої робочої служби у одній групі черги, отже, кожне вхідне завдання обробляється одним екземпляром.” *

Обговорення гарантій доставки

• «Core NATS дає нам майже одноразову доставку — добре для ефемерної телеметрики, але не для всього, що ми не можемо дозволити собі втратити»
• «Ми перенесли розрахункові події на JetStream, тому що нам потрібна була принаймні одна доставка з повторенням, якщо споживач відстає»
• «Наш споживач явно підтверджує повідомлення тільки після успішного запису бази даних, щоб уникнути втрати даних при аварії в середині процесу»

Розмова про масштабування і балансування навантаження

• «Використання групи черги дозволяє нам масштабувати нашу службу горизонтально, без того, щоб будь-які повідомлення оброблялися двічі під час нормальної роботи»
• «Ми відокремили споживачів з великим обсягом читання від тих, хто має великий обсяг запису за темою, тому повільний споживач на одній темі не створює резервну копію не пов’язаного трафіку»
• «Підписки з диковинками зберегли наш код підписника простим — нам не потрібно було твердо кодувати кожен можливий тип замовлення»

Професійні поради

1. ** Будьте точні щодо гарантій доставки у документації. ** « Принаймні- раз » і « Найчастіше- раз » звучать схоже, але мають дуже різні наслідки для цілісності даних.
2. ** Поясніть групи черг з точки зору розподілу навантаження, а не лише термінології. ** « Кожне повідомлення обробляється лише одним екземпляром » є більш зрозумілим, ніж первинний термін для переглядачів, які не знайомі з NATS.
3. ** Розробка споживачів таким чином, щоб вони були idempotent. ** Принаймні один раз доставка означає, що повідомлення- дублікати очікуються, а не виняткові.

Практичні вправи

1. Поясніть співробітнику команди 3- 4 реченнями різницю між основним NATS і JetStream.
2. Напишіть коротке пояснення (4- 5 речень), чому ваша служба використовує групу черг замість окремих підписок.
3. Опишіть, простою англійською, як at- at- least- once delivery вплинув на розробку вашого обробника повідомлень, і чому важлива ідемпотентність.

Розробка та впровадження систем управління якістю та контролю якості

Будьмо чесними - розуміння технічного жаргону - це тільки половина битви, коли ви розробник, який працює в глобальній команді. * Справжній * виклик часто полягає у тому, щоб передавати свої ідеї чітко і отримувати конструктивний зворотній зв’ язок, особливо коли існують відмінності у вміннях рідної мови. Це не просто про те, щоб знати визначення «потоку» або «споживача»; це про те, як ви сформулювати ці поняття для колег, які можуть інтерпретувати їх по-різному, засновані на їх власному розумінні англійської мови - і, можливо, навіть їх власні культурні стилі спілкування. Добре написане повідомлення може запобігти нерозумінням, спростити співпрацю і, врешті- решт, поліпшити якість вашого коду.

Розглянемо сценарій: Ви надіслали запит на витягнення (PR), у якому описано зміну конфігурації користувача NATS JetStream. Рецензент залишає коментар в описі PR: «Чи можете ви розібратися, чому ви обрали цю конкретну політику повторних спроб? Це здається агресивним і може вплинути на пропускну здатність. Спочатку ви можете відчувати себе в обороні або розчаровані тим, що здається нечіткою критикою. Однак, стратегічно оформивши свою відповідь - використовуючи точну мову - можна зменшити ескаляцію ситуації і призвести до продуктивної дискусії. Замість того, щоб сказати щось на зразок «Я просто подумав, що це спрацює», що є неточним і не пояснює * чому * ви прийняли це рішення, спробуйте: «Я розглядав більш агресивну політику повторних спроб, щоб забезпечити довговічність даних у разі тимчасових проблем з мережею, вирівнюючи з нашими гарантіями доставки «принаймні один раз» для цього потоку. Я задокументував потенційний вплив на пропускну здатність і буду уважно стежити за цим після розгортання. » Зауважте, що у переглянутій відповіді чітко вказано ваші аргументи, наведено посилання на відповідні поняття (тривалість даних, принаймні один раз) і продемонстровано розуміння потенційної проблеми.

Крім того, розмови Slack часто вимагають ретельної формулювання. Уявіть, що ви зневаджуєте проблему з користувачем, який не обробляє повідомлення, як очікувалося. Ви надсилаєте своєму колективу швидке повідомлення: « Потребувач не працює — потрібна допомога! » Хоча це технічно правильно, але у цьому повідомленні відсутній важливий контекст. Ефективнішим повідомленням буде: «order-processor споживач переживає періодичні невдачі; повідомлення з’являються втрачені в потоці. Я перевірив журнали і підозрюю, що можлива проблема з вичерпанням резерву з’ єднань JetStream. Зараз я розслідую [посилання на відповідний фрагмент журналу] — будь- які відомості будуть цінними». Цей докладний підхід негайно надає вашим колегам інформацію, яка їм потрібна, щоб ефективно допомогти вам, зменшуючи кількість переходів туди- назад і прискорюючи розв’ язання проблеми.

---

natsctl stream stats -s my_stream --consumer order-processor

Ця команда (за допомогою natsctl, інструменту командного рядка NATS) ілюструє практичне застосування словника, який ми обговорювали. Вивід надає * метрики * - ключові показники продуктивності - пов’язані з order-processor споживача на my_stream потоку, що дозволяє об’єктивно оцінити його поведінку і визначити потенційні проблеми. Вміння чітко інтерпретувати цей вивід і ефективно повідомляти про свої результати є ключовим для активного моніторингу і забезпечення стабільності вашої системи повідомлень NATS.