Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.
1. Основные уровни сетевой архитектуры: DMZ, APP, DB;
2. Правила межсервисного взаимодействия.
User
Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.
1. Основные уровни сетевой архитектуры: DMZ, APP, DB;
2. Правила межсервисного взаимодействия.
Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.
В серии статей я попытаюсь осветить неочевидные нюансы при работе с Redis и сегодня начну с основных концепций и понятий. А еще в конце статьи приведу небольшой чек-лист, который может помочь вам в оптимизации этого NoSQL решения.
Статья была написана мной в 2020 году, после запуска в прод очередной платформы, построенной на микросервисной архитектуре с целью зафиксировать выученные уроки с точки зрения технического руководителя проекта. В проектах участвовало со стороны подрядчика более 300 человек технических специалистов - разработчиков, тестировщиков, аналитиков и др. Поэтому можно сказать, что проекты были достаточно крупными и значимыми.. Теперь уже многие компании - участники проекта либо свернули бизнес в РФ, либо поменяли бренд, а разработанные системы находятся в эксплуатации. Микросервисная архитектура давно не является новой архитектурной парадигмой. Но я думаю, что статья все еще актуальна, как и многие выученные уроки .
❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?
Что такое отказоустойчивость и стабильность?
Под отказоустойчивостью будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:
1. Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.
2. Стабильность системы предполагает самостоятельного восстановления работоспособности после сбоя как компонентов системы, так и всей системы в целом. К примеру, если пропадала сеть на некоторое время — то у стабильных систем после восстановления подключения все компоненты продолжат работать и данные вернутся в консистентное состояние без ручного вмешательства со стороны команды эксплуатации.
Ранее я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.
Сегодня я покажу, как запустить уже целый кластер PostgreSQL в Docker, а также в тестах через Testcontainers, и как вручную инициировать смену мастер-хоста.
Настройка Аудирования и Журналирования в java проекте.
Hibernate Envers не так прост как кажется, но мы всё настроим и кастомизируем.
Всем привет! Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей.
Сегодня хотелось бы поговорить про такую не очень популярную историю, как измерение показателей команды разработки. За рамками статьи хочу оставить, почему необходимо измерять что-либо в работе команды — это тема для отдельного рассказа. Также тут вы не найдёте готовых рецептов для построения бордов в Grafana, но зато получите всё необходимое, чтобы начать их делать самостоятельно. Цель статьи — поделиться, как с минимумом инструментов измерять интересующие тимлида показатели.
Под катом несколько кейсов. Они актуальны для конкретной команды с ее укладом, поэтому прежде всего погружу вас в наши процессы. Но при этом прошу помнить, что статья — не агитация за определённый процесс работы, а описание способа построения дашбордов на примере отдельно взятой команды. Вы вправе сами решить, делать ли вам Code Review, логировать ли время, оценивать с помощью идеальных часов или стори поинтов, использовать ли сабтаски или связанные таски, как связывать баги с задачами и каким образом разделять задачи по эпикам. И я надеюсь, что после прочтения статьи вы сможете создать актуальный для вас борд.
Задавайте вопросы под постом, друзья, и я постараюсь ответить на ваши комментарии (по делу).
Предисловие
Мы разберем, как завести счета в Казахстане и сделать рабочие карточки Visa и Mastercard в различных банках. Вы узнаете, зачем я поехал в соседнюю страну, к чему это привело, как по приезде взаимодействовать с финансовой системой наиболее быстро и эффективно, и что для этого требуется.
Также прошу иметь в виду, что я использую понятие «западный банк» в контексте того, что банк НЕ российский.
Зачем?
Итак, давайте разберемся, для чего нужны карты казахстанских банков. Очевидно, что Россия оказалась под жесткими финансовыми санкциями, и сейчас нашими Mastercard и Visa невозможно оплатить никакие услуги западных сервисов
Небольшой обзор стандартных средств запуска бэкграунд-задач в аспнет приложениях — что есть, чем отличается, как пользоваться. Встроенный механизм запуска таких задач строится вокруг интерфейса IHostedService и метода-расширения для IServiceCollection — AddHostedService. Но есть несколько способов реализовать фоновые задачи через этот механизм (и ещё несколько неочевидных моментов поведения этого механизма).
Одни из важнейших характеристик качественного IT-продукта — отказоустойчивость и работоспособность под нагрузками. Когда речь идёт о пользовательских финансовых операциях, это важно вдвойне, а если к уравнению добавить хайлоад — втройне.
Я разрабатываю сервисы в команде платежей Ozon. Мы много времени уделяем тому, чтобы все транзакции были обработаны корректно, даже если речь идёт о нагрузке в 2к платежей в минуту (именно столько у нас было в пике в период ноябрьских распродаж). Кстати, сейчас, по результатам нагрузочного тестирования, мы выдерживаем 13к платежей в минуту.
Для этого мы готовимся заранее: пересматриваем архитектуру, дорабатываем сервисы, рефакторим код, кэшируем и оптимизируем базы данных. Серебряной пули тут нет, но могу поделиться техниками, которые помогли нам избежать возможных проблем, — будет полезно всем, кто готовит свои сервисы с прицелом на работоспособность под нагрузками.
Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.
Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.
В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.
Делимся подробностями, как мы сделали хороший поиск по закрытой корпоративной соцсети в условиях, когда:
• данные хранятся в разных колонках таблиц MSSQL,
• раньше поиска по ним не было,
• а перенести их оттуда дорого — вся система завязана на MSSQL. Использовать сторонние сервисы не получится по соображениям информационной безопасности.
Критерий хорошего поиска для нас звучит так: даже если пользователь ввел запрос с опечаткой или неточно указал название группы, то всё равно нашёл её.
Также на перспективу нам нужно было продумать поиск по хэштегам как по раздельным словам, поиск по синонимам, ранжирование результатов и выдачу промежуточных результатов на лету.
В своей жизни я много раз встречал ярких способных личностей, которые тащили на себе огромный кусок работы, демонстрируя невероятные для специалистов их профиля результаты, а клиенты стояли к ним в очередь.
Замечательные продажники, уникальные программисты, аналитики, администраторы… В любой отрасли вы можете встретить Звезду. Начальники на них молятся, сдувают пылинки, коллеги восхищаются или люто завидуют. Такие специалисты имеют хорошие зарплаты и личные преференции. Их руководители открывают бутылку дорогого коньяка, когда под их началом появляется такой высококлассный сотрудник!
«Здорово!», скажете вы, и я с вами согласен. Однако всегда надо помнить, что уникальный специалист, это не только Подарок, но и Бомба замедленного действия.
Почему, «бомба»? Про это я и расскажу в этой заметке.
Данную статью пишу для думающих, стоит оно того или нет и начинающих построение своего умного дома, надеюсь она поможет сделать вам свой выбор. Для тех кто думает я не программист у меня ничего не получится, я тоже, хотя имею техническое (теплоэнергетик) образование, но никогда не работал в IT, не знаю не одного языка программирования. Дорогу осилит идущий. Начнем с рассуждений что такое умный дом, поверьте на слово он не решит все ваших бытовых и семейных проблем, но точно сделает жизнь немного комфортней. Что такое умный дом в моем представлении год назад: 1. Красивый планшет со схемой дома весящий на стане в прихожей с которого можно управлять всем в доме; 2. Управление всем чем можно голосом. Откровение через год планшет не нужен, так как бегать со второго этажа на первый что бы по управлять неудобно. Что бы хорошо работало голосовое управление, требуется установка умной колонки в каждую комнату, когда их две это одно. А когда значительно больше вопрос. Сейчас для меня умный дом это то, что работает само без моего участия, и не требует управления. Все о чем пойдет речь далее сделано мною лично, может можно сделать по другому, может проще и лучше. Но таков путь.
На одном из моих поддерживаемых проектов недавно встала задача проанализировать возможность миграции с .NET фреймворка 4.5 на .Net Core по случаю необходимости рефакторинга и разгребания большого количества накопившегося технического долга. Выбор пал на целевую платформу .NET Core 3.0, так как, судя по утверждению разработчиков от Microsoft, с появлением релиза версии 3.0, необходимые шаги при миграции legacy кода уменьшатся в несколько раз. Особенно нас в нем привлекли планы выхода EntityFramework 6.3 для .Net Core т.е. большую часть кода, основанную на EF 6.2, можно будет оставить «как есть» в мигрированном проекте на net core.
С уровнем данных, вроде, стало понятно, однако, еще одной большой частью по переносу кода остался уровень безопасности, который, к сожалению, после беглых выводов аудита придется почти полностью выкинуть и переписать с нуля. Благо, на проекте уже использовалась часть ASP NET Identity, в виде хранения пользователей и других приделанных сбоку «велосипедов».
Тут возникает логичный вопрос: если в security часть придется вносить много изменений, почему бы сразу же не внедрить подходы, рекомендуемые в виде промышленных стандартов, а именно: подвести приложение под использование Open Id connect и OAuth посредством фреймворка IdentityServer4.
Information