• Как понять микросервисы?

    azerphoenix
    @azerphoenix
    Java Software Engineer
    Добрый день!
    Прежде всего ответьте на один вопрос - какую именно проблему вы хотите решить переходом на микросервисную архитектуру. Обратите внимание, что обеспечивать ACID в микросервисной структуре сложнее, чем в монолитах. Также обслуживание микросервисов тоже сложнее. Если есть нагрузка на сервис, то не факт, что вам нужны микросервисы. Возможно, что вам нужна оптимизация сервиса или более производительное железо.

    Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

    Например, в случае с Spring API Gateway в нем есть балансировщик. Балансировщик помогает снижать нагрузку с микросервиса, если у вас имеются несколько копий, то каждый раз запросы идут на разные копии. Также gateway удобен тем, что клиент не беспокоится о том, на какой эндпоинт нужно отправлять запрос. Возможно, что у вас несколько копий одного сервиса и то какой из них должен ответить на запрос клиента, самого клиента это не касается.

    Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

    Можно и через RabbitMQ. А так например, Spring API Gateway использует асинхронные запросы (Spring Webflux) для реализации данной задачи.

    Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных?

    Это зависит от вашей задачи. Да, может быть и своя БД. А может быть и нет.

    Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

    Опять-таки зависит от вашей задачи, от нагрузки и т.д. Возможно, что регистрация, авторизация и сброс пароля будут отдельными микросервисами. А возможно, что User CRUD будет одним микросервисом.
    Ответ написан
    Комментировать
  • Как понять микросервисы?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Микросервисы пишут не для того, чтобы просто переделать API.

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

    А уже исходя из этой точки зрения:

    1. Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

    А если нужно много экземпляров, будете одним nginx-ом раскидывать по 10 локейшенам? Микросервисы в современном мире предполагается запускать в докере на собственном легковесном веб-сервере (типа Jetty), поднимать нужное количество экземпляров и балансировать чем-нибудь на входе, но не по локейшенам.

    2. Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

    РаббитMQ или kafka позволяют множеству экземпляров вашего сервиса обрабатывать сообщения, с гарантией того, что из очереди ничего не пропадет, и если какой-то экземпляр сдохнет, то этот запрос обработает другой экземпляр. Именно ждать ответ наверное не самое правильное, но это можно смотреть как вам удобнее - периодически опрашивать очередь, или настроить чтобы message service сам пушил по событию.

    3. Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных? Как например в админке обращаться к пользователям, чтобы их добавить или заблокировать, я должен запрашивать пользователей с микросервиса? Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

    Это как вы хотите. Если у вас очень много пользователей и авторизация тормозит, но можно сделать микросервис с авторизацией, сделать кластер базы данных с репликацией. Дальше можете балансировать пользователей и там уже решать как их раскидывать. Или база мощная и все экземпляры могут работать с кластером. Или делите базу на части, и раскидываете пользователей по алфавиту (база юзеров от A* до H*, база юзеров от I* до M*, по региону или как вам нравится).

    Микросервисы нельзя писать до того как вы представите себе в голове общую архитектуру всего проекта, и какую проблему вы хотите решить.

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

    @i1yas
    1. Да, я так часто делаю, особенно для тех стеков, с которыми я часто не работаю.
    2. Тут смотря что вы имеете ввиду.
    Есть команды docker run/docker exec/docker-compose run, они либо создают контейнер и запускают команду, либо запускают команду на существующем контейнере, например, bash, либо php -a, psql - таким образом можно попасть в интерактивную среду внутри контейнера.
    3. Как настроете. По умолчанию все данные хранятся внутри контейнера и они будут потеряны при следующем рестарте. Для данных, которые нужно сохранять между рестартами, например база данных, есть volume. Если кратко, можно забиндить часть данных внутри контейнера либо на файловую систему, либо в специальное хранилище докера.
    4. Да, можете для примера посмотреть как устроены docker-compose.yml php + mysql + nginx или что вам ближе. Рекомендую просто потыкать, попробовать своей hello world под docker-compose запустить.
    5. Пункт 4, посмотрите какой-нибудь простенький docker-compose.yml, чтобы там БД была и приложение в разных контейнерах, думаю у вас вопросы многие уйдут
    Ответ написан
    Комментировать
  • Переход с PHP на C#?

    Мне после Ruby довольно хорошо пошло изучение C#. Все довольно интуитивно. VS вообще крутая вещь, очень помогает при навигации, всякие помощники для кода и отладка удобна. Язык несложный и имеет довольно продуманный фреймворк .NET.
    Из минусов помню проблемы с разрешением зависимостей в крупном solution, но наверное можно списать на недостаток опыта.
    Ответ написан
    Комментировать
  • Переход с PHP на C#?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    Гляньте мои репозитории.

    bin и obj вас не волнуют это артефакты.

    Основа проектов файлы sln (решение)
    они могут содержать кучу проектов, тут расширение может различатся.

    IDE Дает адекватные подсказки по методам, но лучше все же по верхам пробежаться на сайте https://metanit.com/sharp/
    Ответ написан
    Комментировать
  • Переход с PHP на C#?

    @OwDafuq
    NuGet — система управления пакетами для платформ разработки Microsoft, в первую очередь библиотек .NET Framework. (С) Wiki.

    .csproj не нужно трогать руками, его генерирует сама VS.

    obj & bin folders

    Изучайте сначала основы C#, а не прыгайте сразу с головой в ASP
    Ответ написан
    2 комментария
  • Что мотивирует open source сообщество?

    Zoominger
    @Zoominger
    System Integrator
    Говорю за себя.
    В моих открытых проектах мной двигали исключительно филантропические мотивы - вот нет такого ПО (для Linux, конечно), это неудобно, тогда я напишу его для себя. Теперь оно есть и можно сделать хорошее - распространить его среди страждущих. Правда, в моем случае ПО помогать сопровождать было некому (отчасти из-за того, что оно на Qt, которое мало кто знает, отчасти от того, что швабодное шаобщество в большинстве своём сборище фанатиков и балаболов, которое мало что умеет на деле).

    Дополнительно - тренировка, это ж хороший пет-проект, оттачивание навыков, прокачка.

    А вообще - читните “Just for fun” Торвальдса, там все написано.
    Ответ написан
    4 комментария
  • Зачем в современном php фреймворки?

    Sanes
    @Sanes
    Чтобы было.
    Это просто очередной уровень абстракции, как и PHP перед Си.
    Обычно такими вопросами задаются от безделия.
    Ответ написан
    2 комментария
  • Как выбрать правильный вектор развития в IT сфере?

    zualex
    @zualex
    Senior Software Engineer
    Карта развития веб-разработчика
    Coding Interview University

    По поводу велосипедов: build-your-own-x
    Попробуй написать свою БД, веб сервер или поисковый движок.

    Давай действуй, я в тебя верю!
    Ответ написан
    Комментировать
  • Как выбрать правильный вектор развития в IT сфере?

    @frozen_coder
    Java-developer
    Не считаю себя хорошим программистом и профи, пока в процессе. Могу поделиться своим ИМХО.

    Часть 1
    1. Готовое использовать тоже надо уметь и знать, где это готовое найти, которое помочь может, какое готовое хорошо, а какое будет лишним.
    2. П.1 не исключает возможности писать велосипед. Писать велосипеды полезно для себя, чтобы глубже разобраться в работе готового, в процессе подглядеть на готовый код, подумать как написал бы сам. Мб писать узкоспециализированные велосипеды, которые подойдут именно вашей задаче лучше, чем готовые, но универсальные решения.
    3. Я работаю full-stack. У нас все такие, ибо народу не так уж много. Периодически устаю от этого, но периодически не представляю себя без возможности писать и на фронте, и на беке. Если вам по душе решать задачу от начала и до конца, то почему нет? Главное, чтобы в кайф. Возможно стоит в таком случае развиваться периодами - выделяем период и изучаем это направление, потом переключаемся на другое. А возможно надо отталкиваться от конкретной задачи и в её рамках изучать как решить её на клиенте, а как на сервере. Чтобы переключаться и читать любой код, надо обладать широким кругозором и знать базовые концепции, Computer Science, паттерны, парадигмы и т.п. Чтобы делать это быстро, нужен опыт. Когда однажды решал что-то подобное, то второй раз решить это будет проще и быстрее. Ещё полезно держать руку на пульсе и слушать, что сейчас в IT вообще твориться, чтобы знать куда копать, если возникнет необходимость - я покрываю это подкастами и статейками из всяких еженедельных рассылок.

    Часть 2
    1. Английский каждый день, хоть 10 минут, но каждый день. Читать, смотреть, слушать. В идеале ещё и говорить.
    2. Дискретка - да. Например, есть книжка Дискретная математика для программистов. Вышка, матан - ну хз, смотря, что за задачи решать, большинству не особо то и пригождается.
    3. Алгоритмы и структуры данных - да. Какие-нибудь классические книжки по этому делу. Кормен, например. Но вот тут, имхо, нужно писать велосипеды! Изучаете алгоритм или структуру данных, описание на естественном языке, а потом берёте ваш любимый ЯП и реализуете этот алгоритм по описанию сами. Затем ищите в интернете его "эталонную" реализацию, сравниваете с вашим велосипедом. Как книжку пройдёте, то мб захочется углубиться в какую-нибудь сферу Computer Science. Ещё есть Open Source Univercity - https://github.com/ossu/computer-science - это сборник лучших бесплатных материалов по CS в сети, как бы онлайн-образование в сфере CS. Сам не проходил, но в планах туда заглянуть есть)
    4. Паттерны, как и п.3
    5. Изучите пару ЯП с парадигмой, отличной от привычной вам.
    6. Если вы в web, то надо познать как работают сети.
    7. В идеале познать ОС, в общих чертах как устроена, как работает. Команды оболочки, поадминить какие-нибудь сервисы в мини-сети из виртуалок, пожить немного чисто в консоли.
    8. Принять участие в Open Source. Вы же пользуетесь готовыми штуками. Возьмите небольшую такую штуку, посмотрите как она устроена внутри, сходите на её гитхаб, посмотрите issue, мб там нужна ваша помощь. Часто есть issue, отмеченные для новичков. Тут одни плюсы - разберётесь в готовой штуке, сделаете её лучше для себя и для других, получите гордое звание контрибьютора).
    9. Не слушать таких людей, как ваш начальник - это у него не получится, а вы на себе крест не ставьте, вам до пенсии ещё кодить и кодить.
    10. Ну и писать код, больше кода богу кода.
    Ответ написан
    2 комментария
  • Как выбрать правильный вектор развития в IT сфере?

    @spaceatmoon
    Отвечаю по вашим вопросам.

    1. Человек, которые знает все тонкости к React, будет шарить лучше чем человек, который пилил свой велосипед. Да, велосипедист будет учиться на своих ошибках, но это ошибки детские. Человек, который учит React будет видеть ошибки местами детские, местами взрослые и знание как их решить будет полезней. К тому же велосипедист при написании свое кода местами будет бороться с языком/машиной, что к его профессионализму никак не скажется и как правило еще раз, это детские ошибки.
    2. Только в целях самообучения и стартапы. На обычный продакшн даже не смей.
    3. Если ваш начальник такой умный, то пусть мне даст готовое решение по синтезу речи на питоне к примеру. Что есть, но оно топорное? Или к примеру пусть кинет ссылку на игру где можно изменять ДНК, где есть караваны, космодесанты... да что же такое, опять нет? Ну ладно, даю последний шанс - операционная система такая же популярная как Windows, но без навязчивых обновлений и жрущая в 3 раза меньше ресурсов умещая в Adobe Premire.... оу, кто-то сдал позиции.

    Короче писать еще и писать программы. Дело не в том насколько революционная программа, люди тысячи программ пишут про одно и тоже. Все они отличаются тем, что каждая по своему удобна, быстра и дешева.

    Кстати, хотите революционного? Напишите язык, который также удобен к примеру как питон, который может во все платформы и быстр как C. Вперёд!
    4. Только если вы в стартапах хотите работать. Фулстек это как ортопед, и не смотря на то, что ортопед знает много, в основном это понос и ОРВИ. В вашем случае это CRUD и шаблоны будут. Ну такое короче.

    Математика вам нужна будет когда начнете программировать что-то серьезное. Для фулстеков и сайтоделов математика не нужна. Нужно понимание построение архитектуры, Отличие ООП и ФП, и умение комбинировать.
    Ответ написан
    5 комментариев
  • Как выбрать правильный вектор развития в IT сфере?

    1. Писать велосипеды.
    2. Стоит, правда в большинстве случаев это будет бессмысленно.
    3. Неправда.
    4. Все мы немного фулстеки по жизни: и кран починить, и дерево посадить. Но специализация должна быть у каждого. Лично я убеждаюсь в том, что продуктивность теряется, когда ты пишешь как фулстек; при этом знать, что же происходит по ту сторону медали ты тоже должен(в идеале). Можно, условно, попробовать полгода фронт, полгода бек, договорившись с командой. А там и дальше сам выводы сделаешь.
    Ответ написан
    Комментировать
  • Как выбрать правильный вектор развития в IT сфере?

    JhaoDa
    @JhaoDa
    LaravelRUS Team
    1. А что, создание приложения заключается только в использовании библиотек? Прям мечта всех «войтивайтишников» — поставил десяток пакетов и проект готов! Лепота! Так не бывает.

    2. Иногда стоит. Но критерий этого «иногда» очень размыт. Например, внедрить какое-то готовое решение в спешке — неделя, свой велосипед — пара дней. И вот эта разница в пять дней даст заранее известный профит. Или отсрочку на то, чтобы не торопясь разобраться во внедряемом решении, пусть даже за две недели. Тогда да, это оправдано.

    3.
    Однажды в молодости Макс Планк пришёл к 70-летнему профессору Жолли и сказал ему, что решил заниматься теоретической физикой.
    — Молодой человек, — ответил маститый учёный, — зачем вы хотите испортить себе жизнь, ведь теоретическая физика уже в основном закончена... Стоит ли браться за такое бесперспективное дело?!
    Надеюсь, вы знаете, кто такой Макс Планк и что он сделал для физики?

    4. Моё личное мнение — узкая специализация с возможностью, ЕСЛИ ОЧЕНЬ НАДО, фуллстэчить. Я PHP-бэкэндер, но могу кодить на современном JS и верстать, хоть и не люблю. Только в экстренный ситуациях.

    Из вашего пространного монолога не понятно самое главное — чем вы занимаетесь сейчас и какой уровень знаний?
    Ответ написан
    1 комментарий
  • Как побороть NIH-синдром?

    petermzg
    @petermzg
    Самый лучший программист
    Когда вы были маленьким ребенком, то для вас буквы представлялись неведомыми закорючками, а уж написать каждую букву требовало огромного труда, но они все равно были мало похожими.
    А сейчас вы умеете читать и писать. Вы научились этому. Так и с программированием.
    Ответ написан
    Комментировать
  • Резонность использования админок на php yii2/python django?

    sim3x
    @sim3x
    1. Админка джанги - только для разработчиков и админов или особо доверенных лиц
    2. Не имеет значения
    3. Нет
    4. На продакшен проектах - нет, на пет-проектах - да
    Ответ написан
    Комментировать
  • Резонность использования админок на php yii2/python django?

    Maksclub
    @Maksclub Куратор тега Веб-разработка
    maksfedorov.ru
    Есть задача -- сделать проект с некоторой логикой, вместо реализации самой логики и написании полезного кода при отсутствии инструментов (генераторы админки например) -- вы 90% времени убьете на как раз шлепание верстки и однотипного бойлерплейта, тк вы не хотите одной командой

    Выбирайте

    Работаю сейчас с старенькой ЦМС -- приходится по 100 раз руками делать и проверку запросов, и по 100 раз шаблоны заново делать для админки -- надоело очень...
    Для логики надоело писать однотипные методы с однотипными запросами в БД -- вот уже поставил задачу себе впилить Eloquent ORM и создать генерацию страниц :) либо позвать фрейм на помощь :)

    узнал, что страницу авторизации можно написать через один скрипт, сразу бросил. Не хочу стать клепальщиком...

    Не клепайте -- делайте каждый болт самостоятельной нарезкой, это очень важно для современного инженера -- самому шлепать болты и гайки, вместо создания инженерных конструкций (сарказм)
    Ответ написан
    5 комментариев