А можете рассказать технические подробности реализации? Какие готовые или самописные решения применили, как сделали балансировку запросов и коннектов, как сделали авторизацию запросов, как реализовали отказоустойчивость, как проводили нагрузочное тестирование, какие результаты получили
Отличная книжка про архитектуру от автора принипов SOLID. Так же рассказывает про дальнейшее развитие этих принципов на более высокие уровни, например, при переходе с уровня классов к уровню модулей и компонентов. Хорошо перекликается с другими книжками по архитектуре (много общего с DDD и MDD). Читал в оригинале, про переводы не знаю. Английский среднего уровня, много новых слов. Легендарный автор рассказывает что такое архитектура, и как её правильно готовить. При этом не важно какой язык программирования, и даже какой его тип, потому что принципы не поменялись с того времени, когда он стал программистом, 50+ лет назад. В очередной раз с другого ракурса объясняет и демонстрирует, что архитектура - это не про фреймворки, и не обязательно они не должны оказывать влияние на архитектуру.
Книга затрагивает не только DDD, но и ES и CQRS, с упором на практическое применение. Логическое продолжение книги "Реализация методов предметно-ориентированного проектирования".
Открывает новые архитектурные подходы, в виде ES, CQRS, на примерах с современным набором инструментов, в виде REST протокола, мессаджингом и так далее. Опять же упор на практику, в более современном виде.
Не уверен что есть перевод, по крайней мне не удалось его найти. Но английский не сложный, проблем с ним не должно возникнуть. Тем более после предыдущей книжки.
“Microservices for everyone” - Mattias Noback https://leanpub.com/microservices-for-everyone Книга про то, как современные технологии объединяют основные подходы в DDD, ES, CQRS и гармонично выливаются в теорию и практику микросервисов.
А чем devops, описанный в статье отличается от выделенной команды админов и мониторщиков? Поймите правильно, это хорошая практика, и здорово что вы к этому пришли. Но не могу до конца понять, причём тут devops. Каждый раз когда слышу про «команду devops» вспоминаю статью devops на википедии и популярную некогда статью «There's No Such Thing as a „Devops Team“». И как я их понимаю — смысл devops как раз в том, чтобы это было частью существующей команды, а не отдельной командой.
Спасибо за перевод.
Привлекло слово grpc в заголовке. Но если его заменить на любое из: http, rest, wsdl, graphql, tcp (вы поняли мысль), то статья практически не изменится (разве что вызов клиента поменяется на соответствующий протоколу). Сам недавно начал изучать этот протокол, и было бы интересно почитать про то как можно его ускорить. Можете подробнее сказать как статья связана с grpc?
Пример и правда не лучший — стоило бы убрать сеттеры и передавать параметры в конструктор (Rectangle(int width, int height) и Square(int size), тогда бы было меньше вопросов. Классы не обязаны быть изменяемыми.
Квадрат — это сын ромба и прямоугольника, и наследует геометрические свойства обоих родителей, являясь при этом внуком четырехугольника и вместе со своими родителями наследуя и его геометрические свойства.
если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление
Это не из доклада, это — из общения с различными людьми. Но я понял, что это было ошибочное мнение. В докладе этот момент не был освещён.
Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
Абсолютно согласен. По личному опыту я сделал точно такие же выводы.
Первый вопрос про ревью и мотивацию. Смотрел в записи ваш доклад о performance review с одного из митапов в Баду, было очень интересно. Насколько я понял, материальные поощрения после review довольно существенные, потому что это хороший инструмент мотивации. Как это сказывается на основной (обязательной) части зарплаты? Пример для наглядности — в одной компании ценят стабильность, и ежемесечная зарплата программиста 180 К (ниже этого он не получит), а ежеквартальные премии могут составлять например 20 К за очень хорошее review — условно говоря на пятёрку по пятибальной шкале, а если сотрудник хорошо работал, но после нормировки оказался ниже середины, то премию он не получит вообще. В другой компании с точно таким же зарплатным фондом обязательная часть зарплаты — это 120 К, но если он постарается, то в конце квартала у него будет премия 200 К (это плюс к обязательной части). Как следует из расчётов, у компании одинаковый зарплатный фонд (оба сотрудника получат по 560 К за три месяца работы, при высшей оценке на ревью). Соответственно в одной компании минус в том, что премия после review слабо мотивирует, а минус второй компании, что хороший, но невыдающийся сотрудник чаще всего будет получать 120 К, что будет его демотивировать так же, как высокая премия мотивирует лучших сотрудников. В каких пределах находится премиальный процент от обязательной части зарплаты, в каких границах находится основная базовая зарплата относительно рыночной зарплаты, и как решаются проблемы демотивации для тех, кто останется недоволен премией?
Второй вопрос частично связан с первым, но больше про HR-стратегию и привлечение новых сотрудников. В Бадушных официальных зарплатных вилках, которые можно встретить на сайтах по поиску работы (и даже на хабре), указываются верхние границы, существенно превышающие среднерыночтные. Но вместе с информацией из доклада про ревью складывается впечатление, что обязательная зарплатная часть существенно ниже нижней границы вилки, а верхняя граница вилки актуальна для очень маленького процента сотрудников и далеко не каждый месяц, и только при условии максимальной оценки на ревью. Часто встречал мнение (как HR-персонала, так и менежеров и разработчиков), что на самом деле для большинства сотрудников вилка по факту меньше, с учётом результатов ревью. Многие относятся с недоверием к официальной вилке. Так вот вопрос — насколько она верна для существующих сотрудников, насколько это честная цифра?
Третий вопрос про тимлидов. Не секрет, что в разных компаниях очень сильно различаются обязанности тимлидов, а так же различается количество уровней IT-шной иерархии управления. Иногда над тим-лидом уже CEO, а иногда ещё три уровня технических управленцев. Иногда тимлиды програмирут 90% времени и по сути больше похожи на ведущих разработчиков, а иногда совсем не программируют, а управляют командой из 15-20 человек. Например, существует мнение, что при команде в 6-8 человек на программирование времени не остаётся. В некоторых компаниях тимлиды отвечают за продуктовую часть, у них свои бизнесовые KPI, а в других ответственность ограничена исключительно качеством кода команды. В некоторых — у тимлида в подчинении кроссфункциональная команда, состоящая как из серверсайд разработчиков, так и клиентсайд разработчиков, тестеровщиков, админов, техписателей и так далее, в то время как в других компаниях у серверсайд тимлиодов в подчинении исключительно серверсайд разработчики. Расскажите, пожалуйста, какой процент времени тимлиды в Баду тратят на непосредтсвенное программирование, как этот процент времени зависит от размера команды, какие у них KPI и входят ли в них бизнесовые и продуктовые показатели, могут ли быть в одной команде и серверсайд и клиентсайд разработчики в подчинении у одномго тимлида, какого размера команды, и какой дальнейший путь развития тимлидов в Баду, кто ими руководит и за что он отвечает?
Что-то не могу понять, зачем GraphQL сравнивать с REST; было бы логичнее выбрать похожий по смыслу формат, например json-api
http://jsonapi.org/format/#fetching-sparse-fieldsets (можно указывать, какие поля возвращать)
http://jsonapi.org/format/#fetching-includes (можно указывать связанные ресурсы, и т.д.)
В _полном_ руководстве ожидал увидеть подробную информацию про HSTS и инструкции для плавного переезда сайта на HTTPS без потери ранка и индекса в популярных поисковиках.
если вдруг вы знаете о каком-нибудь стоящем мероприятии, дополняйте наш список в комментариях.
Есть ещё одна отличная конференция, которая традиционно проходит в первой половине года — https://dddeurope.com/ К сожалению, она проходит в январе, поэтому попасть на неё можно будет видимо только первой половине следующего года. Уровень конференции довольно высокий, и материал будет полезен широкому спектру разработчиков. Видео материалы всех выступлений выкладывают оперативно, и со всеми ними можно ознакомиться на сайте, чтобы самостоятельно составить впечатление о качестве конференции.
Рекомендую.
Прошу прощения за опечатки, возможность редактирования пропала раньше, чем я успел дочитать :(
В следующий раз будут готовить и проверять текст комментария отдельно до публикации.
> а комментарии в tarantool
читать «а лайки — в tarantool»
В общем случае довольно сложно вывести формальную формулу,
так как нет абстрактной формулы масштабируемости, а всё
зависит от конкретной задачи, предметной области,
безнес-требований, выбранного решения и архитектуры.
Разделение монолита на части не обязательно будет способствовать
масштабированию.
1) И это связано с накладными расходами на взаимодействие между
получившимися частями. Чем интенсивнее взаимодействие, объём
трафика, количество запросов, тем медленнее будет работать
система после разделения на части. Отчасти это зависит от
архитектуры, которая получится в результате. Тесно связанные
между собой части будет сложнее разделить на отдельные сервисы.
2) Так же это связано с потерей возможности низкоуровневых
оптимизаций. В монолитном решении можно сделать более эффективные
оптимизации. Например можно сделать JOIN двух больших mysql таблиц,
вместо того, чтобы делать несколько запросов.
3) Накладные расходы на межсерверное взаимодействие. Если данные
лежат на одном сервере, или вообще в оперативной памяти одного и
того же процесса, то получить такие данные можно быстрее, чем из
оперативной памяти других серверов, к которым нужно ещё сделать
сетевые запросы.
Однако не всё так плохо. В самом общем случае довольно легко
доказать, что разделение будет способствовать масштабируемости.
Чем больше и монолитнее система, тем она более требовательна
к ресурсам. Кроме того, такая система ещё более сложная в плане
поддержки. Такую систему сложнее дорабатывать и внедрять новый
функционал. Обычно такие системы плохо держат высокую нагрузку.
Если же разделить систему на более мелкие независимые части,
то появится возможность разместить отдельные части на разных
серверах. Это значит, что нагрузка, создаваемая каждой частью,
должна быть меньше, а следовательно и требовательность к ресурсам
будет ниже у каждой из таких частей (хотя суммарная нагрузка,
создаваемая всеми составными частями может быть выше). Кроме того,
более простой сервис проще масштабировать, чем более сложный сервис.
Это интуитивно понятно, чем проще компонент, тем удобнее с ним
работать, проще поддерживать, изменять, дорабатывать, и конечно
масштабировать, так как для масштабирования придётся вносить
изменения в копмонент. В более простом компоненте меньше
составных частей, и с точки зрения управления сложностью
разработки такие части предпочтительнее в сложных сервисах.
Проще понять внутреннее устройство и внутреннюю логику работы,
понять где и во что может упираться производительность, и
сделать правильное предположение для рефакторинга в сторону
поддержки масштабирования.
Например если сервис использует две больших MYSQL таблицы с
JOIN запросом, и для масштабирования потребуется шардинг, то
из-за этого JOIN запроса шардить просто так не получится. Можно
расшардить самую большую таблицу, а таблицу поменьше реплицировать
на все шарды, чтобы JOIN запрос всё ещё мог выполнятся. Но это
поможет до тех пор, пока не возникнут проблемы и со второй
таблицей. Поэтому с точки зрения именно масштабирования имеет
смысл отказаться от JOIN запроса, и использовать например
последовательные запросы. В этом случае может появиться
возможность каждую из двух больших таблиц масштабировать
отдельно, для каждой сделав шардинг. Одну таблицу
масштабировать проще, чем две связанных JOIN-ом.
Кроме того, для более простого сервис проще рассчитать
математически и аналитически ту нагрузку, которую он
сможет выдержать. Зная внутреннюю архитектуру и бизнес-логику
сервиса можно связать количество запросов от клиентов
(внешние сервисы, которые запрашивают данные) с запросами на
бекенд и хранилище (допустим та же mysql), и спрогнозировать
рост нагрузки на хранилище (количества разных типов запросов,
количество обрабатываемых данных, общий размер данных) с ростом
входящих внешних запросов. Рост нагрузки на бекенд и хранилище
будет более линейным и предсказуемым в более простых системах.
В общем случае решение формализовать довольно сложно, так как
слишком много будет независимых переменных, и чем сложнее и больше
сам сервис, тем больше их будет, и тем сложнее сами эти переменные
выявить. Теоретических методики формальной оценки любого по
сложности сервиса мне не известны. Но на практике обычно всё
гораздо проще. Нужно всего-лишь понять архитектуру существующего
сервиса, нарисовать схему, выделить более менее отдельные и
независимые внутренние компоненты, понять взаимодействие между
ними, и какой эффект они оказывают с точки зрения нагрузки на
процессор, память, нижестоящие внешние сервисы, хранилище, базу
данных и так далее. Дальше останется понять, как можно разделить
сервис так, чтобы максимально нагруженные части можно было вынести
на отдельные сервера, учитывая количество и качество связей между
составными частями. Чащей всего для этого нужно пересмотреть
архитектуру всего решения с функциональной точки зрения, чтобы
получившиеся компоненты были законченными по смыслу и логичными,
чтобы все тесно связанные между собой данные принадлежали бы
одному и тому же компоненту, а между разными компонентами связей
было бы сильно меньше. Для новой же архитектуры нарисовать все
связи, количество запросов между ними, их типы, объёмы данных и
так далее. Чем проще будут отдельные и независимые, но законченных
с точки зрения бизнес-логики компоненты, тем проще будет
предсказать или посчитать создаваемую ими нагрузку, и тем
проще будет придумать как их масштабирвоать при необходимости.
Например если взять сервис, который работает с двумя большими
таблицами MYSQL и использует JOIN, например модуль комментариев
к статье на сайте с возможностью лайка и дизлайка каждого комментария,
то разделив этот сервис на два (один работает непосредственно
с комментариями, а другой обрабатывает лайки и дизлайки), можно
каждый из них поместить в своё собственное, более подходящее под
нагрузку хранилище, например комментарии положить в nosql mongodb
какой-нибудь, а комментарии в tarantool, прикинув по нагрузке,
что лайкают и дизлайкают чаще, чем пишут и редактируют комментарии.
3. В коде АТС 1 не может быть третьей цифрой, если вторая цифра – это 1.
Ваше регулярное выражение уже соответствует первому правилу, но нарушает второе и третье. Пока давайте разберемся со вторым.
…
Поскольку региональный код такой же, как и код АТС, можно просто продублировать регулярное выражение, чтобы довести этот шаблон до ума.
Я долго искал различные workshop'ы на тему fpga, но реально полезных статей и видео по этой теме в разы меньше, чем по теме микроконтроллеров. Поэтому найденные мной ссылки считаю пригодятся.
Вот тут небольшой обзор платы latice iCEstick iCE40HX1K (low cost fpga dev board, $22, ~1000 логических элементов), обзор verilog под простую задачу реализации сумматора на этом fpga, и обзор набора opensource инструментов для сборки и прошивки этой платы.
Не совсем так. Вы же в один архив все репозитории складываете? Так вот суть в том, что проще тогда даже в случае динамической машины достать предыдущий архив, и разархивировать его целиком, потом обновить существующие репозитории через remote update, и добавить новые через mirror, удалить ненужные, и опять заархивировать.
Я бы не рекомендовал использовать пароль от аккаунта для этого.
И в github и bitbucket можно добавить deployment key, который работает для read-only операций с репозиторием. С его помощью можно склонировать репозитории, но нельзя пушить и делать деструктивные действия.
С другой стороны, если сам список репозиториев в bb нельзя получить без пароля (не знаю, есть ли там oauth и т.п.), тогда это не так важно.
Ещё я бы рекомендовал хранить локальный кеш репозиториев, тоесть сохранять все репозитории с предыдущего бекапа. Это позволяло бы не делать каждый раз clone --mirror, а делать git remote update. Таким образом выкачивались бы каждый раз только новые коммиты и изменения в репозиториях, а не целиком все репозитории со всеми ветками с нуля. Для крупных репозиториев это работает существевнно быстрее.
А можете рассказать технические подробности реализации? Какие готовые или самописные решения применили, как сделали балансировку запросов и коннектов, как сделали авторизацию запросов, как реализовали отказоустойчивость, как проводили нагрузочное тестирование, какие результаты получили
Хорошая статья, много полезных ссылок, спасибо.
Я сам тоже собирал ссылки на тему DDD, и многие из них уже в статье есть, но некоторыми хотел поделиться дополнительно для полноты картины.
PS. Ссылки на книги не реферальные, а для быстрого поиска.
Книга "Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)" - https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
Отличная книжка про архитектуру от автора принипов SOLID. Так же рассказывает про дальнейшее развитие этих принципов на более высокие уровни, например, при переходе с уровня классов к уровню модулей и компонентов. Хорошо перекликается с другими книжками по архитектуре (много общего с DDD и MDD). Читал в оригинале, про переводы не знаю. Английский среднего уровня, много новых слов. Легендарный автор рассказывает что такое архитектура, и как её правильно готовить. При этом не важно какой язык программирования, и даже какой его тип, потому что принципы не поменялись с того времени, когда он стал программистом, 50+ лет назад. В очередной раз с другого ракурса объясняет и демонстрирует, что архитектура - это не про фреймворки, и не обязательно они не должны оказывать влияние на архитектуру.
Patterns, Principles, and Practices of Domain-Driven Design - https://www.wiley.com/en-ie/Patterns,+Principles,+and+Practices+of+Domain+Driven+Design-p-9781118714706
Книга затрагивает не только DDD, но и ES и CQRS, с упором на практическое применение. Логическое продолжение книги "Реализация методов предметно-ориентированного проектирования".
Открывает новые архитектурные подходы, в виде ES, CQRS, на примерах с современным набором инструментов, в виде REST протокола, мессаджингом и так далее. Опять же упор на практику, в более современном виде.
Не уверен что есть перевод, по крайней мне не удалось его найти. Но английский не сложный, проблем с ним не должно возникнуть. Тем более после предыдущей книжки.
Хорошие статьи Mattias Noback про DDD и архитектуру, на тему того как менялось понимание хорошей архитектуры, двигаясь от активной пропаганды конкретного фреймворка, через углубление в DDD и Hexagonal Architecture, к пониманию, что фреймворк это не главное, и надо строить архитектуру не завязываясь на него, по возможности
* https://php-and-symfony.matthiasnoback.nl/2017/07/layers-ports-and-adapters-part-1-introduction/
* https://php-and-symfony.matthiasnoback.nl/2017/08/layers-ports-and-adapters-part-2-layers/
* https://php-and-symfony.matthiasnoback.nl/2017/08/layers-ports-and-adapters-part-3-ports-and-adapters/
“Microservices for everyone” - Mattias Noback
https://leanpub.com/microservices-for-everyone
Книга про то, как современные технологии объединяют основные подходы в DDD, ES, CQRS и гармонично выливаются в теорию и практику микросервисов.
(Видео курсы) Domain Driven Design, CQRS, and Event Sourcing
http://subscriptions.viddler.com/GregYoung
Видео курсы на тему DDD/ES/CQRS и архитектуру. От автора самого термина CQRS.
Конечно, книжки лучше, но тем, кому некогда или не хочется читать, или хочется понять общую картину без углубления в детали, то рекомендую посмотреть.
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
Статья, в которой собрано всё вместе, с хорошей схемой, иллюстрирующей как все эти подходы соотносятся друг с другом.
Вот ещё парочка проектов, которые можно использовать для grpc запросов из консоли или браузера. Для полноты картины.
https://github.com/uw-labs/bloomrpc
https://github.com/ktr0731/evans
Привлекло слово grpc в заголовке. Но если его заменить на любое из: http, rest, wsdl, graphql, tcp (вы поняли мысль), то статья практически не изменится (разве что вызов клиента поменяется на соответствующий протоколу). Сам недавно начал изучать этот протокол, и было бы интересно почитать про то как можно его ускорить. Можете подробнее сказать как статья связана с grpc?
Это не из доклада, это — из общения с различными людьми. Но я понял, что это было ошибочное мнение. В докладе этот момент не был освещён.
Абсолютно согласен. По личному опыту я сделал точно такие же выводы.
Первый вопрос про ревью и мотивацию. Смотрел в записи ваш доклад о performance review с одного из митапов в Баду, было очень интересно. Насколько я понял, материальные поощрения после review довольно существенные, потому что это хороший инструмент мотивации. Как это сказывается на основной (обязательной) части зарплаты? Пример для наглядности — в одной компании ценят стабильность, и ежемесечная зарплата программиста 180 К (ниже этого он не получит), а ежеквартальные премии могут составлять например 20 К за очень хорошее review — условно говоря на пятёрку по пятибальной шкале, а если сотрудник хорошо работал, но после нормировки оказался ниже середины, то премию он не получит вообще. В другой компании с точно таким же зарплатным фондом обязательная часть зарплаты — это 120 К, но если он постарается, то в конце квартала у него будет премия 200 К (это плюс к обязательной части). Как следует из расчётов, у компании одинаковый зарплатный фонд (оба сотрудника получат по 560 К за три месяца работы, при высшей оценке на ревью). Соответственно в одной компании минус в том, что премия после review слабо мотивирует, а минус второй компании, что хороший, но невыдающийся сотрудник чаще всего будет получать 120 К, что будет его демотивировать так же, как высокая премия мотивирует лучших сотрудников. В каких пределах находится премиальный процент от обязательной части зарплаты, в каких границах находится основная базовая зарплата относительно рыночной зарплаты, и как решаются проблемы демотивации для тех, кто останется недоволен премией?
Второй вопрос частично связан с первым, но больше про HR-стратегию и привлечение новых сотрудников. В Бадушных официальных зарплатных вилках, которые можно встретить на сайтах по поиску работы (и даже на хабре), указываются верхние границы, существенно превышающие среднерыночтные. Но вместе с информацией из доклада про ревью складывается впечатление, что обязательная зарплатная часть существенно ниже нижней границы вилки, а верхняя граница вилки актуальна для очень маленького процента сотрудников и далеко не каждый месяц, и только при условии максимальной оценки на ревью. Часто встречал мнение (как HR-персонала, так и менежеров и разработчиков), что на самом деле для большинства сотрудников вилка по факту меньше, с учётом результатов ревью. Многие относятся с недоверием к официальной вилке. Так вот вопрос — насколько она верна для существующих сотрудников, насколько это честная цифра?
Третий вопрос про тимлидов. Не секрет, что в разных компаниях очень сильно различаются обязанности тимлидов, а так же различается количество уровней IT-шной иерархии управления. Иногда над тим-лидом уже CEO, а иногда ещё три уровня технических управленцев. Иногда тимлиды програмирут 90% времени и по сути больше похожи на ведущих разработчиков, а иногда совсем не программируют, а управляют командой из 15-20 человек. Например, существует мнение, что при команде в 6-8 человек на программирование времени не остаётся. В некоторых компаниях тимлиды отвечают за продуктовую часть, у них свои бизнесовые KPI, а в других ответственность ограничена исключительно качеством кода команды. В некоторых — у тимлида в подчинении кроссфункциональная команда, состоящая как из серверсайд разработчиков, так и клиентсайд разработчиков, тестеровщиков, админов, техписателей и так далее, в то время как в других компаниях у серверсайд тимлиодов в подчинении исключительно серверсайд разработчики. Расскажите, пожалуйста, какой процент времени тимлиды в Баду тратят на непосредтсвенное программирование, как этот процент времени зависит от размера команды, какие у них KPI и входят ли в них бизнесовые и продуктовые показатели, могут ли быть в одной команде и серверсайд и клиентсайд разработчики в подчинении у одномго тимлида, какого размера команды, и какой дальнейший путь развития тимлидов в Баду, кто ими руководит и за что он отвечает?
http://jsonapi.org/format/#fetching-sparse-fieldsets (можно указывать, какие поля возвращать)
http://jsonapi.org/format/#fetching-includes (можно указывать связанные ресурсы, и т.д.)
Есть ещё одна отличная конференция, которая традиционно проходит в первой половине года — https://dddeurope.com/ К сожалению, она проходит в январе, поэтому попасть на неё можно будет видимо только первой половине следующего года. Уровень конференции довольно высокий, и материал будет полезен широкому спектру разработчиков. Видео материалы всех выступлений выкладывают оперативно, и со всеми ними можно ознакомиться на сайте, чтобы самостоятельно составить впечатление о качестве конференции.
Рекомендую.
В следующий раз будут готовить и проверять текст комментария отдельно до публикации.
> а комментарии в tarantool
читать «а лайки — в tarantool»
так как нет абстрактной формулы масштабируемости, а всё
зависит от конкретной задачи, предметной области,
безнес-требований, выбранного решения и архитектуры.
Разделение монолита на части не обязательно будет способствовать
масштабированию.
1) И это связано с накладными расходами на взаимодействие между
получившимися частями. Чем интенсивнее взаимодействие, объём
трафика, количество запросов, тем медленнее будет работать
система после разделения на части. Отчасти это зависит от
архитектуры, которая получится в результате. Тесно связанные
между собой части будет сложнее разделить на отдельные сервисы.
2) Так же это связано с потерей возможности низкоуровневых
оптимизаций. В монолитном решении можно сделать более эффективные
оптимизации. Например можно сделать JOIN двух больших mysql таблиц,
вместо того, чтобы делать несколько запросов.
3) Накладные расходы на межсерверное взаимодействие. Если данные
лежат на одном сервере, или вообще в оперативной памяти одного и
того же процесса, то получить такие данные можно быстрее, чем из
оперативной памяти других серверов, к которым нужно ещё сделать
сетевые запросы.
Однако не всё так плохо. В самом общем случае довольно легко
доказать, что разделение будет способствовать масштабируемости.
Чем больше и монолитнее система, тем она более требовательна
к ресурсам. Кроме того, такая система ещё более сложная в плане
поддержки. Такую систему сложнее дорабатывать и внедрять новый
функционал. Обычно такие системы плохо держат высокую нагрузку.
Если же разделить систему на более мелкие независимые части,
то появится возможность разместить отдельные части на разных
серверах. Это значит, что нагрузка, создаваемая каждой частью,
должна быть меньше, а следовательно и требовательность к ресурсам
будет ниже у каждой из таких частей (хотя суммарная нагрузка,
создаваемая всеми составными частями может быть выше). Кроме того,
более простой сервис проще масштабировать, чем более сложный сервис.
Это интуитивно понятно, чем проще компонент, тем удобнее с ним
работать, проще поддерживать, изменять, дорабатывать, и конечно
масштабировать, так как для масштабирования придётся вносить
изменения в копмонент. В более простом компоненте меньше
составных частей, и с точки зрения управления сложностью
разработки такие части предпочтительнее в сложных сервисах.
Проще понять внутреннее устройство и внутреннюю логику работы,
понять где и во что может упираться производительность, и
сделать правильное предположение для рефакторинга в сторону
поддержки масштабирования.
Например если сервис использует две больших MYSQL таблицы с
JOIN запросом, и для масштабирования потребуется шардинг, то
из-за этого JOIN запроса шардить просто так не получится. Можно
расшардить самую большую таблицу, а таблицу поменьше реплицировать
на все шарды, чтобы JOIN запрос всё ещё мог выполнятся. Но это
поможет до тех пор, пока не возникнут проблемы и со второй
таблицей. Поэтому с точки зрения именно масштабирования имеет
смысл отказаться от JOIN запроса, и использовать например
последовательные запросы. В этом случае может появиться
возможность каждую из двух больших таблиц масштабировать
отдельно, для каждой сделав шардинг. Одну таблицу
масштабировать проще, чем две связанных JOIN-ом.
Кроме того, для более простого сервис проще рассчитать
математически и аналитически ту нагрузку, которую он
сможет выдержать. Зная внутреннюю архитектуру и бизнес-логику
сервиса можно связать количество запросов от клиентов
(внешние сервисы, которые запрашивают данные) с запросами на
бекенд и хранилище (допустим та же mysql), и спрогнозировать
рост нагрузки на хранилище (количества разных типов запросов,
количество обрабатываемых данных, общий размер данных) с ростом
входящих внешних запросов. Рост нагрузки на бекенд и хранилище
будет более линейным и предсказуемым в более простых системах.
В общем случае решение формализовать довольно сложно, так как
слишком много будет независимых переменных, и чем сложнее и больше
сам сервис, тем больше их будет, и тем сложнее сами эти переменные
выявить. Теоретических методики формальной оценки любого по
сложности сервиса мне не известны. Но на практике обычно всё
гораздо проще. Нужно всего-лишь понять архитектуру существующего
сервиса, нарисовать схему, выделить более менее отдельные и
независимые внутренние компоненты, понять взаимодействие между
ними, и какой эффект они оказывают с точки зрения нагрузки на
процессор, память, нижестоящие внешние сервисы, хранилище, базу
данных и так далее. Дальше останется понять, как можно разделить
сервис так, чтобы максимально нагруженные части можно было вынести
на отдельные сервера, учитывая количество и качество связей между
составными частями. Чащей всего для этого нужно пересмотреть
архитектуру всего решения с функциональной точки зрения, чтобы
получившиеся компоненты были законченными по смыслу и логичными,
чтобы все тесно связанные между собой данные принадлежали бы
одному и тому же компоненту, а между разными компонентами связей
было бы сильно меньше. Для новой же архитектуры нарисовать все
связи, количество запросов между ними, их типы, объёмы данных и
так далее. Чем проще будут отдельные и независимые, но законченных
с точки зрения бизнес-логики компоненты, тем проще будет
предсказать или посчитать создаваемую ими нагрузку, и тем
проще будет придумать как их масштабирвоать при необходимости.
Например если взять сервис, который работает с двумя большими
таблицами MYSQL и использует JOIN, например модуль комментариев
к статье на сайте с возможностью лайка и дизлайка каждого комментария,
то разделив этот сервис на два (один работает непосредственно
с комментариями, а другой обрабатывает лайки и дизлайки), можно
каждый из них поместить в своё собственное, более подходящее под
нагрузку хранилище, например комментарии положить в nosql mongodb
какой-нибудь, а комментарии в tarantool, прикинув по нагрузке,
что лайкают и дизлайкают чаще, чем пишут и редактируют комментарии.
http://www.banggood.com/4WD-WIFI-Crosscountry-Offroad-Robot-Smart-Car-Kit-For-Arduino-p-927973.html
Про третье правило забыли :)
Я долго искал различные workshop'ы на тему fpga, но реально полезных статей и видео по этой теме в разы меньше, чем по теме микроконтроллеров. Поэтому найденные мной ссылки считаю пригодятся.
Вот тут небольшой обзор платы latice iCEstick iCE40HX1K (low cost fpga dev board, $22, ~1000 логических элементов), обзор verilog под простую задачу реализации сумматора на этом fpga, и обзор набора opensource инструментов для сборки и прошивки этой платы.
http://hackaday.com/2015/08/19/learning-verilog-on-a-25-fpga-part-i/
http://hackaday.com/2015/08/20/learning-verilog-for-fpgas-flip-flops/
http://hackaday.com/2015/08/27/learning-verilog-for-fpgas-hardware-at-last/
А так же решение задачи реализации PWM сигнала на этой же плате
http://hackaday.com/2015/12/16/taking-the-pulse-width-modulation-of-an-fpga/
http://hackaday.com/2015/12/17/pwm-on-the-lattice-icestick/
Не совсем так. Вы же в один архив все репозитории складываете? Так вот суть в том, что проще тогда даже в случае динамической машины достать предыдущий архив, и разархивировать его целиком, потом обновить существующие репозитории через remote update, и добавить новые через mirror, удалить ненужные, и опять заархивировать.
Я бы не рекомендовал использовать пароль от аккаунта для этого.
И в github и bitbucket можно добавить deployment key, который работает для read-only операций с репозиторием. С его помощью можно склонировать репозитории, но нельзя пушить и делать деструктивные действия.
С другой стороны, если сам список репозиториев в bb нельзя получить без пароля (не знаю, есть ли там oauth и т.п.), тогда это не так важно.
Ещё я бы рекомендовал хранить локальный кеш репозиториев, тоесть сохранять все репозитории с предыдущего бекапа. Это позволяло бы не делать каждый раз clone --mirror, а делать git remote update. Таким образом выкачивались бы каждый раз только новые коммиты и изменения в репозиториях, а не целиком все репозитории со всеми ветками с нуля. Для крупных репозиториев это работает существевнно быстрее.
В остальном нормальное решение, сам так делаю.