Запилили разработчики госуслуг, а заслуга почему-то правозащитников. Интересно, а если правозащитник на stackoverflow за ответ проголосует и потом автор этот ответ примет как лучший, тоже будет новость и дифирамбы в честь правозащитников на хабре?
Это же skillfactory, они не шибко ценят глубину, качество или уровень конверсии в специалистов и работают на количество и конверсию денежную. Похоже на зарубежные кемпинги, где за 3 месяца человека учат кое-как программировать и хорошо скрывать это на собеседованиях.
Насчёт ACID транзакций вы правы, я ошибся на этот счёт. Хотя, конечно, поведение транзакций несколько отличается от SQL и не позволяет получить данные, принять решение, записать данные - такое, насколько мне известно, достижимо только через Redis Script.
Что касается "как и SQL": да, настройками Redis можно достичь тех же гарантий, что у MySQL, но это полностью уберёт преимущества в производительности, при этом Redis останется однопоточным, а MySQL - многопоточным.
Ну и кроме того, если мы превращаем Redis в однопоточный и ограниченный по функциональности аналог MySQL, то в чём смысл такой инсталяции Redis?
Если же не превращаем, то сказанное в статье верно.
И в любом случае, Redis в дополнение к основной БД - это новая точка отказа. Посыл статьи вовсе не в том, что Redis не надо использовать. Посыл в том, что использование должно быть оправдано, а реализация должна быть адекватной, если проекту важна отказоустойчивость.
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
В книге Clean Architecture речь идёт о крупномасштабной структуре программы, и на таком уровне модуль действительно может закрывать потребности одного actor (действующего лица):
A module should be responsible to one, and only one, actor
Если же речь идёт о внутренней структуре модуля, то здесь работает разделение по аспектам реализации. И, кстати, в формулировке 2014 года Роберт Мартин уже убрал единственное число и говорит об изменениях по схожим причинам:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
В такой формулировке выделение слоя для работы с SQL полностью соответствует SRP: у кода для работы с БД действительно все причины изменений схожи.
Ну и наконец, Роберт Мартин прямо пишет в Clean Architecture, что принцип SRP надо соблюдать примерно на 90%.
Так что не надо обесценивать SRP, и тем более не надо заменять его на "практические рекомендации", весьма спорные и выходящие из моды за несколько лет.
Может я чего-то не учитываю, но я не понимаю, зачем нужен blue/green, когда есть rolling update и staging окружение, близкое к production.
С канареечным понятно — позволяет подвергнуть риску регрессий лишь часть пользователей, и, если скорость реакции на инциденты у разработчиков высокая, а период до полного выката достаточен, то снизит риски.
А что такого несёт blue/green — не понимаю. Разве что как костыль для сокращения периода одновременной работы двух версий (то есть как "антиканареечный" деплой)
Ходили слухи о проблемах в октябре сразу у многих облачных провайдеров — netrack, croc, selectel и других.
Но при этом у Amazon всё стабильно в порядке, с начала пандемии.
Всё-таки дело не только и не столько в переводе инженеров на удалёнку.
P.S. Нагрузка на сеть везде есть, весной были проблемы с каналом из России в Европу, сейчас есть проблемы со скоростью серверов в США из арабских стран. Но справляются все по-разному.
Почему решили с MySQL переходить на PostgreSQL? Были ли трудности при внедрении в новых сервисах PostgreSQL?
Запись в микросервис, абстрагирующий Kafka, выполняется напрямую или через базу и Transactional Outbox?
Базы данных и Kafka развёрнуты вне Kubernetes? Есть ли ситуации, когда одна машина с инстансами БД или один инстанс БД с разными database используется несколькими микросервисами?
Если будет запрет на использование американских технологий, то из AppStore и GooglePlay уберут насовсем, не только на территории США.
Huawei, например, использовать приложения гугла не может нигде.
"Яндекс сливал данные" — это такое народное поверье, или есть доказательства?
Уточню, что речь не о выдаче данных в пределах юрисдикции страны — таким-то и Google регулярно занимается, причём во всех странах и в США прежде всего.
Но секундочку, речь вообще-то о том, что VK встал в защиту (в данном случае украинских) пользователей от российских судебных решений в 2014 году, и ваш комментарий лишь больше подтверждает мои слова — потому что реакцией VK на уголовные дела по репостам стало скрытие списка репостов.
Речь о тех, кто вводил запреты и нагнетал истерию — в основном про период между Януковичем и Зеленским, конечно.
Правда, внедрённые в тот период запреты и сейчас никуда не делись, так что власть не то что бы прямо сильно сменилась. Запрет на ряд российских сервисов продлили недавно, да и с незапрещёнными украинский бизнес не особо желает теперь связываться, именно из-за политики запретов и поддержки её со стороны СБУ.
С чего вдруг такое будет в московских офисах?
Давайте, кстати, вспомним, что первыми на Яндекс набросились украинские власти — заблокировали счета, так что даже зарплаты нельзя было выплатить. Исполнили давнюю мечту националистов — "вiдсечь" всё русское.
Удивляет, что на хабре сравнивают события в Беларусь с Россией, учитывая, что по нетерпимости к оппонентам Лукашенко больше похож на новые украинские власти, которые запретили КПУ, запретили российские телеканалы, запретили популярные российские сервисы (несмотря на то, что тот же VK прямо отказался выдавать что-либо ФСБ или блокировать группы по решению российского суда).
Не сравнивайте, пожалуйста, с современной Россией, уймите свои фобии. У нас что-то подобное было лишь в 1993м году.
На github в поиске по запросу golang scratch docker в топе сразу два примера, где данные о timezone добавляются в контейнер.
А все статьи по этой теме, к сожалению, поверхностные: я не видел упоминаний timezone, не всегда предлагается менять пользователя с root на ограниченного, в этой статье (не в вину переводчику, конечно) ещё и про multi-stage builds не сказано ничего.
Не видим причин логировать в доменном слое. Любые действия сервиса проявляются в пакетах, участвующих в вводе и выводе, будь то API сервиса, слой работы с БД, публикация сообщений или прямое взаимодействие с другими сервисами. То есть можно логировать на уровне infrastructure.
Если потребуется особое ведение логов со слоя app — то скорее всего добавим интерфейс, и реализуем его на уровне infrastructure. И назовём без слова log, например, ActionReporter.
Я так сделал в консольной утилите — на уровне app используется интерфейс Reporter, где каждый метод сообщает одну конкретную вещь (например, метод WarnBadCommit пишет о "плохом" коммите git, вызывается раза 3 с разными текстами). На уровне infrastructure пакет console объявляет структуру console.reporter и функцию console.NewReporter. Структура реализует запись в консоль — через logrus в моём случае, я использовал logrus для форматирования вывода в консоль, абстракцию log.Logger не применял т.к. вывод консольной утилиты — это не логирование.
Если именно со слоя domain — то лучше будет в domain только порождать доменные события и отправлять их в какой-нибудь интерфейс EventDispatcher, а уже в реализации интерфейса на уровне infrastructure (может быть в Middleware) логировать.
Это моё мнение по задаче, которую я на практике не решал, могут быть и другие пути решения.
Не соглашусь. В статье Clean Architecture есть ссылка на статью Hexagonl Architecture (статья уже недоступна, смотрел на archive.org). В статье про Hexagonal Architecture нет конкретных правил именования, там вообще нет привязки к языкам программирования. При реализации Hexagonal Architecture, Clean Architecture, DDD и других решений команды либо просто не понимают и игнорируют правила, о которых они вроде как читали (такое приходилось видеть :D), либо у них возникает очень много практических вопросов, на которые первоисточник ответа не даёт (или даёт, но абстрактный, на уровне требований).
В итоге люди сами выбирают, как решать конкретные вопросы, соблюдая Hexagonal Architecture, Clean Achitecture и другие подходы. Где-то идут на компромиссы, где-то смотрят на опыт других, где-то изобретают сами. Примеров много на github: roblaszczak/go-cleanarch, apavamontri/nodejs-clean, CodelyTV/cqrs-ddd-php-example.
Кстати, есть пример с кричащими названиями всех пакетов: AkbaraliShaikh/denti. Мы так тоже пробовали когда-то, и отказались: да, все пакеты кричат о своём назначении, но они все свалены в кучу независимо от уровня — визуально трудно отделить более важные пакеты бизнес-логики от менее важных пакетов более близкого к вводу-выводу уровня.
2) Роберт Мартин пишет абстрактно, у него нет конкретных правил по именованию пакетов Go, есть абстрактный совет по именованию компонентов приложения: при чтении кода должно быть понятно, что это такое. Наша команда опробовала несколько вариантов и в итоге пришла к тому, что "кричащее" название имеет компонент верхнего уровня, а внутри него уже находятся каталоги "app", "domain", "infrastructure". Поскольку infrastructure скрывает за собой несколько вещей, внутри него есть пакеты с кричащими названиями — но эти названия кричат о технологиях, поскольку о своём назначении инфраструктурный пакет ничего не знает (он реализует интерфейс, не особо зная, как им пользуются). В примере компонент верхнего уровня один — "cooking", также мы вводим компонент "common" где, например, размещается инфраструктурный код для подключения к БД. В простых микросервисах, выполняющих одну задачу, так и остаётся один компонент. В более сложных сервисах — компонентов может быть много, их названия говорят об их назначении.
Есть идея у меня лично transport переименовать в grpc. Что касается логирования и обработки ошибок — у нас это делается как Middleware, реализующий интерфейс, сгенерированный из proto-файла GRPC-плагином для protoc. Так что выделять их в другой пакет нет особого смысла, эти Middleware завязаны на GRPC.
От именования пакетов способность кода "кричать" о своём назначении не страдает — новичок обычно читает код, начиная с main, и там импортируется пакет .../pkg/cooking/app, в пути к которому есть строка, описывающее назначение. Прямо в main вызывается NewLoggingMiddleware или NewErrorHandlingMiddleware, где название опять же говорит о назначении middleware.
Запилили разработчики госуслуг, а заслуга почему-то правозащитников. Интересно, а если правозащитник на stackoverflow за ответ проголосует и потом автор этот ответ примет как лучший, тоже будет новость и дифирамбы в честь правозащитников на хабре?
Это же skillfactory, они не шибко ценят глубину, качество или уровень конверсии в специалистов и работают на количество и конверсию денежную. Похоже на зарубежные кемпинги, где за 3 месяца человека учат кое-как программировать и хорошо скрывать это на собеседованиях.
Насчёт ACID транзакций вы правы, я ошибся на этот счёт. Хотя, конечно, поведение транзакций несколько отличается от SQL и не позволяет получить данные, принять решение, записать данные - такое, насколько мне известно, достижимо только через Redis Script.
Что касается "как и SQL": да, настройками Redis можно достичь тех же гарантий, что у MySQL, но это полностью уберёт преимущества в производительности, при этом Redis останется однопоточным, а MySQL - многопоточным.
Ну и кроме того, если мы превращаем Redis в однопоточный и ограниченный по функциональности аналог MySQL, то в чём смысл такой инсталяции Redis?
Если же не превращаем, то сказанное в статье верно.
И в любом случае, Redis в дополнение к основной БД - это новая точка отказа. Посыл статьи вовсе не в том, что Redis не надо использовать. Посыл в том, что использование должно быть оправдано, а реализация должна быть адекватной, если проекту важна отказоустойчивость.
Анекдот неприличный, вряд ли я могу цитировать его на хабре. Предлагаю в яндексе набрать "мужик сено скафандр" :)
И, кстати, actor и stakeholder - разные вещи, почему автор решил, что можно одно заменить на другое, не будучи при этом носителем английского языка?
Разница объясняется, например, здесь: http://fserranocs460.blogspot.com/2014/01/use-cases-actors-vs-stakeholders.html
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
В книге Clean Architecture речь идёт о крупномасштабной структуре программы, и на таком уровне модуль действительно может закрывать потребности одного actor (действующего лица):
Если же речь идёт о внутренней структуре модуля, то здесь работает разделение по аспектам реализации. И, кстати, в формулировке 2014 года Роберт Мартин уже убрал единственное число и говорит об изменениях по схожим причинам:
В такой формулировке выделение слоя для работы с SQL полностью соответствует SRP: у кода для работы с БД действительно все причины изменений схожи.
Ну и наконец, Роберт Мартин прямо пишет в Clean Architecture, что принцип SRP надо соблюдать примерно на 90%.
Так что не надо обесценивать SRP, и тем более не надо заменять его на "практические рекомендации", весьма спорные и выходящие из моды за несколько лет.
Может я чего-то не учитываю, но я не понимаю, зачем нужен blue/green, когда есть rolling update и staging окружение, близкое к production.
С канареечным понятно — позволяет подвергнуть риску регрессий лишь часть пользователей, и, если скорость реакции на инциденты у разработчиков высокая, а период до полного выката достаточен, то снизит риски.
А что такого несёт blue/green — не понимаю. Разве что как костыль для сокращения периода одновременной работы двух версий (то есть как "антиканареечный" деплой)
Ходили слухи о проблемах в октябре сразу у многих облачных провайдеров — netrack, croc, selectel и других.
Но при этом у Amazon всё стабильно в порядке, с начала пандемии.
Всё-таки дело не только и не столько в переводе инженеров на удалёнку.
P.S. Нагрузка на сеть везде есть, весной были проблемы с каналом из России в Европу, сейчас есть проблемы со скоростью серверов в США из арабских стран. Но справляются все по-разному.
Спасибо за статью, хотелось бы ещё узнать
Если будет запрет на использование американских технологий, то из AppStore и GooglePlay уберут насовсем, не только на территории США.
Huawei, например, использовать приложения гугла не может нигде.
Как мне кажется, договариваться будут, но сильно позже и уже без участия США. Там, где штаты имеют влияние, Китай едва ли пустят — как уже было с МКС.
"Яндекс сливал данные" — это такое народное поверье, или есть доказательства?
Уточню, что речь не о выдаче данных в пределах юрисдикции страны — таким-то и Google регулярно занимается, причём во всех странах и в США прежде всего.
Но секундочку, речь вообще-то о том, что VK встал в защиту (в данном случае украинских) пользователей от российских судебных решений в 2014 году, и ваш комментарий лишь больше подтверждает мои слова — потому что реакцией VK на уголовные дела по репостам стало скрытие списка репостов.
Речь о тех, кто вводил запреты и нагнетал истерию — в основном про период между Януковичем и Зеленским, конечно.
Правда, внедрённые в тот период запреты и сейчас никуда не делись, так что власть не то что бы прямо сильно сменилась. Запрет на ряд российских сервисов продлили недавно, да и с незапрещёнными украинский бизнес не особо желает теперь связываться, именно из-за политики запретов и поддержки её со стороны СБУ.
С чего вдруг такое будет в московских офисах?
Давайте, кстати, вспомним, что первыми на Яндекс набросились украинские власти — заблокировали счета, так что даже зарплаты нельзя было выплатить. Исполнили давнюю мечту националистов — "вiдсечь" всё русское.
Удивляет, что на хабре сравнивают события в Беларусь с Россией, учитывая, что по нетерпимости к оппонентам Лукашенко больше похож на новые украинские власти, которые запретили КПУ, запретили российские телеканалы, запретили популярные российские сервисы (несмотря на то, что тот же VK прямо отказался выдавать что-либо ФСБ или блокировать группы по решению российского суда).
Не сравнивайте, пожалуйста, с современной Россией, уймите свои фобии. У нас что-то подобное было лишь в 1993м году.
На github в поиске по запросу golang scratch docker в топе сразу два примера, где данные о timezone добавляются в контейнер.
А все статьи по этой теме, к сожалению, поверхностные: я не видел упоминаний timezone, не всегда предлагается менять пользователя с root на ограниченного, в этой статье (не в вину переводчику, конечно) ещё и про multi-stage builds не сказано ничего.
Не видим причин логировать в доменном слое. Любые действия сервиса проявляются в пакетах, участвующих в вводе и выводе, будь то API сервиса, слой работы с БД, публикация сообщений или прямое взаимодействие с другими сервисами. То есть можно логировать на уровне infrastructure.
Если потребуется особое ведение логов со слоя app — то скорее всего добавим интерфейс, и реализуем его на уровне infrastructure. И назовём без слова log, например, ActionReporter.
Я так сделал в консольной утилите — на уровне app используется интерфейс Reporter, где каждый метод сообщает одну конкретную вещь (например, метод WarnBadCommit пишет о "плохом" коммите git, вызывается раза 3 с разными текстами). На уровне infrastructure пакет console объявляет структуру console.reporter и функцию console.NewReporter. Структура реализует запись в консоль — через logrus в моём случае, я использовал logrus для форматирования вывода в консоль, абстракцию log.Logger не применял т.к. вывод консольной утилиты — это не логирование.
Если именно со слоя domain — то лучше будет в domain только порождать доменные события и отправлять их в какой-нибудь интерфейс EventDispatcher, а уже в реализации интерфейса на уровне infrastructure (может быть в Middleware) логировать.
Это моё мнение по задаче, которую я на практике не решал, могут быть и другие пути решения.
А как строите развёртывание и масштабируете разработку без контейнеров? Какие потребности и какие решения?
Не соглашусь. В статье Clean Architecture есть ссылка на статью Hexagonl Architecture (статья уже недоступна, смотрел на archive.org). В статье про Hexagonal Architecture нет конкретных правил именования, там вообще нет привязки к языкам программирования. При реализации Hexagonal Architecture, Clean Architecture, DDD и других решений команды либо просто не понимают и игнорируют правила, о которых они вроде как читали (такое приходилось видеть :D), либо у них возникает очень много практических вопросов, на которые первоисточник ответа не даёт (или даёт, но абстрактный, на уровне требований).
В итоге люди сами выбирают, как решать конкретные вопросы, соблюдая Hexagonal Architecture, Clean Achitecture и другие подходы. Где-то идут на компромиссы, где-то смотрят на опыт других, где-то изобретают сами. Примеров много на github: roblaszczak/go-cleanarch, apavamontri/nodejs-clean, CodelyTV/cqrs-ddd-php-example.
Кстати, есть пример с кричащими названиями всех пакетов: AkbaraliShaikh/denti. Мы так тоже пробовали когда-то, и отказались: да, все пакеты кричат о своём назначении, но они все свалены в кучу независимо от уровня — визуально трудно отделить более важные пакеты бизнес-логики от менее важных пакетов более близкого к вводу-выводу уровня.
2) Роберт Мартин пишет абстрактно, у него нет конкретных правил по именованию пакетов Go, есть абстрактный совет по именованию компонентов приложения: при чтении кода должно быть понятно, что это такое. Наша команда опробовала несколько вариантов и в итоге пришла к тому, что "кричащее" название имеет компонент верхнего уровня, а внутри него уже находятся каталоги "app", "domain", "infrastructure". Поскольку infrastructure скрывает за собой несколько вещей, внутри него есть пакеты с кричащими названиями — но эти названия кричат о технологиях, поскольку о своём назначении инфраструктурный пакет ничего не знает (он реализует интерфейс, не особо зная, как им пользуются). В примере компонент верхнего уровня один — "cooking", также мы вводим компонент "common" где, например, размещается инфраструктурный код для подключения к БД. В простых микросервисах, выполняющих одну задачу, так и остаётся один компонент. В более сложных сервисах — компонентов может быть много, их названия говорят об их назначении.
Есть идея у меня лично transport переименовать в grpc. Что касается логирования и обработки ошибок — у нас это делается как Middleware, реализующий интерфейс, сгенерированный из proto-файла GRPC-плагином для protoc. Так что выделять их в другой пакет нет особого смысла, эти Middleware завязаны на GRPC.
От именования пакетов способность кода "кричать" о своём назначении не страдает — новичок обычно читает код, начиная с main, и там импортируется пакет
.../pkg/cooking/app, в пути к которому есть строка, описывающее назначение. Прямо в main вызываетсяNewLoggingMiddlewareилиNewErrorHandlingMiddleware, где название опять же говорит о назначении middleware.