Разработали сложный микросервис уведомлений для крупной строительной компании.
На картинке — общая архитектура сервиса.
В новой технической статье рассказываем, как так получилось.
—
Хотите запустить новый продукт с нуля или сервис внутри существующей архитектуры? Пишите в личку @samatg! Мы берем новых клиентов.
Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.
Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).
Не буду здесь повторяться; тем более, что Дэвид даже рассказал, как быть, если вы уже поторопились и сделали микросервисы.
—
Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!
По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.
Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)
Похвастаюсь. Делаем с Федей аудит одного крупного финансового сервиса. Сегодня был третий день встреч с техдиром.
Каждый фиолетовый прямоугольник — это довольно большой сервис (отдельный репозиторий), над которым работает своя команда.
На схеме примерно треть, а то и четверть всей системы. Базы по много терабайт, тысячи интеграций — вызывает уважение, да что говорить, восхищение, что всё это работает и приносит пользу и деньги. 😍
Новый эпизод! С техническим директором и тимлидом. Даниил Шевчук и Александр Козлов решают те же технические задачи, что и мы с вами — бьют монолит на сервисы, оптимизируют кеши под нагрузкой, налаживают взаимодействие членов команды и команд между собой.
Но есть большое отличие — они работают в благотворительном фонде. У фонда «Нужна помощь» 8 мощных проектов: от популярного медиа «Такие дела» и акции «Рубль в день», которую рекламирует Иван Ургант, до системы автоматизации отчетности благотворительных фондов, этакой «эльбы для благотворителя».
Откуда у благотворителей деньги на разработку? Сколько они денег собирают и сколько тратят? Как устроено IT в этой сфере? — обо всём этом мы поговорили с самыми крутыми технарями в благотворительности в России. Ну и безумные истории запусков по ночам, конечно же :)
Наслаждайтесь: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
С гордостью представляю новый эпизод подкаста.
В гостях — Тамара Зуйкова, технический директор Манго Страхования. Это стартап, в который альфа-групп вложила миллиард (!) рублей.
Разбираемся в страховании — как защищаются от обмана, как зарабатывают деньги и как всё это программируют. Тамара умеет объяснять сложные штуки исключительно ясно и понятно. ❤️
В эпизоде: управление рисками, микросервисная архитектура, власть и ответственность разработчиков, база данных kafka и многое другое — простым языком.
Слушайте везде: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
Дима Олляк делится в нашем уютном чате хорошим:
«Тем временем на Хабре руководитель разработки российского Леруа Мерлена увлекательно рассказал, как они вдвухсотером пилят российский Леруа с джавой и микросервисами. За неимением апдейтов техблога Медузы вполне годная статья.
Бонустрек — холодной душ от счастливых покупателей в каментах: „Как уже сказали выше, могут эти 200 человек пожалуйста пофиксить поиск?“»
Эти три поста — мини-ода серверу Nginx и его создателю Игорю Сысоеву. Я не написал о покупке компании NGINX американским гигантом F5 за 670 миллионов долларов в феврале (профайл в Ведомостях и в Форбсе), исправляюсь.
Nginx — это скотч веб-разработчика. Вы ведь знаете, что именно с помощью скотча астронавты починили свой автомобиль на луне? С помощью Nginx можно скрепить разные части сайта между собой (микросервисы, ау), ускорить сайт с помощью кеширования (скорость работы Медузы и RAWG), серьезно сэкономить на хостинге и даже защититься от DDoS-атак. Nginx поддерживает и простейшие одностраничные сайты и гигантские корпорации. Это сервер, который вобрал в себя лучшее от таможни, DHL и завода.
Мы с коллегами недавно сделали с помощью nginx две необычные вещи, которыми я хочу поделиться.
Во-первых, перевели один очень старый сайт с http на https (это улучшает позиции в гугле), по пути убрали www из всех адресов и добавили кеширование, так что сайт стал открываться раз в 10 быстрее.
Интересная часть в том, что на сайте было много хардкод-адресов http://www..., и поменять исходный код было решительно невозможно (старый perl), так что мы использовали модуль ngx_http_sub_module, который позволяет переписать содержимое ответа на лету.
Мы не поменяли ни одной строки кода в движке сайта, все изменения — через настройки nginx.
Во-вторых, добавили щепотку динамического контента в кешированные nginx'ом страницы. Под нагрузкой наш django + react сервер отвечает не очень быстро. Для того, чтобы сайт отвечал мгновенно — мы кешируем странички для анонимов, то есть регулярно пересчитываем их, а при запросах мгновенно отдаем последнюю сохраненную версию.
Для проверки одной SEO-гипотезы нам потребовалось добавить несколько случайных ссылок на каждую страницу. Казалось, nginx-кеширование и динамический контент не сочетаются. Но нет, выручил SSI — технология родом из 1993, когда писали статический html-код страниц, а динамику добавляли маааленькими кусочками. Мы добавили в код своих страниц <include>, так что основная страница кешируется как и раньше, а блок со ссылками быстро отдается отдельным быстрым микросервисом.
Да здравствует nginx и инженеры, умеющие с ним управляться!
Segment — очень классный сервис, который собирает данные аналитики и раскидывает по десятку доступных интеграций, которые вы выберете. Этакий мультиплексер аналитических данных.
Они рассказывают, как уткнулись в проблемы производительности, выделили отдельные задачи в микросервисы и стало лучше. В течении года число похожих друг-на-друга микросервисов выросло до 140(!) и начались серьезные проблемы менеджмента зависимостей и деплоя. Тогда они собрали все сервисы обратно в один четкий монолит и опять задышали свободно.
Отличный пример, который показывает, что каждому инструменту (и подходу) — своё время и место. Включайте мозги, не идите на поводу у хайпа.
У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.
Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.
Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.
В случае разделения машины на части мы можем выбрать разных производителей отдельных частей, достаточно, чтобы все они соблюдали стандарты и поэтому могли работать вместе.
Короткая (14 страниц A4) и познавательная статья про безопасность в гугле: https://cloud.google.com/security/security-design/
Проходится «по верхам» обеспечения безопасности такого монстра, как Google.
Мне было особенно интересно про аутентификацию/авторизацию на уровне общения сервисов друг с другом (внутри есть больше подробностей про это):
Each service that runs on the infrastructure has an associated service account identity. A service is provided cryptographic credentials that it can use to prove its identity when making or receiving remote procedure calls (RPCs) to other services. These identities are used by clients to ensure that they are talking to the correct intended server, and by servers to limit access to methods and data to particular clients.