В прошлой статье мы разобрали, как писать сервер на gRPC. И протестировали его с помощью BloomRPC. Теперь, давайте разберем как пишется клиент. И попробуем отправлять запросы с клиента на сервер. Это будет наш первый шаг к созданию микросервисов на грпц.
В моем случае я использую многомодульный проект, но можно создать отдельный проект. Структура проекта будет примерно следующей:
Как уже известно, около 70 % отказов в приложениях происходят из-за изменений: развёртывания нового кода, применённых миграции в базе данных, изменения конфигурационных файлов и т.д. Остальные 30 % сбоев происходят в ходе работы приложения без прямого вмешательства разработчиков и системных администраторов: из-за проблем с сетью или дисками, возросшей нагрузки от пользователей, аварии в дата-центре. На первую группу мы можем повлиять с помощью управления изменениями и стратегии проведения этих изменений, а как повысить устойчивость к проблемам из второй группы, мы поговорим в этой статье.
Вы, наверное, в последнее время часто слышите о новых продуктах Сбера, со многими из них сталкиваетесь как клиенты.
А есть в Сбере крупные и сложные технологические проекты, которые напрямую не видны для клиентов, но от их запуска сильно зависит успех клиентских продуктов. Сложность связана с необходимостью трансформировать приложения, которые каждую секунду обеспечивают непрерывность текущего бизнеса Сбера, а масштаб обусловлен большим количеством функционала, который востребован 68 млн клиентов. В статье я расскажу об одном из таких очень больших изменений — запуске новой платформы для СберБанк Онлайн.
Фото Cenk Batuhan Özaltun, Unsplash.com
На конференции QCon в марте я рассказывал об эволюции распределённых систем в Kubernetes. Главный вопрос: что будет после микросервисов? У вас наверняка есть мнение на этот счет. У меня оно тоже есть. В конце вы узнаете, что я думаю. Но для начала давайте обсудим потребности распределённых систем. Как эти потребности развиваются с годами, начиная с монолитных приложений до Kubernetes и таких новых проектов, как Dapr, Istio, Knative, и как они меняют наши методы работы с распределёнными системами. Попробуем сделать несколько прогнозов на будущее.
Когда-то вы кодили на одном большом и могучем серваке, с кучей памяти и кучей процов. Сервер был безграничен, все ваши сервисы были здесь, все ваши Redis’ы и даже зачастую MySQL-и были тут. Все ваши приложения были здесь же: какая-то аналитика, какой-то бэкенд для админки, еще десяток сервисов — все было рядом.
Но вот вы заехали в Swarm. Все приложения — это набор контейнеров. А контейнеры это, по сути, набор микросерверов со своей файловой системой, своей памятью, своими процами. И они уже не всегда рядом. Соответственно, это тянет за собой некоторые изменения.
Из цикла "Микросервисы или смерть"
Решаемая проблема: монолитное приложение на Node.js раньше, в развернутом состоянии, занимало 0.2 Гб всего. Теперь же, разбитое на 33 микросервиса, занимает 33 * 0.1 = 3.3 Гб. Можно ли избежать подобной издержки? -- можно! В статье мы избавимся от лишнего веса.
Когда мы задались вопросом перехода на микросервисную архитектуру, мы столкнулись с некоторым количеством трейд-оффов. Проведя ряд экспериментов и отвязавшись от специфических для нашего продукта бизнес-требований, мы попытались сформулировать вопросы, которые могут встать перед любой командой разработки, безотносительно к требованиям к продукту. Ну и, конечно, дать на них ответы.
В качестве прикладного дополнения к рассуждениям мы разработали несколько Proof of Concept, сопроводили их разработку краткими пояснениями и приложили исходный код PoC.
Архитектура микросервисов — это методология, позволяющая разделить монолитное единое приложение на небольшие приложения и сервисы, которые выполняют легкие задачи. Бизнес-возможности и независимо развертываемые модели являются основными целями разработки микросервисов. Архитектура микросервисов построена с использованием различных языков программирования, они могут быть развернуты и соединены между собой.
В этой статье хочу рассказать о том, как я создавала сервис для распознавания эмоций на основе анализа записей деловых телефонных разговоров.
Привет, меня зовут Ваня, недавно я выступил на CodeFest 11, где рассказал про путь Тинькофф Бизнеса на фронтенде от одного приложения к сотне. Но, так как в ИT очень быстро все меняется, а ждать запись еще долго, сейчас я тезисно расскажу о нашем шестилетнем путешествии в дивный мир микрофронтенда!
При рефакторинге монолита на микросервисы часто мы уже обладаем работающей системой. У которой миллионы, тысячи активных пользователей. Возможно их 20, но они очень важные и очень активные. Как в таком случае отрефакторить все, чтобы внешне никто ничего не заметил? И как в этом поможет тропический фикус-душитель?
Архитектуры микросервисов продолжают развиваться в инженерных организациях, поскольку команды стремятся увеличить скорость разработки. Микросервисы продвигают идею модульности как объекты первого класса в распределенной архитектуре, обеспечивая параллельную разработку и компоненты с независимыми циклами выпуска. Как и при принятии любых технологических решений, необходимо учитывать компромиссы. В случае микросервисов они включают потенциальную потерю централизованных стандартов разработки, а также повышенную сложность эксплуатации.
К счастью, существуют стратегии решения этих проблем. Сначала мы рассмотрим рефакторинг сервиса на основе Kafka Streams с использованием Microservices Framework, который обеспечивает стандарты для тестирования, конфигурации и интеграции. Затем мы используем существующий проект streaming-ops для создания, проверки и продвижения нового сервиса из среды разработки в рабочую среду. Хотя это и не обязательно, но вы если хотите выполнить шаги, описанные в этой заметке, то вам понадобится собственная версия проекта streaming-ops, как описано в документации.
- Саш, админы говорят, что у нас 400 полетели адово. Глянь, в чем проблема.
- Странно… все же было хорошо.
Пару часов спустя...
- Коллеги, и в очередной раз у нас изменены контракты без согласования и оповещения! Это уже не первый случай!
Фото с сайта linkerd.io
Пару лет назад ребята из Kinvolk сравнили производительность Linkerd и Istio и узнали, что Linkerd значительно быстрее и меньше Istio везде, кроме одной области. Linkerd использовала больше процессорных ресурсов в плоскости данных (data plane). Недавно мы повторили эти эксперименты с последними версиями обеих service mesh. Как показывают результаты, Linkerd не только по-прежнему заметно быстрее Istio, но и использует на порядок меньше ресурсов памяти и процессора в плоскости данных (data plane). Причем это происходит, даже если число запросов в секунду в три с лишним раза больше, чем в бенчмарке Kinvolk. Вы легко можете это повторить.
А теперь подробности.
Однообразный код писать неинтересно, нудно, но приходится. Испокон веков изворотливые программисты ищут Святой Грааль формализма, позволяющего переложить рутинные задачи на машину, писать только раз и переиспользовать код. Так появились структурное программирование, потом объектно-ориентированное, полиморфизм с параметризованными типами, кодогенерация на основе формальных грамматик, препроцессоры макроязыка и прочее… Под катом рассмотрим, как обстоят дела именно в Go.
Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.
Мы расскажем о том, как можно разбить монолитное приложение на более мелкие части, составляющие модульную систему, и обсудим миграцию в облако.
Эта статья подводит итог вебинара "Разрушение монолита", представленного Даниэлем Гутьерресом Сааведрой, старшим инженером-программистом компании Zartis. Вы можете посмотреть полный текст вебинара, который также включает сессию вопросов и ответов, ниже!
Привет, самое хардовое IT комьюнити Рунета, я Саша, главный архитектор в компании Quadcode. Мы пришли на Хабр для того, чтобы показать “кухню” Fintech - варимся мы во всем этом много лет, поэтому уже можем поделиться опытом. В блоге будем рассказывать об архитектурах, технологиях, инструментах и лайфхаках - то, что может пригодиться и вам.
Этот пост - первый в списке, его можно считать знакомством. Под катом я расскажу про структуру нашей команды, про продукты Quadcode – это платформа для трейдинга, банкинг и внутренние разработки, а также про наши первые шаги на пути к IPO.
Наша команда
Команда Quadcode уже 8 лет работает в финтехе. Цель компании - создавать удобные финтех-инструменты для B2B клиентов со всего мира.
В разработке мы руководствуемся Agile принципами, да и в принципе склонны к гибким методологиям. Именно они позволяют достигать баланса в скорости и качестве разработки продуктов, поэтому разработка представляет из себя набор Scrum команд.
Во главе каждой команды стоит Team Lead. Сами команды сгруппированы в отделы работающие над определенными предметными областями. Например, есть отдел Finance Development, в котором команды разрабатывают финансовые сервисы для платформы. Есть ветка, где располагаются владельцы продукта (product owners), задача которых развивать и улучшать наши продукты. Сейчас у нас в разработке 230+ опытных (реально опытных, у каждого много лет практики) специалистов. Это порядка 24 команд и 6 Product Owners. Джуниоров мы берем редко. Но с каждым годом искать опытных специалистов становится все сложнее, так что все больше в эту сторону смотрим, но тут нужно все грамотно подготовить.
