Программист
Привет, друзья! Продолжаю делиться с вами заметками о Docker.
Заметки состоят из 4 частей: 2 теоретических и 2 практических. Если быть более конкретным:
Docker, Docker CLI и Dockerfile;Docker Compose.В этой части мы разработаем простое приложение, состоящее из трех сервисов и базы данных, а в заключительной — "контейнеризуем" его.
Репозиторий с кодом приложения.
Если вам это интересно, прошу под кат.
Всем привет. Меня зовут Михаил, я - фронтенд-разработчик в Лиге Цифровой Экономики.
В последнее время я пробую себя в должности руководителя направления фронтенд-разработки, однако я хочу с вами поделиться опытом разработки приложения с применением Webpack Module Federation, о том, какие задачи приходилось решать и проблемы, которые возникли на этом пути. Не буду вдаваться в теорию о микрофронтах и module federation, об этом уже много написано и предполагается, что вы знакомы с базовой настройкой. Мы же поговорим о самом «вкусном», некоторые моменты будут опущены в целях сосредоточения на деталях.
Меня зовут Семен Катаев, я работаю в Авито над процессом перехода от монолитной архитектуры к микросервисам. Переход у нас все еще продолжается, но мне уже есть чем с вами поделиться. Это краткий обзор того, с чем придётся столкнуться, если вы задумались над созданием надежного, масштабируемого, распределённого приложения.
Нам пришлось поменять практически все процессы разработки, провести реорганизацию в компании, освоить новые для нас паттерны проектирования и начать использовать незнакомые инструменты для перехода к микросервисной архитектуре. Об инструментах сегодня и пойдёт речь.
Очень часто при проектировании высоконагруженных систем, основанных на микросервисной архитектуре, обнаруживается что «узким» местом, ограничивающим производительность системы и возможности ее масштабирования, становится передача сообщений и временные затраты на сериализацию-десериализацию сообщений и дополнительные расходы на установку соединения и начальные согласования. Решением может стать использование протокола gRPC с кодированием сообщений с применением Protocol Buffers (protobuf).
В этой статье рассмотрены подходы к реализации gRPC клиента и сервера для бэкэнда на Kotlin, разобран пример создания проекта для взаимодействия микросервисов через протокол gRPC с использованием возможностей Kotlin DSL и корутин.
Эксперименты с созданием редактора диаграмм на Blazor Webassembly (Blazor WebAssembly: Drag and Drop в SVG, Blazor WebAssembly: соединительные линии в SVG) показали что технология не годится для интенсивных манипуляций с DOM.
То что будут проседания было известно заранее: WebAssembly не имеет доступа к DOM, любые изменения только через вызовы JavaScript. Задержки оказались такими большими, что перетаскивание на мобильном тормозило уже после добавления третьей фигуры.
Массовый переход от монолитов к микросервисам решает ряд проблем:
• раздельный деплой и рефакторинг;
• удобное масштабирование частей системы;
• прозрачное разграничение ответственности команд;
• снижение бласт-радиуса;
• снижение когнитивной нагрузки на разработчика.
При этом создает другие проблемы: взаимодействие сервисов существенно сложнее и дороже, чем взаимодействие объектов в памяти. Частично упростить его можно с помощью протокола gRPC.
gRPC дает возможность зафиксировать в репозитории контракты межсервисных вызовов, строгую типизацию, стриминг, кросс-платформенную кодогенерацию и множество других полезных для межсервисного общения вещей.
Из этой статьи вы узнаете, когда стоит применять gRPC, а когда лучше воздержаться, как решаются типичные задачи, включая конфигурирование, отладку, healthcheck, а также то, о чем умалчивает документация.
По материалам выступления на конференции DotNext.
Эта статья - простая и подробная инструкция, как можно в домашних условиях покрыть латунью металлические детали, применяя только подручную химию. cut/ В ней, подробно описанны все ньюансы и "подводные камни". После прочтения этой статьи, у вас просто не может не получиться делать такие же превращения деталей, как на картинке.
В этой статье мы узнаем что такое камера в 3D пространстве (матрица вида) и как она работает, узнаем как сделать те объекты что дальше - меньшего размера (матрица перспективной проекции).
Мы продолжим работу над кодом, который у нас получился в финале 2-й части. И начнем с обсуждения камеры в пространстве (м.б. в 3D игре).
Снова привет, Хабр!
В первой части статьи мы разбирали, что такое изоляция микросервисов, как в этом помогают переключатели функциональности, и как создать простое ASP.NET приложение в с поддержкой feature toggles, которое будет показывать прогноз погоды. В этой части закончим работу над ним — напишем заглушку, сделаем экспериментальную конечную точку, функциональность которой можно включать или выключать, не останавливая работу приложения, и разберёмся с экстренными ситуациями, которые могут возникнуть при разработке приложения.
Дисклеймер: в статье много тяжёлых иллюстраций, берегите мобильный интернет.
Привет, друзья!
Продолжаю делиться с вами заметками о Docker.
Заметки состоят из 4 частей: 2 теоретических и 2 практических.
Если быть более конкретным:
Docker, Docker CLI и Dockerfile;Docker Compose;Пришел к выводу, что в первой части я был излишне многословен, поэтому в этой части буду более лаконичным.
Часто бывает так, что эффективная коммуникация – один из основных движущих факторов в современных программных системах, даже в мире, живущем по законам микросервисной архитектуры. Технология gRPC может справляться с этими требованиями. В этой статье будут рассмотрены некоторые основы gRPC, а еще мы реализуем первое клиент-серверное приложение с применением .NET. Кроме того, клиент на основе Python демонстрирует, насколько эффективной может быть коммуникация между различными сервисами.
Удивительно, сколько полезностей можно узнать за один хабрамитап Хабр ПРО. Например, какая судьба ждёт монолит при переходе на микросервисы и кто отвечает за общий код между двумя микросервисами.
Эти и другие вопросы обсуждались 25 ноября в выпуске «Хабрамитап про микросервисы: отвечаем на вопросы с Хабр Q&A». Вебкаст посетил наш сотрудник — руководитель направления автоматизации в Россельхозбанке (РСХБ) Денис Рылеев.
На протяжении эфира Денис отвечал на вопросы о микросервисах, которые задавал ведущий хабрамитапа Андрей Аврамчук, подобравший самые интересные топики от зрителей вебкаста и пользователей бывшего Тостера — нынешнего Хабр Q&A. Кроме Дениса выступал ещё один эксперт — системный инженер компании EPAM Михаил Чугунов.
Из этой статьи даже начинающий разработчик поймёт, что такое микросервисы и в каких ситуациях они применяются. Денис и Михаил постарались ответить на все вопросы максимально доступным языком. Мы выделили несколько категорий вопросов:
Заранее обрадуем жаждущих именно услышать специалистов: каждый вопрос сопровождается ссылкой с вшитым тайм-кодом, так что долго искать ответы в записи вебкаста не придётся.
Хороший вопрос требует хорошего ответа. Приступим.
Сталкивались ли вы с задачей построить Enterprise-grade-приложение из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза?
Мы хотим поделиться опытом, как решили эту задачу в Netcracker. Как в этом помогла концепция Service Mesh и идея применить «микросервисную модель» и к структуре Service Mesh. Мы реализовали Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.
Сама статья основана на расшифровке выступления на SaintHighload 2021 в Питере Алексея Ефимова, системного архитектора Netcracker и руководителя отдела Cloud Core. Ссылка на запись — в конце статьи.
Всем привет, меня зовут Катя, я QA Engineering Manager в inDriver. В этой статье расскажу про свой опыт использования Proxyman, а также о том, почему считаю его лучшей программой-сниффером. Приятного чтения!
Пост про то, почему стоит, как минимум избегать квадратичной сложности в тех местах, где на это нет никаких причин. Если вы широко используете .concat в .reduce эта статья для вас. В ней я попытаюсь разобрать на пальцах почему это может быть очень плохим решением, и как это исправить.
Радиолюбители часто пытаются с той или иной степенью успешности использовать в своих конструкциях полупроводниковые лазерные излучатели видимого и ИК спектра. Лазерный диод внешне кажется довольно простым полупроводниковым прибором. Ему не нужно ни высоких напряжений, ни колоссальных токов. Он на первый взгляд похож на светодиод: пропустил через него ток -- получил на выходе излучение. Тем не менее, в использовании полупроводниковых лазеров кроется некоторое количество подводных камней, игнорирование которых ведет прежде всего к снижению их надежности, к быстрой деградации выходной мощности и качества пучка, а нередко и к мгновенному выходу из строя еще до первого включения. В этой статье я хотел бы обратить на эти подводные камни внимание.