Архитектура программного обеспечения 4D Talk: бизнес-архитектура, архитектура приложений и облачная инфраструктура

Микросервисы Архитектура

Архитектура программного обеспечения 4D Talk: бизнес-архитектура, архитектура приложений и облачная инфраструктура

Этот раздел взят изпроектирование архитектуры программного обеспечения》

Разработка программного обеспечения — это разложение сложной проблемы на ряд простых проблем, а затем объединение ряда простых решений в комплексное решение. Самая большая проблема в разработке программного обеспечения — иметь возможность быстро и эффективно вносить изменения в ответ на изменения спроса и среды, а также постоянно предоставлять стабильные и высокодоступные услуги. Архитектура программного обеспечения является скелетом и каркасом программной системы.

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

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

Классификация архитектуры программного обеспечения

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

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

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

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

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

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

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

Архитектурные образцы и архитектурные стили

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

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

В серии статей автора CRUD, многоуровневая архитектура, гексагональная архитектура, луковая архитектура, REST и DDD — все это архитектурные стили, тогда как CQRS, EDA, UDLA, микросервисы и т. д. делятся на архитектурные паттерны.

Источники и ответы на сложность системы

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

В «Дизайне, управляемом предметной областью» Эрик Эванс разглагольствует о так называемой спагетти-архитектуре, когда код делает что-то полезное, но трудно объяснить, как он это делает; он утверждает, что основная причина этой дилеммы заключается в том, что смешивание сложности проблем предметной области усложнение технических деталей в конечном итоге приводит к экспоненциальному увеличению общей сложности.

Сложность не возникает из воздуха и во многих случаях не преднамеренна, а это означает, что увеличение сложности часто не зависит от нашей субъективной воли. Подобно слону в комнате, мы не можем убежать и не можем закрывать глаза. Источниками сложности могут быть:

  • Расширение и непрерывная итерация: инкрементный дизайн означает, что разработка программного обеспечения никогда не заканчивается Проектирование продолжается в жизненном цикле системы, и программисты всегда должны учитывать вопросы проектирования. Инкрементальная разработка также означает непрерывный рефакторинг. Первоначальный проект системы почти никогда не бывает лучшим решением. По мере накопления опыта обязательно будут открываться более совершенные конструкции.

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

  • Необоснованная бизнес-инкапсуляция. Необоснованная бизнес-инкапсуляция — это относительно широкое понятие, и его конкретные проявления ориентированы на процесс, а не на объект, необоснованное многослойность и т. д.

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

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

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

Дизайн, управляемый доменом

领域驱动设计

Этот раздел взят изДизайн, управляемый доменом》

Проектирование, ориентированное на предметную область, DDD возникло из его самой влиятельной и известной книги: «Дизайн, управляемое предметной областью — решение сложных задач в основе программного обеспечения», опубликованной известным экспертом по моделированию Эриком Эвансом в 2004 году. В этой книге Эрик Эванс предоставляет только набор первоначальные теории не содержат набора методологий, поэтому на протяжении многих лет существуют разные мнения о DDD. Ранее Мартин Фаулер однажды предложил концепцию модели анемии и модели гиперемии.Он считал, что большинство наших систем используют POJO в качестве модели, только обычные геттерные и сеттерные методы, никакого реального поведения, как у людей, которым не хватает крови.По мнению Эванса, Все модели в DDD существуют в виде перегрузок, то есть в DDD модели, которые мы разрабатываем, содержат не только описания бизнес-атрибутов, но и методы, которые могут описывать действия, разница в том, что некоторые понятия в предметной области не могут быть использованы. в объектах модели, таких как склады, фабрики, службы и т. д., если наложить их на модель, это разрушит определение модели.

领域驱动设计架构

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

  • Единый язык, разработчики/пользователи программного обеспечения все используют один и тот же набор языка, то есть унифицируется познание определенного понятия и существительного, устанавливается четкая бизнес-модель и формируется единая бизнес-семантика. Сделайте модели основой вашего языка. Убедитесь, что команда использует этот язык во всех внутренних коммуникациях, в коде, рисовании, письме и особенно в устной речи. Например, номера счетов, переводы и стратегии овердрафта — все это очень важные понятия предметной области.Если эти названия будут соответствовать нашим ежедневным обсуждениям и описаниям в PRD, это значительно улучшит читаемость кода и снизит затраты на когнитивные функции. . Например, никто не будет повторно подтверждать значения «приказа на работу», «приказа об утверждении» и «формы» на собрании, а модель создания DDD не будет похищена БД.

  • Предметно-ориентированная бизнес-семантика является явной, и проблемы рассматриваются в терминах предметных областей, а не модулей. Извлеките неявную бизнес-логику из push if-else, используйте общий язык для наименования, написания кода и расширения и превратите его в концепцию отображения; многие важные бизнес-концепции, в зависимости от способа написания сценариев транзакций, их значения Полностью погружены в логику кода, но не выделены.

  • Обязанности разделены, и модели разделены разумно в соответствии с фактическим бизнесом.Структура зависимостей и границы между моделями более четкие, избегая хаотических зависимостей, тем самым повышая удобочитаемость и ремонтопригодность; единая ответственность, модель фокусируется только на своей собственной работе, избегая "Ультрафиолета" " и привести к хаотичным вызовам отношений. Благодаря моделированию сложный бизнес в реальном мире может быть лучше выражен С течением времени накопление системы в реальном бизнесе будет продолжать увеличиваться, а бизнес-логика будет лучше описываться с помощью четкого кода. модель расширяет систему Он имеет высокую степень модульности и улучшает возможность повторного использования кода По сравнению с традиционной трехуровневой моделью весьма вероятно, что внутри каждого Сервиса разбросано большое количество повторяющихся функций.

Микросервисы и облачная архитектура

Этот раздел взят изМикросервисы и Cloud Native》

服务衍化

Монолитная многоуровневая архитектура

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

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

Когда эпоха Web2.0 была только популярна, не было существенной разницы между интернет-приложениями и приложениями уровня предприятия.Централизованная архитектура была разделена на три стандартных уровня: уровень доступа к данным, сервисный уровень и веб-уровень.

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

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

SOA (Service-Oriented Architecture) — это сервис-ориентированная архитектура, которая включает в себя модульную разработку, распределенное развертывание расширения и т. д. относительно широкое понятие.

SOA — это компонентная модель, которая связывает различные функциональные блоки приложения (называемые службами) через четко определенные интерфейсы и контракты между этими службами. Интерфейсы в SOA определяются нейтральным образом, независимо от аппаратной платформы, операционной системы и языка программирования, которые реализуют службу. Это позволяет службам, встроенным в самые разные системы, взаимодействовать унифицированным и общим способом. Сервис-ориентированная архитектура позволяет развертывать, комбинировать и использовать слабосвязанные крупномодульные компоненты приложений распределенным образом по сети в соответствии с требованиями. Сервисный уровень является основой SOA и может напрямую вызываться приложениями, тем самым эффективно контролируя искусственные зависимости в системе, взаимодействующей с программными агентами.

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

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

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

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

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

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

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

Облачная нативная облачная архитектура

Cloud Native — это использование автоматизации и архитектуры для управления сложностью системы и повышения производительности за счет создания команд, культуры и технологий. — Джо Беда, технический директор Heotio, соучредитель

Pivotal является создателем облачных приложений и запустил платформу облачных приложений Pivotal Cloud Foundry и среду разработки Java с открытым исходным кодом Spring, став пионером и первопроходцем в архитектуре облачных приложений. Еще в 2015 году Мэтт Стайн из Pivotal написал брошюру под названием «Миграция на облачную архитектуру приложений», в которой исследовались несколько ключевых характеристик облачной архитектуры приложений: приложения, совместимые с 12 факторами, архитектура, ориентированная на микросервисы, адаптивная архитектура самообслуживания, Совместная работа на основе API и антихрупкость. В 2015 году компания Google возглавила создание Cloud Native Computing Foundation (CNCF).Первоначально определение Cloud Native, данное CNCF, включало следующие три аспекта: контейнеризация приложений, архитектура, ориентированная на микросервисы, и оркестрация и планирование контейнеров с поддержкой приложений.

Облачное приложение просто определяется как приложение, созданное с нуля для архитектуры облачных вычислений; это означает, что если мы разрабатываем наше приложение с расчетом на то, что оно будет развернуто в распределенной масштабируемой инфраструктуре, наше приложение является облачным. оригинал. Поскольку общедоступное облако будет нести все большую вычислительную мощность, облачные вычисления станут основным методом предоставления ИТ-возможностей в будущем.CNCF также переопределяет облачные технологии: облачные собственные технологии выгодны для организаций в общедоступном облаке, частном облаке и эластичном построении и эксплуатации. масштабируемые приложения в новых динамических средах, таких как гибридное облако; репрезентативные облачные технологии включают контейнеры, сервисные сетки, микросервисы, неизменяемую инфраструктуру и декларативные API.

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

  • Applicationless соответствует сервисной публикации.В сервисно-ориентированной структуре вам больше не нужно подавать заявку на приложение для сервисной публикации, и вам не нужно обращать внимание на то, где находится ваше приложение.

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

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

К ключевым характеристикам облачных приложений относятся: упаковка с помощью облегченных контейнеров, разработка с использованием наиболее подходящего языка и инфраструктуры, проектирование с использованием слабосвязанного подхода к микросервисам, взаимодействие и совместная работа, ориентированные на API, службы без сохранения состояния и службы с отслеживанием состояния Четко разграничены в архитектуре, независимо от лежащего в их основе операционные системы и серверы, развернутые в гибкой облачной инфраструктуре самообслуживания, управляемые с помощью гибких процессов DevOps, возможностей автоматизации и распределения ресурсов на основе определения и политики. Нативное облако — важный путь разработки распределенных приложений. Его конечное состояние должно быть без распространения. Все проблемы, связанные с распределенными решениями, решаются облачной платформой. Разработка распределенных приложений будет такой же удобной, как и разработка традиционных приложений, или даже более удобной. .

облачная инфраструктура

Этот раздел взят изВиртуализация и оркестрация распределенной инфраструктуры》

应用基础架构变迁

виртуальная машина

Виртуальная машина состоит из определенного оборудования и виртуализации ядра, на которой работает гостевая операционная система. Программное обеспечение, называемое гипервизором, создает виртуализированное оборудование, которое может включать в себя виртуальные диски, виртуальные сетевые интерфейсы, виртуальные процессоры и многое другое. Виртуальная машина также включает в себя гостевое ядро, которое может взаимодействовать с этим виртуальным оборудованием. Гипервизор может быть размещен, что означает, что это какое-то программное обеспечение, работающее в операционной системе хоста (MacOS), как показано в примере. Это также может быть «голое железо», работающее непосредственно на оборудовании машины (заменяющее вашу ОС). В любом случае гипервизорный подход считается тяжеловесным, поскольку требует виртуализации нескольких частей (если не всего оборудования и ядра).

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

контейнер

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

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

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

В качестве автономных единиц контейнеры могут работать в любой операционной системе хоста, CentOS, Ubuntu, MacOS или даже в системах, отличных от UNIX, таких как Windows. Контейнеры также действуют как стандартизированные единицы работы или вычислений. Распространенная парадигма заключается в том, что каждый контейнер запускает один веб-сервер, один сегмент базы данных или один рабочий процесс Spark и т. д., и приложение можно легко масштабировать, просто увеличивая количество контейнеров. Каждый контейнер имеет фиксированную конфигурацию ресурсов (ЦП, ОЗУ, количество потоков и т. д.), и масштабирование приложения требует масштабирования только количества контейнеров, а не одного примитива ресурса. Это обеспечивает инженерам более простую абстракцию, когда приложения необходимо увеличивать или уменьшать. Контейнеры также являются отличным инструментом для реализации микросервисной архитектуры, где каждый микросервис представляет собой просто набор взаимодействующих контейнеров. Например, микросервис Redis можно реализовать с одним главным контейнером и несколькими подчиненными контейнерами.

Kubernetes и оркестрация

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

Однако единицы контейнеров становятся все более разбросанными, а затраты на управление постепенно растут. Спрос на инструменты оркестрации контейнеров беспрецедентен. Kubernetes, Mesos, Swarm и т. д. предоставляют мощные возможности оркестрации и планирования для облачных приложений. Они находятся на облачной платформе. , Распределенная операционная система. Оркестрация контейнеров — это процесс, с помощью которого часто можно развернуть несколько контейнеров для реализации приложения посредством автоматизации. Механизмы управления контейнерами и оркестрации контейнеров, такие как Kubernetes и Docker Swarm, позволяют пользователям направлять развертывание контейнеров и автоматизировать обновления, мониторинг работоспособности и процессы аварийного переключения.

Kubernetes в настоящее время является самым заинтересованным проектом с открытым исходным кодом в мире, Это отличная система оркестровки контейнеров для предоставления универсального сервиса. Kubernetes родился от гиганта интернет-индустрии Google.Он основан на концепции системы Borg, созданной сотнями инженеров более десяти лет.Он чрезвычайно прост в установке, а метод подключения сетевого уровня очень гибкий. Выдающаяся производительность Kubernetes и Mesos внесла революционные изменения в рабочую модель различных инженеров отрасли. Им больше не нужно смотреть на каждый сервер, просто замените его, когда что-то пойдет не так. Инженерам по развитию бизнеса больше не нужно слишком много сосредотачиваться на нефункциональных требованиях, они могут сосредоточиться только на своих собственных областях бизнеса. Разработчикам промежуточного ПО необходимо разработать надежное облачное ПО промежуточного слоя для соединения бизнес-приложений и облачных платформ.

Kubernetes, Service Mesh и Serverless совместно выводят различные уровни инкапсуляции и скрывают подробности ниже. Kubernetes представляет различные шаблоны проектирования для реализации новых, эффективных и элегантных шаблонов абстракции и управления для различных облачных ресурсов, что делает управление кластером и выпуск приложений относительно простой и подверженной ошибкам задачей. Широко распространенная микросервисная программная архитектура переносит различные сложности распределенных приложений в сервисы, и то, как осуществлять управление с помощью глобально согласованных, систематических, стандартизированных и неинтрузивных средств, стало критически важным вопросом в микросервисной программной архитектуре. Kubernetes улучшает детализацию декомпозиции приложений и в то же время использует обнаружение сервисов, управление конфигурацией, балансировку нагрузки и проверки работоспособности в качестве функций инфраструктуры, упрощая разработку приложений. Декларативная конфигурация Kubernetes особенно подходит для процессов CI/CD, и теперь существуют инструменты с открытым исходным кодом, такие как Helm, Draft, Spinnaker, Skaffold и т. д., которые могут помочь нам публиковать приложения Kubernetes.

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

дальнейшее чтение

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

Кроме того, вы можете перейти кxCompassИнтерактивный поиск и найдите нужную статью/ссылку/книгу/курс; илиМАТРИЦА Матрица артикулов и индексов кодовСм. статьи и исходный код проекта для получения более подробной информации о навигации по каталогам в файлах . Наконец, вы также можете следить за публичной учетной записью WeChat: "Медвежья технологическая дорога' для последней информации.

Категории