Я учился в компании почти месяц.
В течение месяца я начал обращаться к распределенной микросервисной архитектуре с 0, что дало мне большой выигрыш. Сегодня позвольте мне разобраться в основном содержании микросервисной архитектуры (вся галантерея) от начала до конца.
Ниже вы увидите основные принципы основных платформ микросервисов в отрасли, включая обнаружение сервисов, шлюзы, центры конфигурации, мониторинг и другие компоненты, функции и краткое введение в принципы архитектуры. Спасибо за чтение! 😋
Хотите разблокировать больше новых поз? Пожалуйста, посетитемой блог. 😏
Привет, микросервисы
Что такое микросервисы
Отец микросервисов, Мартин Фаулер, дает примерное представление о микросервисах следующим образом:
На данный момент не существует единого стандартного определения индустрии микросервисов (пока нет точного определения этого архитектурного стиля). Но вообще говоря, микросервисная архитектура — это архитектурный шаблон или архитектурный стиль, который выступает за разделение одного приложения на набор небольших сервисов, каждый из которых работает в своем собственном процессе.Координируйте и сотрудничайте друг с другом, чтобы предоставить пользователям максимальную ценность. Службы взаимодействуют друг с другом с помощью облегченных механизмов связи (обычно RESTful API на основе HTTP). Каждая услуга строится вокруг определенного бизнеса и может быть независимо развернута в производственной среде, среде, подобной производственной, и т. д. Кроме того, следует максимально избегать унифицированного и централизованного механизма управления службами.Для конкретной службы следует выбирать соответствующие языки и инструменты в соответствии с бизнес-контекстом для ее построения, и может быть достигнуто очень легкое централизованное управление. , чтобы координировать эти услуги. Сервисы могут быть написаны на разных языках, и могут использоваться разные хранилища данных.
Согласно описанию Мартина Фаулера, я резюмирую несколько моментов:
(Слова плохие, не не нравится)
небольшой сервис
Небольшой сервис, нет определенного стандарта или спецификации, но он должен быть небольшим в общей спецификации.
независимость процесса
Каждый набор служб работает независимо, возможно, моя служба работает вtomcatконтейнер, в то время как другая служба работает вjettyначальство. Всю услугу можно непрерывно масштабировать по горизонтали на протяжении всего процесса.
коммуникация
В прошлом все протоколы были тяжелыми, как ESB, как SOAP, легкая коммуникация, что означало, что более умные и легкие сервисы вызывали друг друга, чем в прошлом, так называемые интеллектуальные конечные точки и тупые каналы, все эти конечные точки не связаны Да, завершение вызов делового общения и подключение этих микросервисов похоже на подключение ряда командных сервисов через конвейеры в системе Linux.
В прошлом мы обычно рассматривали различные зависимости и проблемы, вызванные сопряжением систем. Микросервисы позволяют разработчикам больше сосредоточиться на разработке бизнес-логики.
развертывать
Независимым должен быть не только бизнес, но и развертывание. Однако это также означает, что традиционный процесс разработки будет в определенной степени изменен, а также будет определенная вина за пригодность разработки со стороны эксплуатации и обслуживания.
управлять
Традиционные сервисы SOA корпоративного уровня часто бывают большими, сложными в управлении, сильно связанными и экономически эффективными для групповой разработки. Микросервисы позволяют командам выбирать собственные технологии для реализации, а разные сервисы могут выбирать разные стеки технологий для реализации своей бизнес-логики в соответствии со своими потребностями.
Плюсы и минусы микросервисов
Зачем использовать микросервисы? Потому что это весело?
нет. Ниже приведены преимущества, которые я нашел в Интернете:
Преимущества Каждая услуга достаточно целостна, достаточно мала, а код прост для понимания, поэтому ее можно сфокусировать на определенной бизнес-функции или бизнес-требовании.
Разработка проста, а эффективность разработки повышена.Услуга может быть посвящена только одному делу.
Микросервисы могут разрабатываться индивидуально небольшими группами от 2 до 5 разработчиков.
Микросервисы — это слабосвязанные, функционально значимые сервисы, которые независимы ни при разработке, ни при развертывании.
Микросервисы могут разрабатываться на разных языках.
Микросервисы, которые легко интегрировать со сторонними поставщиками, обеспечивают простую и гибкую интеграцию автоматизированных развертываний с помощью инструментов непрерывной интеграции, таких как Jenkins, Hudson и Bamboo.
Микросервисы легко понять, модифицировать и обслуживать один разработчик, поэтому небольшие группы могут больше сосредоточиться на своей работе. Нет необходимости - - Ценность может быть реализована только через сотрудничество. Микросервисы позволяют использовать новейшие технологии в слиянии.
Микросервисы — это просто код для бизнес-логики, не смешанный с HTML, CSS или другими компонентами интерфейса.
Каждый микросервис имеет собственные возможности хранения и может иметь собственную базу данных. Также может быть объединенная база данных.
В целом преимущество микросервисов заключается в том, что в условиях больших систем они могут эффективно снизить сложность и сделать логику сервисной архитектуры более понятной.
Но это также принесет множество проблем, таких как непротиворечивость данных в распределенной среде, сложность тестирования, сложность эксплуатации и обслуживания.
Какая организация подходит для использования микросервисов?
Микросервисы имеют различные преимущества и недостатки, так какая организация подходит для использования микросервисов?
Закон Мерфи (системы проектирования) и закон Конвея (разделение системы)
Закон Конвея — это концепция микросервисов, предложенная более 50 лет назад. В статье Конвея самая известная строчка:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
Китайский дословный перевод примерно означает: организация системы проектирования, дизайн, производимый ею, эквивалентен коммуникационной структуре внутри организации и между организациями. Взгляните на картинку ниже (из Интернета, захваченную и удаленную), а затем подумайте о продуктах Apple и дизайне продуктов Microsoft, и вы сможете наглядно понять это предложение.
Желающие могут изучить
Эволюция архитектуры
Архитектура постоянно развивается, то же самое верно и для микросервисов.Когда масштаб крупных технологических компаний достигает определенного уровня, совершенно необходимо эволюционировать в систему технической архитектуры для дальнейшего управления.
(Слова плохие, не не нравится)
Традиционная команда ориентирована на процесс: после того, как продукт продуман, она переходит к планированию, после планирования — к разработке, а затем идет шаг за шагом. Мы делаем технологию для продукта.Если в процессе возникает проблема, будет очень много времени, чтобы оглянуться на проблему.
(Слова плохие, не не нравится)
Используя систему микросервисной архитектуры, организация команды должна быть преобразована в кросс-функциональную команду, то есть в каждой команде есть эксперты по продукту, эксперты по планированию, эксперты по разработке, а также эксперты по эксплуатации и обслуживанию.Они используют методы API для публикации своих функций, и платформа использует свой продукт выпуска Feature
Система архитектуры микросервисной технологии
Ниже я расскажу о системе архитектуры микросервисных технологий, которую использует большинство компаний.
(Плохая картинка, не подумайте)
обнаружение службы
Обнаружение основных услуг, разделенное на три
Первый заключается в том, что после того, как разработчик разработает программу, он найдет доменное имя для эксплуатации и обслуживания.Если услуга будет оказана, мы можем найти наш соответствующий сервис через dns.
Недостатком является то, что, поскольку служба не имеет функции балансировки нагрузки, могут возникнуть значительные проблемы с производительностью службы балансировки нагрузки.
Во-вторых, это общепринятая практика. Вы можете обратиться к шлюзу zuul, проанализированному в моем предыдущем блоге.Каждая служба регистрируется в реестре с помощью встроенной функции сервера.Потребители службы постоянно опрашивают реестр, чтобы найти соответствующую службу, и используют встроенную балансировку нагрузки. позвонить в сервис.
Недостаток в том, что он не очень хорош для многоязычных сред, и вам нужно разрабатывать функции обнаружения сервисов и балансировки нагрузки отдельно для клиента потребителя. Конечно, этот метод обычно используется вspring cloudВверх.
Третий — поместить клиент и балансировщик нагрузки на один и тот же хост, а не в один и тот же процесс.
По сравнению с первым и вторым методами этот метод устраняет их недостатки, но значительно увеличивает стоимость эксплуатации и обслуживания.
шлюз
Что такое шлюз для микросервисов?
Мы можем подумать об этом в реальной жизни. У каждой крупной компании есть своя строительная площадка, и на этой строительной площадке много охранников. Если иностранцы входят в компанию, они сначала приветствуют швейцара перед входом.
Нетрудно понять значение шлюза, когда практично связать жизнь с микросервисами.
Какая польза от шлюза
- Обратная маршрутизация: во многих случаях компании не хотят, чтобы посторонние видели внутреннюю часть нашей компании, поэтому им нужен шлюз для обратной маршрутизации. Преобразование внешних запросов во внутреннюю конкретную службу
- Аутентификация безопасности: в сети будет много злонамеренных доступов, таких как поисковые роботы, хакерские атаки и функции безопасности обслуживания шлюза.
- Автоматический выключатель с ограничением тока: обратитесь к моему блогу, чтобы хорошо изучить распределенный зоозащитник Когда много запросов перегружены, наши сервисы будут автоматически отключены, что приведет к тому, что сервисы станут непригодными для использования. Токоограничивающие предохранители могут эффективно избежать таких проблем.
- Мониторинг журнала: все внешние запросы будут проходить через шлюз, поэтому мы можем использовать шлюз для записи информации журнала.
- Выпуск в оттенках серого, сине-зеленое развертывание. Это относится к методу публикации, который может плавно переходить. На нем можно проводить A/B-тестирование, то есть пусть некоторые пользователи продолжают использовать фичу продукта А, а некоторые пользователи начинают использовать фичу продукта Б. Если у пользователей нет возражений против Б, то постепенно расширять область применения и мигрировать все пользователей к Б. Приходите.
Архитектура шлюза Zuul с открытым исходным кодом
zuulЯдро шлюза на самом деле являетсяservlet, все запросы проходятzuul servletраспространиться наzuulFilter Runner, а затем распределяется по трем фильтрам.
Давайте сначала поговорим о левой половине архитектурной диаграммы, которая предназначена для использованияGroovyРеализован премаршрутный фильтр, маршрутный фильтр, постмаршрутный фильтр.
Обычно запросы обрабатываются первыми.предмаршрутный фильтрОбработка, общая пользовательская логика упаковки Java также будет реализована здесь.
фильтр маршрута, реализация состоит в том, чтобы найти соответствующий микросервис для вызова.
После завершения вызова ответ вернется, и он пройдет черезпочтовый фильтр маршрута, мы можем инкапсулировать обработку аудита журналов с помощью фильтров пост-маршрутизации.
Можно сказатьzuulСамой большой особенностью шлюза является его трехуровневый фильтр.
Правая половина диаграммы архитектурыzuulПользовательский механизм загрузки фильтров для конструкции шлюза. Внутри шлюза будет модель производитель-потребитель, которая автоматически опубликует скрипт фильтра вzuulШлюз считывает нагрузку и запускается.
Центр конфигурации
В прошлом разработчики помещали файлы конфигурации в файлы разработки, в которых было много скрытых опасностей. Например, спецификации конфигурации отличаются, а персонал, занимающийся конфигурацией, невозможно отследить. Как только конфигурация должна быть изменена в больших масштабах, время изменения будет очень долгим, и персонал, занимающийся конфигурацией, нельзя будет отследить, что повлияет на весь продукт, а последствия будут непозволительны.
Следовательно, есть центр конфигурации~
Текущий центр с открытым исходным кодом имеетЦентр конфигурации BaiduDisconf, spring cloud config, Apollo, сегодня я остановлюсь на Apollo, центре конфигурации с хорошим качеством приложений.
Apollo с открытым исходным кодом Ctrip
Адрес в открытом доступе 👉:GitHub.com/C trip Corp/Ах…
Центр конфигурации apollo относительно велик, и локальное приложение будет иметь соответствующий клиент центра конфигурации, который может регулярно синхронизировать конфигурацию в центре конфигурации. Если центр конфигурации простаивает, кэш будет использоваться для конфигурации.
способ связи
Что касается способов связи, то на рынке обычно есть два метода удаленного вызова, я составил таблицу:
| RPC | REST | |
|---|---|---|
| связь | сильная связь | слабо связанный |
| протокол сообщения | TCP | HTTP |
| Протокол | бинарный | Текст XML, JSON |
| представление | высокий | ниже, чем RPC |
| Контракт интерфейса IDL | thrift,protobuf,IdL | Swagger |
| клиент | Строго типизированный клиент, обычно генерируемый автоматически | Обычно доступен по HTTP, генерирует строго типизированный клиент, хорошая многоязычная поддержка. |
| кейс | Даббо, даббокс, мотан, тарс, грпс, бережливость | spring boot,tax-rs,dropwizard |
| дружественный к разработчику | Сравнение на стороне клиента, двоичные сообщения не могут быть прочитаны | читаемое сообщение |
| открытый для внешнего мира | Обычно необходимо преобразовать в REST/текстовый протокол | Может быть непосредственно разработан извне |
Мониторинг и раннее предупреждение
Мониторинг и раннее оповещение очень важны для микросервисов, а надежная система мониторинга и раннего оповещения имеет решающее значение для работы микросервисов. Общий мониторинг делится на следующие уровни:
От инфраструктуры до стороны пользователя существуют уровни мониторинга, всесторонние, многоугольные, и каждый уровень очень важен. В целом микросервисы можно разделить на 5 точек мониторинга:мониторинг журнала,Мониторинг метрик,медицинское обследование,проверка цепочки вызовов,Сигнализация
Архитектура мониторинга
Следующая диаграмма представляет собой диаграмму архитектуры мониторинга большинства компаний. У каждой службы естьagent,agentСобранная ключевая информация будет передана некоторымMQ, для развязки. Параллельно пройти логинELK,будетMetricsвходящийInfluxDBБиблиотека временных рядов. И нравитсяnagios, можно периодически инициировать микросервис проверки информации для агента.
Мониторинг цепочки вызовов APM
Во многих компаниях есть мониторинг цепочки вызовов, например, у Али есть мониторинг Eagle Eye, прокомментировалCat, большая часть мониторинга цепочки вызовов (да, я имею в видуZipkin) Архитектура такая👇
Когда запрос войдет в веб-контейнер, он будет созданTracer,соединятьspans(Моделирование задержки для потенциально распределенной работы, этот модуль также содержит наборы инструментов для передачи информации о контексте трассировки по сети систем, например, через заголовки http).SpansЕсть контекст, который содержитtracerИдентификатор для размещения в правильном месте дерева, представляющего распределенную операцию. Когда мы помещаем различные промежутки на рисунке в серверную часть, наша цепочка вызовов службы будет динамически генерировать цепочку вызовов.
Ниже приведены некоторые из наиболее часто используемых на рынке систем мониторинга цепочки вызовов:
1. Точно определитьадрес гитхаба:GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.Друзья, которые интересуются анализом производительности в области java, должны взглянуть на этот проект с открытым исходным кодом. Это открытый исходный код корейской команды. Он имплантирует код байт-кода через механизм JavaAgent для достижения цели добавления трассировки и захвата производительности. данные. . Анализ производительности таких инструментов, как NewRelic и Oneapm на платформе java, также представляет собой аналогичный механизм.
2. Прогулки по небуадрес гитхаба:wu-sheng/sky-walkingЭто открытый исходный код брата по имени Ву Шэн в Китае.Это также система для отслеживания, оповещения и анализа бизнес-операций распределенных кластеров приложений JAVA.Он также имеет более 400 звезд на github. Функционал чуть слабее пинпоинта, да и плагин не такой богатый, но тоже редкий.
3. ЗипкинОфициальный сайт:OpenZipkin · A distributed tracing systemадрес гитхаба:GitHub - openzipkin/zipkin: Zipkin is a distributed tracing systemЭто открытое твиттером, и это также сделано со ссылкой на систему Dapper.
Сторона Java-приложения Zipkin использует компонент Brave для сбора данных анализа производительности внутри приложения. Адрес Brave на гитхабе:GitHub.com/open zip kin/…Этот компонент реализует серию перехватчиков Java для отслеживания процесса вызова запросов http/servlet и доступа к базе данных. Затем, добавляя эти перехватчики в файлы конфигурации, такие как spring, сбор данных о производительности java-приложений завершается.
4. КОШКАадрес гитхаба:GitHub - dianping/cat: Central Application TrackingЭто открытый исходный код Dianping, и реализованные функции довольно богаты, и некоторые отечественные компании также используют его. Однако его метод отслеживания заключается в жестком кодировании некоторых «скрытых точек» в коде, то есть навязчивости. В этом есть свои плюсы и минусы: плюс в том, что вы можете добавлять точки захоронения там, где вам это нужно, что более целенаправленно, минус в том, что существующую систему нужно менять, а многие команды разработчиков этого не хотят.
5. Xhprof/XhguiКомбинация этих двух инструментов представляет собой инструмент, который обеспечивает возможности APM для приложений PHP, а также не требует вмешательства. Адрес Xhprof на гитхабе:GitHub - preinheimer/xhprof: XHGUI is a GUI for the XHProf PHP extension, using a database backend, and pretty graphs to make it easy to use and interpret.Адрес гитхаба xhgui:GitHub - perftools/xhgui: A graphical interface for XHProf data built on MongoDBЯ не знаком с PHP, но информации об этих двух инструментах в Интернете довольно много.
Плавкие предохранители, изоляция, ограничение тока, деградация
Перед лицом огромного всплеска трафика крупные компании обычно используют сериюпредохранитель(Система автоматически отключает службу, чтобы предотвратить максимизацию проблемы),изолировать(Изолируйте службы от служб, чтобы одна служба не была связана с другими службами и к ней нельзя было получить доступ),Ограничение(Определенное количество пользователей имеет доступ в единицу времени),понизить рейтинг(Когда общая нагрузка всей микросервисной архитектуры превышает заданный верхний порог или ожидается, что входящий трафик превысит заданный порог, для обеспечения нормальной работы важных или базовых сервисов мы можем поставить какие-то неважные или неважные сервисы. услуги или задачи (задержка использования или приостановка использования услуг) меры.
Давайте представимhystrixТекущий процесс (извините, что не нашел схему архитектуры):
Каждый раз, когда вызывается микросервис, он будет использоватьhystrixизcommandспособом (тот, что в верхнем левом углу рисунка выше), а затем используйтеcommandСинхронный,илиотзывчивый,илиАсинхронный, чтобы определить, не перегорела ли цепь (см. рисунок слева направо),
Если цепь разорвана, используйте резервный вариант понижения;
Если линия закрыта, но ресурсы потока исчерпаны, а очередь заполнена, принять текущие ограничительные меры (см. шаг 5 на рисунке);
Если он завершен и выполнение прошло успешно, перейдите к методу run(), чтобы получить ответ, но если в этом процессе есть ошибка, продолжайте переходить к резервному варианту понижения.
В то же время в верхней части картинки есть суффикс, которыйhealthДа, это компонент, который вычисляет, исправна ли ссылка целиком, и фиксирует каждый шаг операции.
Механизм оркестрации контейнеров и сервисов
От физических машин к виртуальным машинам, от виртуальных машин к контейнерам, от физических кластеров кopen stack,open stackприбытьkubernetesТехнологии постоянно меняются, а наше познание не обновлялось.
Начнем с контейнера, который в первую очередь представляет собой относительно независимую работающую среду, чем-то похожую в этом отношении на виртуальную машину, но не такую полную, как виртуальная машина. Виртуальная машина упаковывает виртуальное оборудование, ядро (например, операционную систему) и пространство пользователя в новую виртуальную машину, которая может работать на физическом устройстве с помощью «гипервизора». Виртуальная машина опирается на гипервизор, который часто устанавливается на системное оборудование «голого железа», что приводит к тому, что гипервизор в некотором роде считается операционной системой. После установки гипервизора экземпляры виртуальных машин могут быть выделены из доступных вычислительных ресурсов системы, и каждая виртуальная машина может получить уникальную операционную систему и нагрузку (приложение). Короче говоря, виртуальная машина сначала должна виртуализировать физическую среду, затем построить полную операционную систему, создать слой среды выполнения, а затем запустить приложение. Для контейнерных сред нет необходимости устанавливать операционную систему хоста, а уровень контейнера (например, LXC или libcontainer) устанавливается непосредственно поверх операционной системы хоста (обычно это вариант Linux). После установки уровня контейнера экземпляры контейнера могут быть выделены из доступных вычислительных ресурсов системы, а корпоративные приложения могут быть развернуты в контейнерах. Однако каждое контейнерное приложение будет использовать одну и ту же операционную систему (операционную систему с одним хостом). Контейнер можно рассматривать как виртуальную машину с установленным набором определенных приложений.Он напрямую использует ядро хост-машины.У него меньше уровней абстракции, чем у виртуальных машин, он легче и запускается очень быстро.
Контейнеры более эффективны с точки зрения ресурсов, чем виртуальные машины, поскольку им не требуется отдельная операционная система для каждого приложения — экземпляры меньше по размеру, их создание и миграция выполняются быстрее. Это означает, что одна операционная система может содержать больше контейнеров, чем виртуальная машина. Поставщики облачных услуг очень заинтересованы в технологии контейнеров, поскольку на одном и том же аппаратном устройстве можно развернуть больше экземпляров контейнеров. Кроме того, контейнеры легко мигрировать, но их можно мигрировать только на другие серверы с совместимыми ядрами операционной системы, что ограничивает возможности миграции. Поскольку контейнеры не упаковывают то же ядро или виртуальное оборудование, что и виртуальные машины, каждый набор контейнеров имеет собственное изолированное пользовательское пространство, что позволяет запускать несколько наборов контейнеров в одной и той же хост-системе. Мы видим, что все архитектуры на уровне ОС могут совместно использоваться контейнерами, и единственное, что нужно создавать независимо, — это двоичные файлы и библиотеки. Из-за этого контейнеры очень легкие.
Наш наиболее часто используемый контейнер — daocker, URL-адрес выглядит следующим образом: https://www.docker.com/
Оркестрация контейнеров
В прошлом виртуальные машины могли проходить через облачные платформыopen stackВиртуализация управления, как управлять контейнерами в эпоху контейнеров? Это зависит от механизма оркестрации контейнеров.
Apache mesos
Mesos основан на архитектуре ведущий и подчиненный. Фреймворк решает, как использовать ресурсы. Мастер отвечает за управление машиной. Ведомый периодически сообщает о состоянии машины мастеру, а мастер затем отправляет информацию в фреймворк. . Мастер высокодоступен, а из-за зк есть и лидер. Ниже схема архитектуры👇
kubernetes
Kubernetes — очень популярный в последнее время движок для оркестровки контейнеров с открытым исходным кодом.китайская документация kubernetes
Концепция дизайна и функции Kubernetes на самом деле представляет собой многоуровневую архитектуру, похожую на Linux.Во-первых, внутри каждого узла Kubernetes kubelet управляет глобальным глобальным модулем, и каждый модуль несет один или несколько контейнеров, а kube-proxy отвечает за сетевой прокси. и загрузите сбалансированный.
За пределами узла Kubernetes находится соответствующий сервер контроля и управления, который отвечает за унифицированное управление планированием, распределением и работой каждого узла.
сервисная сетка
. . . ожидающее обновления
Данные и литература
Описание микросервисов Мартином Фаулером
Теоретические основы микросервисной архитектуры — закон Конвея
Zipkin, Pinpoint, SkyWalking, CAT для выбора цепочки вызовов
Заканчивать
Этот фильм закончился~ Хотите узнать больше о новых захватывающих позах?
пожалуйста, посетите мойличный блог
Эта статья является оригинальным содержанием, уже вличный блогПервая публикация, а затем настроение может быть выпущено одновременно на CSDN, segmentfault, Nuggets, Jianshu и Open Source China. Если есть сходство,судьбародной брат. Спешите добавить друга, давайте придумаем число, купим лотерейный билет и заработаем ему несколько миллионов первым😝