Автор | Ван Шу

Что такое микросервисы

Микросервисы — это архитектурный стиль, в котором большое сложное программное приложение состоит из одного или нескольких микросервисов. Каждая микрослужба в системе может быть развернута независимо, и каждая микрослужба слабо связана. Каждый микросервис фокусируется только на выполнении одной задачи и делает ее хорошо. Во всех случаях каждая задача представляет собой возможность малого бизнеса. Концепция микросервисов возникла из статьи «Микросервисы», написанной Мартином Фаулером в марте 2014 года (http://martinfowler.com/articles/microservices.html).

Хотя точного определения архитектурного стиля «микросервисов» не существует, он имеет некоторые общие характеристики, такие как организация служб с учетом бизнес-возможностей, автоматическое развертывание, интеллектуальные конечные точки, «децентрализованный» контроль над языком и данными и т. д. Представление об архитектуре микросервисов основано на сравнении с монолитным приложением.

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

Монолитное программное обеспечение

Корпоративные приложения, поскольку они обслуживают многие бизнес-потребности, будут иметь специальные программные приложения, предоставляющие множество функций, и общая практика заключается в объединении этих функций в одном монолитном приложении. Например, ERP, CRM и различные другие программные системы планируется строить как монолиты с сотнями функций. После того, как такое приложение с ямками будет развернуто, оно станет одним кошмаром за другим в будущих сценариях устранения неполадок, расширения и обновления.

Сервис-ориентированная архитектура (SOA) направлена ​​на преодоление вышеуказанных ограничений путем введения концепции «сервисов», которые представляют собой агрегаты и группы, извлеченные из аналогичных функций, предоставляемых приложением. Таким образом, при использовании SOA программные приложения разрабатываются как композиции «крупномасштабных» сервисов. Однако объем сервисов в SOA очень широк, что, в свою очередь, приводит к сложным и крупным сервисам с большим количеством операций (функций) и чрезвычайно сложными форматами сообщений и стандартами (такими как стандарт WS*).

В большинстве случаев сервисы в SOA независимы друг от друга, за исключением того, что они развертываются в той же среде выполнения, что и все остальные сервисы (достаточно рассмотреть несколько веб-приложений, которые будут развернуты в одном и том же экземпляре Tomcat). Подобно монолитным программным приложениям, эти сервисы со временем имеют привычку накапливать различные работы. Рис. 1 — хороший пример монолитной архитектуры, показывающий розничное программное приложение, включающее несколько служб, которые можно развернуть в одном приложении.

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

• Монолитные приложения проектируются, разрабатываются и развертываются как единое целое.

• Монолитные приложения относительно сложны, что затрудняет обслуживание, обновление и добавление новых функций.

• Трудно применять гибкие методы разработки и доставки с монолитной архитектурой.

• Чтобы обновить какую-то часть, ее, скорее всего, придется переустанавливать.

• В случае противоречивых требований к масштабу, если вы хотите выполнить одноточечное расширение, вам нужно подготовиться к многократному использованию ресурсов или даже к свержению и началу заново (например, если вы хотите обслуживать больше ЦП для A, сервис B может надо переделывать, а может надо два-три раза дополнить память)

• Надежность: нестабильная служба может снизить производительность всего приложения.

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

Микросервисно-ориентированная архитектура

Архитектура, ориентированная на микросервисы, обладает некоторыми качествами. Эти характеристики обязательно будут востребованы средними и крупными компаниями любого размера, если они хотят сохранить гибкость своих ИТ-систем и иметь возможность масштабировать систему в любое время.

Почему архитектура, ориентированная на микросервисы, лучше

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

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

недостаточность

Абсолютов не бывает, и у микросервисов тоже будет несколько проблем:

• Сетевая задержка. Распределенный характер микросервисов делает сетевую задержку неизбежной.

• Эксплуатационная нагрузка: больше серверов означает больше работы по техническому обслуживанию.

• Конечная согласованность: в системе с высокими требованиями к транзакциям, учитывая ограничения реализации, несогласованность данных может возникнуть на каждом узле в течение определенного периода времени.

ключевые принципы дизайна

В целом можно выделить следующие принципы проектирования:

• Принцип единой ответственности (SRP). Предоставление ограниченного и целенаправленного объема бизнеса для микросервисов помогает нам обеспечить гибкость разработки и предоставления сервисов.

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

• Микросервисы предназначены для обеспечения бесперебойной и стабильной гибкой/независимой разработки и развертывания сервисов.

• Мы должны сосредоточиться на масштабе микрослужбы, а не делать ее «меньше». Размер услуги должен относиться к размеру области, необходимой для облегчения данной бизнес-возможности.

• В отличие от сервисов в SOA, данный микросервис должен иметь несколько операций/функций и простой формат сообщения.

• Со временем рекомендуется начинать с относительно широких границ служб, рефакторинг до меньших границ служб (исходя из потребностей бизнеса).

ключевые преимущества

Теперь мы рассмотрим несколько ключевых преимуществ.

эластичность

Википедия определяет эластичность как系统处理变化的能力.我对弹性的理解是在问题被解决后系统从异常状态或者压力期中优雅的恢复，同时又不会影响系统性能的能力。

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

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

Масштабируемость

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

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

Разнообразие технологий

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

• Golang: Текущая тенденция благодаря сочетанию высокой производительности с элегантным и лаконичным синтаксисом, который любой, у кого есть опыт работы с языком программирования, может выучить за несколько дней.

• Java: с момента выпуска Spring Boot он стал довольно привлекательным стеком технологий для написания гибких сервисов.

• DJango: мощная среда Python для написания микросервисов, очень похожая на Ruby on Raile.

• Node.js: использует сильные стороны известного JavaScript для создания нового стека серверных технологий, который меняет способ написания инженерами нового программного обеспечения.

Итак, есть ли проблема с объединением технологических стеков этих языков? Справедливости ради, это преимущество:我们可以选择合适的工具来做相对应的工作. Пока технологии, которые необходимо интегрировать, стандартизированы, архитектура, ориентированная на микросервисы, может помочь вам в этом.

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

Node.js не подходит для параллельных задач. Для тех микросервисов, которые находятся под давлением, мы можем выбрать более подходящий язык для разработки, такой как Erlang, который может управлять параллелизмом более элегантным способом.

заменяемость

Заменяемость относится к способности заменить компонент в системе, не влияя на поведение системы. Когда мы говорим о программном обеспечении, заменяемость часто неотделима от низкой связанности. При написании микросервисов внутренняя логика не может быть раскрыта вызывающей службе, реализация службы прозрачна для клиента, и клиенту нужно знать только интерфейс.

независимость

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

легко развернуть

Микросервисы должны быть просты в развертывании по следующим причинам:

• Меньше бизнес-логики, что упрощает развертывание.

• Микросервисы — это автономные единицы работы, поэтому обновление сервиса — локально контролируемая проблема для сложных систем. Нет необходимости переустанавливать всю систему.

• И инфраструктура, и конфигурация в архитектуре микросервисов должны быть максимально автоматизированы (например, Docker для развертывания микросервисов).

SOA против микросервисов

Архитектура, ориентированная на микросервисы (SOA), и архитектура микросервисов очень изобретательны. Так в чем именно разница между ними?

Микросервисы — это детализированные компоненты SOA. Другими словами, один компонент SOA можно разделить на несколько микросервисов, и эти микросервисы могут обеспечивать тот же уровень функций, что и исходный компонент SOA, за счет разделения труда и сотрудничества, как показано на следующем рисунке:

Еще одно различие между микросервисами и SOA заключается в технологии, в которой сервисы взаимосвязаны и написаны. Микросервисы, с другой стороны, обеспечивают соблюдение стандартов, таких как HTTP, которые широко известны и широко используются. Мы можем получить ключевые преимущества, упомянутые в Tech Diversity, выбрав правильный язык или работу для создания компонента (микросервиса).

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

Почему выбирают Node.js

Node.js — это новый стек технологий, и для многих это просто тренд, и это далеко не практический инструмент для решения задач.

Давайте сосредоточимся на Node.js. Node.js — отличный выбор для создания архитектур, ориентированных на микросервисы, по следующим причинам:

• Низкий порог обучения (если вы хотите быть профессионалом, все равно есть определенный порог)

• легко расширить

• дружественный к тесту

• легко развернуть

• Управление зависимостями через npm

• Существует большое количество библиотек, интегрированных с основными стандартными протоколами.

Агрегация API

Агрегация API — это продвинутый метод объединения различных функций (плагинов, методов и т. д.) в интерфейс. пример:

const express = require('express');
const app = express();
app.get('/sayhello', function (req, res) {
  res.send('Hello World!');
});
app.get('/saygoodbye', function(req, res) {
  res.send('Bye bye!');
}
const server = app.listen(3000, function () {
  let host = server.address().address;
  let port = server.address().port;
  console.log('Example app listening at http://%s:%s', host, port);
});
скопировать код

В предыдущих примерах использовался популярный веб-фреймворк Express в стеке Node.js. Фреймворк также построен на агрегации API.

Давайте посмотрим на четвертую и седьмую строки. В этом коде разработчик регистрирует два метода. Когда кто-то делает запрос GET к URL-адресам: /sayhello и /saygoodbye соответственно, эти два соответствующих метода будут выполнены. В этом примере интерфейс — это приложение, прослушивающее порт 3000.

резюме

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

Наконец, мы обсудили, как Node.js является мощным инструментом для создания микросервисов и как вы можете создавать высококачественные программные компоненты, используя такие методы, как агрегирование API, чтобы извлечь выгоду из JavaScript.