Микросервисы в Azure

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

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

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

Этот вопрос и, конечно же, ответы будут основаны на мнениях, но, как правило, думая в терминах микросервисов, думайте не в терминах таких вещей, как множество API, виртуальных машин и т. д. Вместо этого думайте в терминах. Когда я загружаю изображение, необходимо изменить его размер и обновить таблицу, чтобы указать URL-адрес для бегунка. или при обновлении записи XXX в базе данных запустите XXX, чтобы создать отчет, или обновите поиск Azure. и что каждая служба умеет делать только одну вещь. I.E Измените размер изображения.

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

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

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

Хорошим примером, для которого я его использую, является электронная почта и SMS. Мои системы не умеют отправлять электронную почту или SMS. Они умеют только добавлять в очередь. Мои микросервисы. SendEmail и SendSMS знают, как это делать, и я могу очень легко изменить, как и кому я отправляю этот контент. Я могу завтра перейти с Twilio на отправку сетки, даже не сообщая API, что я это сделал.

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

В основном я говорю о том, чтобы начать работу, возможно, о портировании существующего приложения. Начните с рабочего процесса, например, отправьте электронное письмо, измените размер изображения, создайте отчет, создайте PDF-файл, отправьте электронное письмо 50 подписчикам и т. д., Возьмите весь этот код и поместите в собственный микросервис, который просто знает, как сделать одно. Затем, когда вы будете уверенно расти, создайте рабочий процесс из всех этих служб с помощью Logic Apps, а обо всем остальном позаботится Azure, это то, что они хотят делать.