Проверка данных класса (bean) в java тема не новая, но актуальная и здесь я объединю различные аспекты: валидацию данных в рамках JSR-303, покажу как это сделать чисто в Java и с использованием Spring, как делать в стандартном приложении и в Web.

Содержание: Валидация данных (JSR-303) в

• стандартном Java приложении
• c использованием Spring
• объединение Java + Spring
• Spring MVC

Привет! Меня зовут Константин Евтеев, я работаю в Авито руководителем юнита DBA. Наша команда развивает системы хранения данных Авито, помогает в выборе или выдаче баз данных и сопутствующей инфраструктуры, поддерживает Service Level Objective для серверов баз данных, а еще мы отвечаем за эффективность использования ресурсов и мониторинг, консультируем по проектированию, а возможно и разрабатываем микросервисы, сильно завязанные на системы хранения, или сервисы для развития платформы в контексте хранилищ.

Я хочу рассказать, как мы решили один из вызовов микросервисной архитектуры — проведение бизнес-транзакций в инфраструктуре сервисов, построенных с помощью паттерна Database per service. С докладом на эту тему я выступал на конференции Highload++ Siberia 2018.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).

Anthony Smith Images / Shutterstock.com

Мы создаём Kubernetes как облачный сервис и пристально следим за актуальными инструментами разработчиков контейнерных приложений. В этом посте мы расскажем про инструменты, которые сильно облегчают работу с развёртываниями Kubernetes и помогают построить CI/CD.

Введение в микросервисную архитектуру

Часть 1 из 10

Адаптация статей Ewan Valentine.

Это серия из десяти частей, я постараюсь раз в месяц писать про построение микросервисов на Golang. Я буду использовать protobuf и gRPC в качестве основного транспортного протокола.

Стек, который я использовал: golang, mongodb, grpc, docker, Google Cloud, Kubernetes, NATS, CircleCI, Terraform и go-micro.

Зачем мне это? Поскольку мне потребовалось много времени, чтобы разобраться в этом и решить накопившиеся проблемы. Так же я хотел поделиться с вами тем, что я узнал о создании, тестировании и развертывании микросервисов на Go и другие новые технологии.

В этой части, я хочу показать основные концепции и технологии для построения микросервисов. Напишем простую реализацию. В проекте будут следующие сущности:

• грузы
• инвентарь
• суда
• пользователи
• роли
• аутентификация

Выбор подходящей архитектуры — ключевая часть построения фронтенда сервиса. Разработчик Анна Карпелевич рассказала студентам Школы разработки интерфейсов, что такое архитектура, какие функции она выполняет и какие проблемы решает. Из лекции можно узнать о наиболее популярных архитектурных подходах во фронтенде: Model-View-* и Flux.


— Добрый вечер. Меня зовут Аня Карпелевич. Мы сегодня с вами будем говорить про архитектуру фронтенда верхнего уровня.

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

С этого момента вам больше не придется думать об установке ОС и отдельных пакетов на каждую ноду. Зачем? Вы можете сделать все это автоматически через Dockerfile!

Тот факт что вы можете купить сотню новых серверов, добавить их в рабочее окружение и почти моментально получить их готовыми к использованию — это действительно потрясающе!

Заинтриговал? Теперь давайте обо всем по порядку.

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

Руководство организовано как последовательность шагов — выбор архитектуры → выбор технологий для вычисления и хранения данных → проектирование приложения Azure → выбор шаблонов → проверка архитектуры. Для каждого из них приведены рекомендации, которые помогут вам при разработке архитектуры приложения.

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

Прим. перев.: Автор оригинальной статьи — Théo Chamley, архитектор облачных решений Google. В этой публикации для блога Google Cloud он представил краткую выжимку из более детального руководства его компании, названного «Best Practices for Operating Containers». В нём специалисты Google собрали лучшие практики по эксплуатации контейнеров в контексте использования Google Kubernetes Engine и не только, затронув широкий спектр тем: от безопасности до мониторинга и журналирования. Итак, какие практики в работе с контейнерами наиболее важны по мнению Google?

Алхимиками двигало примерно то же, что и современными учёными — им хотелось понять, как устроен мир. Они изучали это как могли. Позже древние протонауки эволюционировали до современного состояния наук.

Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 21 веке двигало …» и «… понять, как устроено предприятие».

На страницах ИТ-интернета тема Enterprise Architecture (ЕА) — одна из популярнейших. Она дает возможность поговорить о «высоком», — об «архитектурном» подходе, десятках framework, почувствовать себя Архитектором «с большой буквы».

Пишут многие и пишут много. Читатели статей «Архитектура предприятия» одобрительно кивают, восхищаясь … «платьем короля». На «благодатной почве» ЕА развелись всевозможные «архитекторы».

Книги, учебные дисциплины, консалтинговые проекты, группы, консорциумы, целые институты со специализацией ЕА (IFEAD, iEAi и др.), глобальные организации (GEAO), одноименные журналы (Journal of Enterprise Architecture), международные стандарты (ISO 15704, 42010 и др.) и прочее — прочее.

Тем не менее, в контексте ЕА, остаются вопросы: что такое «архитектура», что такое «предприятие» и что такое «архитектура предприятия», а также — кто главный потребитель ЕА и почему конкретных примеров этой самой ЕА нигде нет.

Методик, эталонных моделей и архитектурных фреймворков (обычно с окончанием на «AF»: FEAF, TEAF, DoDAF и т.п.) — «как грязи», а реальных результатов посмотреть негде.

Да-да, ключевая особенность этого направления: нет ни одного конкретного полного примера этой самой загадочной enterprise architecture в открытом доступе.

Архитекторы говорят, что это NDA, «большой секрет», ДСП (возможно даже «гос-тайна»). Но как вообще «архитектура» может быть секретной? На то она и «архитектура», чтобы быть узнаваемой: различимой и сопоставимой. А вот «Алхимия предприятия» — как раз и должна держаться в строгом секрете.

Моя история не для всех. В том смысле, что тема не хайповая. Но тем, кто в теме, надеюсь, будет интересно. Она (история) основана на реальном опыте последних лет. Я расскажу об одном из вариантов — с моей точки зрения, эффективном, — управления сложным архитектурным ландшафтом.

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

Как вы уже догадались из названия статьи, сегодня речь пойдет о самом популярном, разве что после Singleton, шаблоне проектирования MVC, хотя такое сравнение не совсем уместно. Понимание концепции MVC может помочь вам в рефакторинге и разрешении неприятных ситуаций в которые, возможно попал ваш проект. Дабы восполнить пробел, мы реализуем шаблон MVC на примере простого сайта-визитки.

Есть множество типов архитектур ПО со своими плюсами и минусами. Далее поговорим об особенностях наиболее популярных из них и расскажем о своем переходе на микросервисы.

В ходе рефакторинга нашей криптобиржи, было решено пересмотреть концепцию работы с маркет-датой. В классическом случае маркет-дата распространяется двумя методами:

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

Также требуется создать высокодоступную инфраструктуру, реализовать такие мелочи как CI/CD для сервисов, обеспечить все это нужными спецами по разработке, сопровождению, и т.д., и т.п.

(Иллюстрация)

Одна из задач, с которой сталкиваются 99,9% разработчиков, — это обращение к сторонним endpoint’ам. Это могут быть как внешние API, так и «свои» микросервисы. Сейчас все и вся бьют на микросервисы, да. Получить или отправить данные просто, но иногда изобретают велосипеды. Можете назвать 5 способов реализации запросов на Java (c использованием библиотек и без)? Нет — добро пожаловать под кат. Да? Заходите и сравните ;)

Небольшой рассказ о преимуществах и недостатках микросервисов, концепции Service Mesh и инструментах Google, позволяющих запускать микросервисные приложения не засоряя голову бесконечными настройками политик, доступов и сертификатов и быстро находить ошибки, прячущиеся не в коде, а в микросервисной логике.



В основе статьи — доклад Крейга Бокса на нашей прошлогодней конференции DevOops 2017. Видео и перевод доклада — под катом.

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

Ниже мы рассмотрим реальные примеры из жизни и попытаемся научиться на чужих ошибках. А попутно составим книгу полезных рекомендаций для solution-архитектора. Во всех историях — архитектурные задачи, которые начинаются с первичных требований клиента и сопровождаются дальнейшим разбором полетов.



В основе статьи — доклад Алексея Богачука (solution-архитектора компании EPAM) с конференции HolyJS 2018 Piter. Под катом — видео и расшифровка доклада.

В этой статье расскажем о том, как и для чего мы разработали Систему Взаимодействия – механизм, передающий информацию между клиентскими приложениями и серверами 1С:Предприятия – от постановки задачи до продумывания архитектуры и деталей реализации.

Система Взаимодействия (далее – СВ) – это распределенная отказоустойчивая система обмена сообщениями с гарантированной доставкой. СВ спроектирован как высоконагруженный сервис с высокой масштабируемостью, доступен и как онлайновый сервис(предоставляется фирмой 1С), и как тиражный продукт, который можно развернуть на своих серверных мощностях.

СВ использует распределенное хранилище Hazelcast и поисковую систему Elasticsearch. Еще речь пойдет о Java и о том, как мы горизонтально масштабируем PostgreSQL.

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.