«Вимоги до надійності вище, ніж в середньому энтерпрайзе»: Дойче Банк про Java-розробки і конференціях

Технологічний Центр Дойче Банку відомий своїми Java-спікерами: Руслан Черемин та Олексій Рагозин давно виступають на конференціях, вибираючи для доповідей далеко не самі доступні теми, і обидва ведуть технічному блогу. Дойче Банк взяв участь у Joker 2016, і ми використали це як привід поставити Черемину з Рагозиным по декілька питань.





Руслан Черемин (senior developer)

— Про вас зазвичай знають просто «він з Дойче» — а чи можете розповісти про те, чим саме там займаєтеся і як саме (наприклад, які інструменти використовуєте)?

— Ми займаємося валютним ринком. Зокрема, команда, в якій я працюю, займається генерацією цін на валютні інструменти — ми збираємо інформацію з багатьох ринків, застосовуємо до неї особливу магію, і вирішуємо, за якою ціною зараз готовий торгувати цією конкретною валютою зі своїми клієнтами Дойче Банк.

Нічого сильно незвичайного з інструментів у нас тут немає: у Дойче Банку ліцензія на IDEA, хоча деякі фахівці ще за звичкою розробляють в Eclipse. Для складання використовуємо Maven і Ant, сусідні команди використовують Gradle.

— В «Без слайдів» ви говорили «виявилося, що Дойче Банку якраз був потрібен такий фахівець, як я» — а що саме означало «такий, як ви», у чому саме була відповідність ролі?

— В той момент моя нинішня команда збиралася переписувати з нуля сервер генерації цін — з Disruptor, та іншими фокусами. У них була вакансія для людини, який буде основним розробником цього нового сервера, і доб'ється з його допомогою нових красивих цифр latency. А тут я з доповіддю про Disruptor, і як раз збираюся йти з Яндекса, і дуже цікавлюся можливістю попрацювати в домені low latency. У процесі підготовки до конференції ми познайомилися з Володею Долженко, через якого я, зрештою, опинився в Дойче.

— Розкажіть для тих, хто далекий від банківського сектора: в чому специфіка Java-розробки в такому місці, як ТехЦентр Дойче Банку, що відрізняє її від Java-розробки в цілому? Підвищені вимоги до надійності?

— Звичайно, вимоги до надійності у нас вище, ніж в середньому энтерпрайзе, але все-таки ми не шатли тут запускаємо — чогось захмарного немає. Надійність, в основному, забезпечується надмірністю: наприклад, з двох десятків джерел даних, які слухає наш сервер, штук п'ять реально використовуються в кожен конкретний момент — очевидно, найякісніші. Решта просто в обоймі на заміну, якщо раптом якісний джерело замовкне — у нас є менш якісний, але все ж робочий. І така надмірність на багатьох рівнях.

Особливість банківського сектора — те, що він дуже регульований і перевіряється. Тому чимала частина бізнес-вимог полягає в тому, щоб відповідати запитам аудиторів. Наприклад: ми зберігаємо масу інформації про те, що в наших системах відбувається, і зберігаємо її мало не вічно. Наприклад: помітна частина вимог до надійності відбувається не безпосередньо від нашого бізнесу, а виходить спочатку від аудиторів/регуляторів (іноді ці вимоги досить дивно виглядають в контексті конкретного додатка).

— На JPoint 2016 ви розповідали про escape analysis — а чи можете привести з досвіду роботи якої-небудь конкретний приклад того, як його знання допомагало впоратися з конкретної робочої завданням?

— Ні, не можу :) Це досить свіже дослідження, і якогось помітного застосування в моїй роботі йому поки не знайшлося. Наші найкритичніші щодо продуктивності програми були написані ще за часів досить старих версій Java, і там застосовані набагато більш дубові методи оптимізації. А переписувати прямолінійне і надійне на модне і молодіжне тільки тому, що воно модне і молодіжне… Я чекаю нових проектів — можливо, там це знадобиться більше.

— Добре, це дуже свіже — а у випадку з темами на кшталт Java Memory Model, про яку робили доповідь у 2013-му, конкретні випадки «ось тут це допомогло» є?

— Так, ті ж самі weak caches у нас в коді багато де використовуються і допомагають зменшити навантаження на GC. У гарячих місцях у нас є спеціалізовані під конкретний сценарій concurrent map-и або буфера.

Взагалі, знання JMM — це допоміжний навик, основне застосування для нього — це фільтрувати завідомо неправильні рішення. У більшості випадків я шукаю рішення, відповідне по функціональності, дизайну, продуктивності, — а модель пам'яті виступає як фільтр, отбраковывающий ідеї, складно реалізуються в багатопоточних умовах, і навпаки, подсказывающий перевірені багатопотокові патерни.

Таких трюків, як з benign race, зовсім небагато. Большая частина практичного застосування JMM полягає в тому, щоб не робити дурниць і бути простіше.

Олексій Рагозин (system architect)
— Ви досить «хардкорних» спеціаліст. Дойче Банк підходить вам тим, що там багато відповідних завдань?

— За його мірками на «хардкорность» я не тягну. У RTC є команди, які вирішують завдання з розряду ultra low latency, ось там «хардкор». Але Дойче дійсно приваблює мене тим, що дуже часто доводиться вирішувати завдання, які ще не мають «типових» рішень в індустрії. Я б сказав, що якщо вам цікаво займатися певними технологіями (наприклад, in-memory data grid), ТехЦентр Дойче Банку — це чи не єдине місце.

— У вас досить активна публічна діяльність: багато разів виступали на конференціях, ведете англомовний блог. У чому ваша головна мотивація для цього?

— Крім блогу і конференцій, я тривалий час викладав на курсах другої вищої освіти в МДТУ їм. Баумана, а зараз веду два курсу Java-школі нашого технологічного центру.

Але повертаючись до питання, основна мета — це розширення кола спілкування, обмін думками. Виступи і статті в блозі викликають відгук від читачів/слухачів, дуже часто я дізнаюся щось нове.

— Про Java-школу цікаво: а які два курсу?

— Один про профілюванні Java-додатків, інший про складання сміття. Перегукується з двома моїми доповідями на JPoint.

— Часом вважається, що самоосвіти достатньо: мовляв, на StackOverflow вже будь відповідь знайти можна. А навіщо Java-школа — що вона дає, чого в гуглі не отримаєш?

— Школа дає дуже багато. Грубо кажучи, до тих пір, поки людина не розуміє проблему, він не може коректно задати питання. А відповідно, не може знайти відповідь на StackOverflow. Це замкнене коло. Тому багато інженерні завдання вимагають деякої «академічної» бази, перш ніж людина зможе самостійно шукати рішення конкретної проблеми, використовуючи загальнодоступні ресурси. І це справедливо не тільки для вузьких технічних тим зразок тюнінгу JVM, а для дуже різних. Ніякої StackOverflow не навчить правильно використовувати складний фреймворк або проектувати архітектуру програми.




Наостанок — доповіді, які Черемин і Рагозин робили в останні роки на конференціях JUG.ru Group:






Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.