Микросервисная архитектура: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[непроверенная версия][отпатрулированная версия]
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
Строка 1: Строка 1:
'''Микросервисная архитектура''' — вариант [[Сервис-ориентированная архитектура|сервис-ориентированной архитектуры]] программного обеспечения, ориентированный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — '''''микросервисов''''', получивший распространение в середине 2010-х годов в связи с развитием практик [[Гибкая разработка программного обеспечения|гибкой разработки]] и [[DevOps]]<ref name="martinfowler">{{cite web|url= http://martinfowler.com/articles/microservices.html|title= Microservices|author= Martin Fowler|date=10.03.2014|publisher=martinfowler.com}}</ref><ref>{{Cite journal|last= Balalaie|first= A.|last2= Heydarnoori|first2= A.|last3= Jamshidi|first3= P.|date= 2016-05-01|title= Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|url= http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7436659 |journal= IEEE Software|volume= 33|issue= 3|pages= 42–52|doi= 10.1109/MS.2016.64|issn= 0740-7459}}</ref><ref>[https://www.javacodegeeks.com/2014/12/continuous-deployment-strategies.html Continuous Deployment: Strategies]</ref>.
'''Микросервисная архитектура''' — вариант [[Сервис-ориентированная архитектура|сервис-ориентированной архитектуры]] программного обеспечения, ориентированный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — '''''микросервисов''''', получивший распространение в середине 2010-х годов в связи с развитием практик [[Гибкая разработка программного обеспечения|гибкой разработки]] и [[DevOps]]<ref name="martinfowler">{{cite web|url= http://martinfowler.com/articles/microservices.html|title= Microservices|author= Martin Fowler|date=10.03.2014|publisher=martinfowler.com}}</ref><ref>{{Cite journal|last= Balalaie|first= A.|last2= Heydarnoori|first2= A.|last3= Jamshidi|first3= P.|date= 2016-05-01|title= Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture|url= http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7436659 |journal= IEEE Software|volume= 33|issue= 3|pages= 42–52|doi= 10.1109/MS.2016.64|issn= 0740-7459}}</ref><ref>[https://www.javacodegeeks.com/2014/12/continuous-deployment-strategies.html Continuous Deployment: Strategies]</ref>.


Если в традиционных вариантах сервис-ориентированной архитектуры модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы (такие, как [[SOAP]], [[XML-RPC]]), в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции, и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов (в стиле [[REST]] с использованием, например, [[JSON]], [[Protocol Buffers]], [[Thrift]]). За счёт повышения гранулярности модулей архитектура нацелена на уменьшение [[GRASP#Слабое зацепление (Low Coupling)|степени зацепления]] и увеличение [[GRASP#Высокая связность (High Cohesion)|связности]], что позволяет проще добавлять и изменять функции в системе в любое время<ref name="intorMS">{{cite web|url=https://specify.io/concepts/microservices|title= Introduction into Microservices|author= Oliver Wolf}}</ref>.
Если в традиционных вариантах сервис-ориентированной архитектуры модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы (такие, как [[SOAP]], [[XML-RPC]]), в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции, и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов (в стиле [[REST]] с использованием, например, [[JSON]], [[Protocol Buffers]], [[Thrift]]). За счёт повышения гранулярности модулей архитектура нацелена на уменьшение [[GRASP#4._Слабое_зацепление_(Low_Coupling)|степени зацепления]] и увеличение [[GRASP#5._Высокая_связность_(High_Cohesion)|связности]], что позволяет проще добавлять и изменять функции в системе в любое время<ref name="intorMS">{{cite web|url=https://specify.io/concepts/microservices|title= Introduction into Microservices|author= Oliver Wolf}}</ref>.


== Свойства ==
== Свойства ==

Версия от 22:37, 28 ноября 2018

Микросервисная архитектура — вариант сервис-ориентированной архитектуры программного обеспечения, ориентированный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов, получивший распространение в середине 2010-х годов в связи с развитием практик гибкой разработки и DevOps[1][2][3].

Если в традиционных вариантах сервис-ориентированной архитектуры модули могут быть сами по себе достаточно сложными программными системами, а взаимодействие между ними зачастую полагается на стандартизованные тяжеловесные протоколы (такие, как SOAP, XML-RPC), в микросервисной архитектуре системы выстраиваются из компонентов, выполняющих относительно элементарные функции, и взаимодействующие с использованием экономичных сетевых коммуникационных протоколов (в стиле REST с использованием, например, JSON, Protocol Buffers, Thrift). За счёт повышения гранулярности модулей архитектура нацелена на уменьшение степени зацепления и увеличение связности, что позволяет проще добавлять и изменять функции в системе в любое время[4].

Свойства

Свойства, характерные для микросервисной архитектуры[1]:

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

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

Наиболее популярная среда для выполнения микросервисов — системы управления контейнеризованными приложениями (такие как Kubernetes и её надстройки OpenShift и CloudFoundry[англ.], Docker Swarm, Apache Mesos[англ.]), в этом случае каждый из микросервисов как правило изолируется в отдельный контейнер или небольшую группу контейнеров, доступную по сети другим микросервисам и внешним потребителям, и управляется средой оркестрации, обеспечивающей отказоустойчивость и балансировку нагрузки. Типовой практикой является включение в контур среды выполнения системы непрерывной интеграции, обеспечивающее автоматизацию обновления и развёртывания микросервисов.

История

Несмотря на то, что термин «микросервисы» упоминался с середины 2000-х годов, появление концепции относят ежегодному семинару архитекторов программного обеспечения в Венеции 2011 году. В 2012 году о микросервисах докладывали на конференции 33d Degree в Кракове, а также появился ряд публикаций о «гранулярном SOA», излагающих микросервисный подход. В 2012—2014 годы о внедрении микросервисах в рамках собственных программных разработок заявляли специалисты таких компаний, как Amazon, Netflix, Twitter, с 2015 года в ведущих издательствах регулярно выпускаются книги о микросервисной архитектуре, проводится несколько регулярных конференций, целиком посвящённых микросервисам.

Критика

Архитектура постоянно подвергается критике с самого момента её формирования, среди новых проблем, которые возникают при её внедрении отмечаются:

  • сетевые задержки[5]: если в модулях, выполняющих несколько функций, взаимодействие локально, то микросервисная архитектура накладывает требование атомизации модулей и взаимодействия их по сети;
  • форматы сообщений[5]: отсутствие стандартизации и необходимость согласования форматов обмена фактически для каждой пары взаимодействующих микросервисов приводит как к потенциальным ошибкам, так и сложностям отладки;
  • баланс нагрузки и отказоустойчивости[5][прояснить].

В добавок к этому, усложняется тестирование и разработка[6].

Примечания

  1. ↑ 1 2 Martin Fowler. Microservices. martinfowler.com (10 марта 2014).
  2. ↑ Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (2016-05-01). "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture". IEEE Software. 33 (3): 42—52. doi:10.1109/MS.2016.64. ISSN 0740-7459.
  3. ↑ Continuous Deployment: Strategies
  4. ↑ Oliver Wolf. Introduction into Microservices.
  5. ↑ 1 2 3 Jan Stenberg. Experiences from Failing with Microservices (11 августа 2014).
  6. ↑ Developing Microservices for PaaS with Spring and Cloud Foundry.

Литература

  • Ньюмен С. Создание микросервисов = Building Microservices. — СПб.: Питер, 2016. — 304 с. — ISBN 978-5-496-02011-4.
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Микросервисная_архитектура&oldid=96554982