В этой статье рассказываем про распределенные транзакции - зачем они нужны в микросервисной архитектуре и какие у нас есть варианты реализации. Рассказ ориентирован на тех, кто не в теме - кому непонятно, зачем на простую транзакцию накручивать столько сложностей, это ведь удлиняет разработку и увеличивает количество точек отказа. Поясним зачем это нужно, приведем примеры проектов и немного пофилософствуем.
Product Developer
System Design 101
О сложных системах простыми словами.
В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.
Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.
Возможно, немного другой формат шпаргалки покажется вам более удобным.
Хороший ретрай, плохой ретрай, или История одного падения
Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.
Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.
Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.
Выбираем IAM в 2023 или, что есть кроме Keycloak
Гипотетическая ситуация — ваш работодатель поручил вам выбрать Identity and Access Management platform.
Обязательно: open‑source (Apache 2.0), self‑hosted, OAuth 2.0, OIDC, SAML, LDAP.
Для тех кому интересно узнать, что есть еще кроме Keycloak.
Безопасность OAuth2
У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model,
Как я делал внутренний cookbook по тому, как писать код (и результат можно скачать)
Авокадо с зубами подсказывает, что так код легче поддерживать, дописывать и рефакторить. Мы всё теперь пишем только так.
Привет, Хабр! У нас была проблема: каждый писал код как хотел. Было очень тяжело это поддерживать и ревьюить. Мы сначала думали, что достаточно написать стандарт кода. Оказалось, недостаточно, ему ещё надо обучить. Чтобы обучить, мы открыли для ревью эталоны кода, чтобы покрыть ими самую частую логику взаимодействия с компонентами. Тоже не хватило. А заодно я узнал, что мои же «золотые» образцы противоречили моему же стандарту кода (сначала было смешно, а потом пришлось переписывать).
В итоге я сделал кукбук с большим количеством примеров, чтобы объяснить культуру и методологию не через абстракции, а очень предметно. Начал вроде как просто для себя, оказалось полезно — и внедрил в работу команды.
Всё это было нужно для того, чтобы мы все в команде понимали, что такое наш стандарт кода, делали одинаковые вещи примерно одинаково, имели набор готовых шаблонов на системные или платформенные обращения и уменьшили объёмы как самого ревью, так и диалогов после.
Началось с того, что однажды я увидел очередной большой кусок кода, где логика из одного сервиса ушла в другой, а интеграционных тестов было аж 54 штуки. Исправленная опечатка в одном из запросов потребовала трёх часов работы, хотя я заранее знал с точностью до строчки и знака, где именно эта опечатка.
В общем, тот результат, который нас устроил, — это сочетание стандарта, библиотеки шаблонов и книги, как написать приложение. В ней мы делаем демоприложение и через все этапы показываем, почему принималось то или иное решение для реализации кода.
На сегодня ни в одной компании в России я не видел целостного подхода в сборке с кукбуком. Какие-то части встречаются, в сборке — нет. Вот я и хочу рассказать, как мы это сделали у себя в банке.
Посвящается всем, кто коллекционирует элегантные решения без привязки к языку, фрэймворку, Фаундлингам и Software Craftsmanʼам.
Погнали.
Тот самый случай, когда мы за один месяц рожали то, что надо было делать три (не повторяйте, это больно)
Ачивка «Терминатор»: прибить проект, потому что проще заново
У нас есть внутренний продукт для оценки сотрудников. Он сменил три проджекта, три тимлида разработки, двух дизайнеров. Я была третьим проджектом в этой наследной цепочке.
Что пошло не так? Ну, в какой-то момент пришёл бизнес и сказал: чуваки, вот у нас замечательное ТЗ, его нужно сделать. Команда в первом составе собрала аналитику, прикинула список действий, заложила 15% времени на непредвиденное и приступила к разработке.
А в декабре бизнес сказал, что мы должны запуститься через месяц.
Мы катастрофически не успевали, стали выпускать поэтапно и седеть. В этот месяц родилось то, что мы очень вежливо называем MVP. Он был настолько прекрасен, что части бека выполнялись на фронте. Потому что фронтендер помогал, чем мог, и делал математику для обработки данных прямо в формах ввода этих данных.
Первый состав по каким-то личным причинам (возможно, кровью из глаз) не смог взять это на поддержку, сменились тимлид и проджект. Бизнес считал, что проект нормально работает, нормально поддерживается и всё с ним будет хорошо. И начал выкатывать новые запросы на фичи в нон-стоп режиме.
Второй тимлид выгорел и уехал в условный Гондурас.
Всё это время в команде был разработчик, у которого был гениальный план, что бы он сделал, если бы стал тимлидом. В какой-то момент его мечта сбылась. Он стал тимлидом. Тут нам как раз принесли новый блок с жёстким дедлайном в три месяца, надо было сделать новый продукт. На всё это у нас было времени с мая по июль.
Короче, мы посовещались и пристрелили к чертям весь проект.
Мечта была в том, чтобы написать его заново.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность