Web
Привет, меня зовут Владимир Иванов, и я архитектор ПО в компании EPAM. В своей работе мне постоянно приходится документировать программные решения, которые предстоит создать. Я решил поделиться некоторыми аспектами этой деятельности с вами, ведь вам тоже это может пригодиться.
Как вы рисуете диаграммы для вашего ПО? На какие вопросы они должны ответить? Зачем рисовать что-либо вообще? Давайте разберёмся.
Казалось бы, упаковать PHP в контейнер и настроить GitHub Actions - дело пяти минут. Но как часто бывает, реальность оказалась сложнее. Это история о том, как я вернулся к разработке на PHP и решал накопившиеся проблемы с деплоем Laravel-проекта. О том, как готовил Docker-образ, несколько раз переписывал процесс деплоя, находил компромиссы там, где это было возможно, и полностью перестраивал архитектуру там, где компромиссы были неприемлемы.
На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.
В рамках предыдущих статей мы выделили область применения подхода и рассмотрели основные методологические принципы Domain Driven Design.
В данной статье я хотел бы обозначить основные современные подходы к построению архитектуры корпоративных систем: Supple, Screaming, Clean и дать им свою четкую интерпретацию в виде полноценного готового решения.
В дальнейшем рассмотрим каждый шаблон проектирования подробно: обозначим область применения, приведем примеры кода, выделим рекомендуемые практики. В итоге, напишем готовый микросервис.
Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.
В этой статье я постараюсь восполнить нехватку постепенного введения в современную сетевую балансировку и проксирование. По правде сказать, это объёмная тема, достойная целой книги. И чтобы статья не получилась безразмерной, я постарался ряд сложных задач подать в виде простого обзора.
За время работы с объектными хранилищами я встречал немало «подводных рифов» на пути к быстрому и эффективному хранению.
В этой статье я покажу, где чаще всего проседает производительность при работе с S3-совместимым хранилищем, — на примерах из реальных кейсов технической поддержки.
Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg - в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров – Go.
У нас не подгорит!
Как PostgreSQL хранит большие значения столбцов? Какие явные и неявные ограничения есть у существующего механизма хранения? Что за проблемы вызваны этими ограничениями? И как можно решить эти проблемы, и расширить возможности PostgreSQL? Об этом, и чуть больше - данная статья.
Приветствую, хабровчане. В далёком 1998-м я поступил в вуз на инженера-программиста и ещё в первом семестре реализовал свой первый коммерческий программный проект. Нет, это не курсовая для сокурсников, как вы могли бы подумать. Это была простенькая система складского учета для знакомых коммерсантов (работает, кстати, и поныне). Забавно, но она и стала тем триггером, который через пару лет надолго привел меня в коммерческую продуктовую разработку сперва на позицию разработчика, потом тимлида, аналитика…
В минувшие годы десятилетия довелось заниматься и решениями, которые создают люди, и людьми, которые создают решения, а с недавних пор и сам тружусь архитектором решений. Казалось бы, карьерный сдвиг очевиден. Даже более того – кардинально изменились масштаб, сложность, инструменты, возможности... Но что примечательно, фактически я до сих пор остаюсь на стыке бизнеса и работающих программных систем. Так чем же в действительности занимаются архитекторы решений, и не вымрут ли они, прежде чем очередной первокурсник защитит свой диплом? Давайте разбираться.
В предыдущих статьях мы рассмотрели архитектуру решения Apache Kafka, развернули продукт и разобрались с отправкой и получением сообщений. Можно было бы, конечно, дальше погрузиться в тему использования данного решения, но в Интернете есть множество различных публикаций с примерами использования Kafka для различных задач и различных сред разработки. Поэтому данная статья будет целиком и полностью посвящена такой важной теме, как обеспечение безопасности Apache Kafka.
По своему предназначению Kafka является посредником между различными системами при их обмене сообщениями. Для этого, как мы помним, есть топики и разделы. Но проблема заключается в том, что при стандартной настройке Kafka по умолчанию, любой пользователь или приложение может писать любые сообщения в любой топик, а также считывать данные из любых топиков. Естественно, для сколько-нибудь промышленного применения системы такой подход недопустим. Например, в случае, когда несколько приложений используют один и тот же кластер Kafka, или когда кластер используется в качестве облачного сервиса для сторонних приложений, ну и естественно, когда в Kafka начинает обрабатываться конфиденциальная информация.
В статье мы будем говорить о встроенных в Kafka механизмах защиты и не будем касаться использования каких-либо наложенных средств.
Привет! Меня зовут Иван Гаас, я руковожу автоматизацией процессов разработки в Почтатехе — компании, создающей цифровые продукты для Почты России.
Среднее количество сообщений, которые мы обрабатываем в Почте — от 500 тысяч до миллиона в секунду. В пики, когда наша big data прогоняет свои 25 петабайт данных — до 3 миллионов. При этом кластер Kafka состоит всего из 12 серверов в каждом из 3 дата-центров и справляется с этим.
C 2016 года мы в три раза увеличили количество новых цифровых сервисов. Корпоративная шина на Kafka помогла быстро масштабироваться: количество интеграций за последнее время упало с 1000 до 300 и теперь растёт незначительно. Если раньше интеграция сервиса растягивалась на месяцы, то теперь достаточно нескольких дней.
Я расскажу, как мы построили шину, которая обеспечивает такую производительность.
HTTP/2 – это значительное обновление по сравнению с HTTP/1.1, решающее его ключевые ограничения, такие как блокировка Head-of-Line (HoL) и неэффективность многократных соединений. В этой статье мы разберёмся, почему HTTP/2 стал стандартом, как он устроен и чем отличается от предыдущей версии протокола. Мы рассмотрим ключевые концепции HTTP/2: мультиплексирование, сжатие заголовков HPACK, бинарный формат фреймов и серверный push.
Во второй части статьи мы покажем, как включить HTTP/2 в Go-приложениях. Вы узнаете, как правильно настроить HTTP-сервер с поддержкой TLS и ALPN, какие пакеты использовать и какие нюансы учитывать при разработке. Также мы обсудим практические аспекты работы с HTTP/2, возможные проблемы и пути их решения.
Базовые distroless-образы GoogleContainerTools часто упоминаются как один из способов создания (более) маленьких, (более) быстрых и (более) безопасных контейнеров. Но что на самом деле они собой представляют? Зачем они нужны? В чем разница между контейнером, созданным на distroless-базе, и контейнером, созданным с нуля? Давайте разберёмся.
Привет, Хабр! Меня зовут Артем Безруков, я DevOps‑инженер в команде интеграционных сервисов Platform V Synapse в СберТехе.
Наша команда работает над продуктом из линейки Platform V Synapse — Platform V Synapse Messaging. Это брокер сообщений, в основе которого лежит Apache ActiveMQ Artemis. Мы делаем из него более безопасное и функционально обогащённое решение, разрабатывая дополнительные плагины, и заботимся о том, чтобы его можно было просто и быстро развернуть с помощью наших скриптов автоматизации.
В последние годы набирает обороты тренд на использование облачных технологий, технологий контейнеризации и микросервисной архитектуры, и наша команда решила расширить возможности продукта. И если изначально стенды ограничивались только виртуальными машинами (ВМ), то с недавнего времени мы начали выводить Platform V Synapse Messaging в среды оркестрации контейнеров — Kubernetes (K8s/облако).
В этой статье расскажем о нашем пути: почему выбирали то или иное решение, с какими трудностями столкнулись и к чему это нас привело. Мы считаем, что наш опыт будет полезен инженерам, которые прорабатывают механизмы переноса приложений в облако, развёртывают данные приложений и автоматизируют связанные с этим процессов.
Поехали!
ReplicaSet — но это ручной процесс. Команда Kubernetes aaS от Mail.ru реализовала в своем сервисе автоматическое машстабирование на уровне кластеров. Ну а если вы хотите оптимизироваться на уровне подов — то следуйте рекомендациям этого перевода.ReplicaSet) декларативным образом с использованием спецификации Horizontal Pod Autoscaler. По умолчанию критерий для автоматического масштабирования — метрики использования CPU (метрики ресурсов), но можно интегрировать пользовательские метрики и метрики, предоставляемые извне.
Это третья статья из цикла. В прошлой части мы разбирали типы метрик, и уже там начали встречаться перцентили. Это полезная штука, но для неподготовленного читателя она выглядит просто как математическая дичь. Эта статья поможет разобраться в перцентилях по-инженерному, не заканчивая профильный факультет.
В современном информационном обществе данные играют ключевую роль в принятии решений и развитии различных отраслей. Однако для того, чтобы данные были максимально полезными и доступными, необходимо создание эффективных инструментов и платформ для их хранения, анализа и предоставления.
В статье Центр цифровой трансформации Республики Татарстан рассказывает о создании региональных витрин данных – мощных инструментов, которые способствуют управлению информацией на уровне региона, открывая новые возможности и решая существующие проблемы.