Ответы пользователя по тегу Проектирование программного обеспечения
  • Как разделять относительно одинаковые скрипты между клиентами?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Скрипты выросли. И у них появилась общая часть (shared). Которая не меняется. И вариативная часть которую
    можно спокойно менять под каждого клиента
    . Как выделить общее и частное - это великая тайна.
    И понять ее можно только с опытом.

    Я-бы предложил следующую стратегию. В общее (shared) должны зайти интерфейсы и абстрактные классы
    или какие-то сущности которые почти никогда не меняются. В вариативные части (client1, client2 ...)
    зайдут реализации или то что просто сильно меняется.

    Преимущества данного подхода - будет меньше кода в перспективе. Но есть и недостаток.
    Некоторые клиенты могут почувстовать странное (немотивированное) изменение версии
    в (shared) части которое они не заказывали. Впрочем это может быть редко или вообще никогда.
    Ответ написан
    Комментировать
  • Как ослуществляется выборка данный в модульной или микросервисной архитектуре?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Т.к. мы не можем сделать выборку всех заказов в статусе X, т.к. их очень много, но мы и не можем сделать выборку с лимитом т.к. не знаем точно, что данные заказы будут оплачены платёжной системой Y и наоборот, если будем строить выборку от оплат. В общем получается, что мы решаем вопросы, которые легко решены в БД, но мы их пытаемся решить в коде. Как поступать то?

    Это типичная проблема которая возникает после распила монолита на части. Если раньше
    монолит ходил в базу и делал любые SQL, то после разделения отвественностей уже такие
    игры не работают.

    Вы говорите что не знаете точно какие заказы оплачены. Вам нужно создать новый метод
    который в правильном сервисе выдает только оплаченные заказы. А в базу ходить не надо.
    Она вообще может быть недоступная по инфо-безопасности для прочих модулей.

    Вот и есть правильная микросвервисная архитектура.
    Ответ написан
    Комментировать
  • Возможно ли создать такую программу, которая позволила бы просматривать торент файлы в которых содержаться видео и фото, или пдф файлы, или html?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Есть утилита torrent-cli. Кажется у нее были опции для просмотра.
    Еще в гитхабе есть проекты похожие по смыслу
    https://github.com/casey/intermodal
    https://github.com/elektito/ih2torrent
    Они позволяют видеть каталог файлов.

    Непонятно зачем ты пишешь про tbpw. Если ты хочешь видеть контент самих файлов - у тебя только
    один вариант - качать торрент.
    Ответ написан
    Комментировать
  • Как следует разбить микросервисы?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Ну слушай. В микросервисах нет математической формулы правильности архитектуры. Все итеративно.

    Ты пишешь.
    Запросы от каждого микросервиса к Auth service будут замедлять систему

    Ну тогда не спрашивай часто. Спрашивай редко. Или введи какое-то кеширование. Вот токены для этого
    дела и создавались. Обновить токен раз в сутки - это нагрузка никакая. Можно с этим жить.

    И вообще микросервисы тоже с нуля начисто никто не пишет. Это процесс итеративный. Опытным путем
    так сказать.
    Ответ написан
    Комментировать
  • Что лучше выбрать для взаимодействия в микросервисной архитектуре? MessageBroker или REST?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Современные брокеры такие как Kafka не имеют одной точки отказа. Можешь их рассмотреть вместо кролика.

    REST является синхронным по своему дизайну. Тоесть ты вызываешь rest метод и ждешь ответа именно на этот
    вызов в отличие от MQ где ты просто шлешь уведомления и тебе безразличен отклик. Поэтому MQ обычно
    быстрее и дешевле когда у тебя идут тысячи и миллионы месседжей в секунду.

    В REST можно делать пакетные (batch) методы. Это ускоряет обработку при массовом обслуживании
    но и коды ошибок будут тоже возвращаться в виде batch ошибок и их надо соотв также пачкой и обработать
    а это все усложняет бизнес-логику.
    Ответ написан
  • Как лучше учиться архитектуре?

    mayton2019
    @mayton2019
    Bigdata Engineer
    По книжкам - не особо эффективно. Личный опыт и "насмотренность" взгляда здесь будут лучше учителя.
    Работая на себя или делая фриланс, архитектура не имеет особого смысла. Архитектура обычно появляется
    где есть какой-то конфликт. Например конфликт денег. Или людей. Или ресурсов. Или есть варианты как разрабатывать.
    Если ты писал сплошняком (стеной) код и это работало то это и есть твоя архитектура. И тебе другое не надо.

    Можешь почитать Макконнелла - Совершенный код. Но его лучше читать как-бы закрепляя то что
    ты сам уже понял.

    Есть шуточная статья на хабре где Java разработчик пишет расчет факториала по всем правилам шаблонов.
    Это как-бы пример оверинжинеринга или того как не надо делать. И понять где архитектурное решение было нужно
    а где не нужно - это как раз и есть опыт архитектора.

    Если тебе интересна оценка твоего кода со стороны - то закжи себе code-review и просто послушай что
    другие teammates говорят о твоем коде. Будет больная и неприятная правда. Это все - тоже части архитектур.
    Ответ написан
    5 комментариев
  • Как правильно выбрать фреймворк и яп для проекта, если ты заказчик?

    mayton2019
    @mayton2019
    Bigdata Engineer
    https://github.com/SteamRE/SteamKit

    Ну ты автор чудак еще тот. Go зачем-то сюда затащил...

    Дан дотнетовский фреймворк. И ищи бригаду дот-нетчиков.
    Ответ написан
    Комментировать
  • Подскажете по архитектуре системы уведомлений?

    mayton2019
    @mayton2019
    Bigdata Engineer
    При данной схеме тебе база и крон вообще не нужны. Пиши сразу в Rabbit. Если consumer обладает логикой неуспеха обработки - то пускай кидает необработанное вообщение в специальную мусорку (Dead-Letter-Quee) для анализа ошибок впоследствии.

    Какой возможен программный потолок количества отправляемых уведомлений в единицу времени, при такой архитектуре на одном сервере?

    На этот вопрос невозможно ответить. Цифры могут отличаться в разы в зависимости от выбранного железа. Но современные MQ настолько быстрые что с большей вероятностью твой софт не сможет их загрузить событями.
    Узким местом в такой системе будет скорее всего твой софт.
    Ответ написан
    2 комментария
  • Как лучше организовать очередь сообщений для их разбора по графику?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Я-бы разобрался с дублями. Если есть система которая продуцирует их - то наверное можно
    как-то решить этот вопрос на уровне источника. Это performance issue который нужно обусждать.

    Можно строить всякие архитектуры на базе очередей или идемпотентных баз но при этом главная
    причина (сетевой траф) будет непофикшена а по сути спрятана под ковер.
    Ответ написан
    4 комментария
  • Хорошая ли стратегия разбивать монолит джанго на микросервисы джанго?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
    Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
    или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
    проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
    Конвей про это писал еще.

    И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
    тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
    того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
    перформанса
    . Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
    накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
    на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

    И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
    И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

    Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
    нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

    Но имеет смысл сделать модуляризацию монолита. Например что там...
    application
    - sales
    - hiring
    - userprofiles

    Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
    контроль за изменениями.
    Ответ написан
    6 комментариев
  • Где хранить список topic и queue для rabbitmq в микросервисах?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Про что данный вопрос? Про разработку или проектирование? Я могу сказать что при разарботке 100%
    нужного материала лежит в исходном коде. В git. Документация может быть или может не быть но код это - golden
    source. Код - это источник правды. Во всех спорных случаях лезут в код и сравнивают. И в концепии современного Scrum/Agile код идет впереди. Бизнес говорит
    что delivery процесс важнее документирования. Сначала релизиться фича а потом вдогонку добиваются
    wiki, confluence, autodocs. А после того как концепции IAS не только код но и инфраструктура тоже переехала
    из с настенных плакатов и Word документов в нормальные себе *.yaml файлики. Для случая автора цена
    вопроса - просто создать такой файлик и со всеми договориться что вот топики будут лежать здесь. Дальше
    этот файлик можно брать как Properties, процессить делать кодогенерацию и прочее.

    При проектировании что делать? Я не знаю. Ну создайте самый главный документ типа спецификации
    где будет просто таблица с перечислением всех точных названий ресурсов. Но опираясь на свой опыт
    я все таки думаю что это не проектирование а это ближе к реализации. К коду короче. Вообще в архитектурном
    документе может даже и не быть имен топиков. Там будет что-то эферемное. Конкретика появиться
    как раз в IAS скриптах и в коде приложения.
    Ответ написан
    Комментировать
  • Как лучше сделать архитектуру сервиса с Cassandra?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Объем данных - терабайт в день. 90 МБ/с траффика в пике.
    Скорость ответа сервисов и мгновенная запись не важна, важно записать данные.


    Между первым и вторым сервисом можно поставить Kafka. Это позволит смягчить ситуацию частичной
    недоступности пишущего сервиса. Я здесь далее по топику предполагаю что Kafka и Cassandra - это облачные
    решения
    которые в приципе не падают. А если и падают то очень редко и по крайне жестким авариям датацентров.

    В этом случае в качестве точек сбоя можно просто рассматривать два ваших микросервиса.

    Еще вариант. Вообще убрать пишущий микро-сервис. Я не знаю как в кассандре. Но в bigdata есть огромное
    число т.н. коннекторов. Это что-то типа драйвера который позволяет писать стриминг в базы и наоборот.
    Например есть коннектор который пишет сразу из Kafka в таблицы Databricks. Скорее всего для кассандры
    тоже есть нечто подобное. Мне кажется с коннектором архитектурно получается проще.
    Ответ написан
    2 комментария
  • Как лучше\проще реализовать работу с серийными номерами\лицензиями чтобы не особо пиратили?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Можно изготовить такой USB-брелок который содержит важный функционал. Без которого приложение - бесполезно.
    Типа аппаратное решение задачи в железе. Тогда получается что вы продаете софт + аппаратуру установка которой очень легкая. Но при этом пиратить и копировать такое решение невозможно.
    Ответ написан
    Комментировать
  • В чем минусы событийно ориентированного подхода?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Не претендую на правду. Просто несколько мыслей.

    В чем минусы событийно ориентированного подхода?
    Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
    По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.

    Мысль первая. Наследие.

    Когда мы говорим о наследии Алана Кея - надо просто глянуть что он создал практически.
    А создал он язык Smalltalk. Поэтому логично изучать минусы событийного подхода на
    примере софта который написан с использованием Smalltalk. Кто из коллег в топике
    знает примеры такого софта? Я - к сожалению не знаю.

    По ссылкам википедии https://en.wikipedia.org/wiki/Smalltalk можно видеть в категории
    influenced мы просто видим что Smalltalk
    влиял на Java, Go, Swift. Но я здесь не согласен потому что мы не можем измерить глубину
    этого влияния. Это все равно что сказать что Сталин влиял на Черчилля. Как влиял? На 10%?
    Или более чем половину? Сложно. Насчет Java я тут сказал-бы что сомнительно. ООП? Может быть.
    Акторы? Нет. В Java изначально нет акторов. Они существуют позже в виде фреймворков но
    языком не поддерживаются.

    По поводу MessageBus. Если брать технологию акторов которая используется в Erlang.
    то там скорее не message bus а очереди сообщений между потоками-акторами.
    Если про Smalltalk сказать нечего то про Erlang я могу сказать что на нем написаны
    две единицы софта такие как RabbitMq (очень надежная и неубиваемая система MQ).
    Может не супер-производительная. И CouchDb которая выделяется своей
    устойчивостью ко всяким сетевым сбоям. Реклама говорит что Кауч работает
    практически при мигающей сети, при обрывах и т.п. лучше чем аналогичый TCP-IP совт.

    Мысль вторая. Что Кей говорил про ООП.

    У меня есть цитатник. Я туда собираю некоторые слова на лытни. И иногда слова Кнута, Дейкстры
    и прочих it-академиков. Вот из цитатника Кея:

    I made up the term "object-oriented," and I can tell you
    I did not have C++ in mind.

    Что в этой прямой речи можно понять. Что господин Кей открещивается от современного ООП.
    А фактически все современное ООП зеркалит то что есть в С++. Здесь вы можете со мной спорить
    о первенстве (я не буду спорить я не знаю). Но абсолютно очевиден факт что мир пошел по пути
    жесткой синхронщины в 80х. И пока все еще идет. Будут ли примитивные типы int/double обьектами
    не суть важно. Тут важно что Кей постулирует среду в которой двигаются сообщения. Как сеть в миниатюре.
    А классическое ООП С++ - лишает нас этой среды и заменяет ее вызовом метода. Никакого сообщения
    в С++ нет и быть не может потому что сообщение НЕ существует в отрыве от основного потока который
    инициировал вычисления. Умрет поток - развалится весь стек и параметры и все. В противоположность
    в языке Erlang поток (процесс) приёмник может дохнуть много раз но стек сохраняет свою живучесть
    просто повторяя вычисления заново. И здесь мне кажется и идет развилка путей.

    И здесь как-раз мы может говорить о недостатках. Очевидно что у нас появляется лаг приемки-передачи
    сообщения. У нас появляются мягкие гарантии времени обработки. И многое другое.

    Интересно почему в 80х Алан Кей проигрывал. Я думаю что победил прагматизм. В те далекие 80-е
    комьютеры были еще слабыми. Частота мерялась сотнями килогерц и мегагерцами. И в расчетах
    каждый такт был важен. И красивые и академические языки такие как Lisp, Prolog, Smalltalk
    просто проигрывали языку С в силу оверинжинеринга. А поскольку С++ был вначале действительно
    ООП-надстройкой над С - то он предлагал и ООП-подход и скорость портабельного ассемблера.
    И хотя я лично не люблю С++ (я считаю его перегруженным техническими долгами прошлого)
    я признаю что бизнес выбирая С++ выбирал просто скорость вычислений. Академизм и красивые
    доказательства правоты программ были тогда не нужны. Нужно чтоб банковское приложение
    быстро считало кредиты и выдавало зарплаты и пенсии.

    Сегодня, когда мы нежемся в сладкой неге мощных процессоров и даже (!) облаков - мы можем
    себе позволить любого уровня парадигмы и абстракции. Цена 1 абстракции стала настолько дешево
    стоить что нам дешевле в банках запускать Java/Net приложения и на ходу фиксить ошибки
    чем долго разрабатывать на С++ и иметь неопредленнное поведение и тяжелый анализ
    в случае падения. Даже такой уродец как Python взлетел как язык интеграции а не разработки.

    Мысль третья. Нестандартные и асинхронные архитектуры реализованные в железе.

    Недавно смотрел анонс нового процессора от Чака Мура (это тот самый Мур который создал закон имени себя).
    Мне кажется это пример той самой асинхронной клетки о которой мечтал Алан Кей.

    Мысль четвертая. На кого похож Алан Кей?

    Не знаю как вам. :) А мне он уж очень напоминает Боливара Траска из Люди Икс Дни Минувшего будущего.

    Мысль 5. Что делает Алан Кей на фото?

    Бренчит на музыкальных инструментах. Наверное блюз. Блюз потерянных архитектур :)
    Ответ написан
    Комментировать
  • Существуют ли в opensource-проекты с хорошей архитектурой?

    mayton2019
    @mayton2019
    Bigdata Engineer
    SOLID может на каком-то этапе противоречить например KISS. Например вы, как старший разработчик можете видеть "вперед" и прогнозировать потребность бизнеса в расширении какого-то функционала. И будете закладывать Open/Closed и прочие философии. А разработчик уровня Junior который неделю назад пришел на проект - этого не знает и будет писать "как чукча". Тоесть буквально то что надо сделать - тои напишет. И между вами может возникнуть спор как раз на тему SOLID против KISS. Но вы можете ошибаться в своём прогнозе потребности бизнеса. Или бизнес может передумать. В этом случае правда оказалась на стороне святой простоты (Santa simplicitas).

    Как вы понимаете такие антагонизмы не могут быть удовлетворены аж никогда. Поэтому вы никогда не найдете проекты которые удовлетворяют ВСЕМ философиям которые перечислены в списке одновременно.
    Ответ написан
    Комментировать
  • Как лучше проводить анализ исходного кода?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Скорее всего вам это не надо. Внешний анализ заказывают банки например чтобы подтвердить что софт - безопасен и не боится эксплоитов. Из таких систем я помню платную Veracode. Она находила у нас ошибки безопасности в логгировании (!).

    Вот. Из безсплатных - посмотрите SonarQube. Он работает с плагинами.

    Да и очень полезно указывать конкретные теги языков. Что там у вас? 1С? Кобол? Или Лого?

    Я серъезно! Почему не указываете?
    Ответ написан
    Комментировать
  • На основе чего генерируются чертеж?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Я вот помню что AutoCad программировался на AutoLisp. Тоесть теоретически если вы создадите команды для черчения - то AutoCad может их исполнить в пакетном режиме. Но если вообще развивать эту идею - то можно брать любой векторный редактор и смотреть что под него есть.
    Ответ написан
  • Подскажете по архитектуре "мультисервисного" приложения?

    mayton2019
    @mayton2019 Куратор тега Java
    Bigdata Engineer
    Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

    Зачем такой ужас. Делай только те репозитарии которые реально задействованы в бизнес-задачах.
    Из личного опыта могу сказать что если приложение спроектировано по умному - то ему не нужно
    выделять каждую таблицу в Entity.
    Ответ написан
    3 комментария
  • Как гарантировать отправку в кафку некоего события?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Нет никакого смысла страховать Кафку. Она совершенно самодостаточна. Есть настройка message delivery semantics. Почитай про нее. Вобщем идея такава что - каждый сам себе в зависимости от бизнес требований выставляет такие параноидальные настройки producer/consumer, чтобы было и быстро и надёжно одновременно.
    Ответ написан
    Комментировать
  • Отслеживание новых записей в бд в реальном времени?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Богдан. Обычно реляционные БД так не работают. Клиент - спрашивает. БД отвечает. Обратное не делают обычно.

    Отслеживание новых записей - это технически сложная задача потому что нужен буфер и умножение этого буфера на количество подписчиков. Тоесть приходим к полноценной MQ-системе. Обычно БД конфигурируется так что лишних ресурсов на это нет. Да и зачем БД рассылвать уведомления когда это задача сервера приложений.

    Если вы все таки решили спрашивать на зарубежных форумах - то не говорите слово MySQL/SQL. Пишите просто - информационная система и хранилище. Пускай вам советуют с чистого листа как это надо дизайнить.
    Ответ написан