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

Следите за разработчиками Tencent Cloud и заранее получайте техническую информацию из первых рук👇

01. История развития архитектуры

Я твердо убежден, что для глубокого понимания технологии недостаточно просто опираться на одну или две таблицы сравнения различных измерений в Интернете. Вместо этого нам необходимо понять исторические предпосылки появления этих технологий: какие проблемы привели к их появлению. решить, и какие проблемы они решили? Какие новые проблемы это принесло и почему в итоге было устранено? Следующая часть содержания составлена ​​со ссылкой на «Архитектуру Феникса» и некоторые статьи Мартина Фаулера и других. Давайте посмотрим, как исторические волны способствуют эволюции архитектуры.

1.1 Оригинальная распределенная эпоха

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

1971 год Intel Компания разработала первый в мире микрокомпьютер MCS-4,открыл новую эру микрокомпьютеров,Компьютеры постепенно переходят от профессиональныхиз Исследовательское оборудование превратилось в предприятиеизпроизводственное оборудование。нода Использование микрокомпьютеров в коммерческом производстве сталкивается с очень большимиизвопрос：Компьютерное оборудование имеет ограниченные вычислительные и обрабатывающие возможности, что напрямую ограничивает максимальный размер информационного программного обеспечения на одном компьютере.Если бы вы родились в эту эпоху,Я считаю, что вы можете естественным образом подумать об этой проблеме и ее решении: «Сила есть, когда много людей», «Пламя сильное, когда каждый подкладывает дрова».,Простая истина применима везде,В то время колледжи и университеты、научно-исследовательский институт、То же самое происходитиз Начать изучение«Используйте несколько компьютеров для совместной работы для поддержки одной и той же системы программного обеспечения»изплан,И добился ряда результатов. Когда речь идет о распределенном, удаленный вызов неизбежен.,Итак, давайте возьмем удаленные звонки в качестве примера и поговорим об ограничениях результатов разведки в этот период.,Какая пропасть из влияний произошла.

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

Каждый должен понимать «UNIX История «войны системных версий», чтобы избежать повторения той же «войны», мы несем ответственность за формулировку UNIX Фонд открытого программного обеспечения и основные производители компьютеров совместно разработали стандарты системных технологий. DCE/RPC Эта далеко идущая спецификация вызова удаленных служб также признана современной RPC Один из создателей. Поскольку сам Фонд открытого программного обеспечения несет ответственность за UNIX Разработка системных технических стандартов, в данном контексте DCE/RPC. с сильным UNIX«Простой первый принцип»изфилософия дизайна,По умолчаниюраспределенныйсредаиз Служитьвызов、ресурс Доступ и другие операции должны быть максимально прозрачными.,чтобы разработчикам не приходилосьсосредоточиться наони посещаютизметод илиресурсда Также расположен локальнодаудаленный。

Однако в то время эта слишком идеальная цель столкнулась со слишком большим количеством технических проблем. «Удаленный вызов» полностью отличался от «локального вызова» по сложности: обнаружение услуг, балансировка нагрузки, автоматический выключатель, изоляция, переход на более раннюю версию, аутентификация и ряд таких проблем. так как авторизацию нужно решать срочно. Что достойно восхищения, так это то, что, несмотря на множество трудностей, DCE создала с нуля большое количество протоколов для решения этих проблем и действительно стала относительно «прозрачной». Однако в распространении есть еще одна фатальная проблема — проблемы, вызванные. Проблемы с производительностью сети.

Давайте сделаем вывод：Производительность оборудования недостаточна——>использоватьраспределенный Служить——>распределенныйизудаленныйвызовчто приводит к снижению производительности(Вопреки первоначальному намерению устранить недостатки производительности оборудования)——>Намеренно путем объединения нескольких запросов и т. д.(Разработчики должны понимать, что они пишут распределенные программы, что противоречит прозрачности и простоте DCE.)Уменьшите потери производительности сети——>людииз Возможности становятся масштабируемымиизограничение。В это времяраспределенный Судя по результатам, это не удалось.,Компромисс между дизайном и производительностью делает простоту и прозрачность пустыми разговорами.

Когда мы играем в игры и побеждаем BOSS, есть еще один способ решить проблему, которую невозможно решить вызовом людей — криптоновое золото. В 1980-е годы закон Мура неуклонно вступал в силу, и производительность микрокомпьютеров увеличивалась с поразительной скоростью вдвое. каждые два года. Поскольку дистрибутив полон противоречий и компромиссов, так что просто добавьте больше денег в обмен на лучшие машины, и наступит монолитная эра.

Увеличение масштаба системы за счет повышения производительности одного компьютера

1.2 Эпоха монолитной архитектуры

До появления микросервисов «монолит» не считался архитектурой, поскольку он был слишком «простым» и «естественным». Даже если бы я захотел найти книгу о лучших практиках монолитной архитектуры, я не смог бы ее найти. Сегодня во многих книгах единая сущность рассматривается как «раковая опухоль», и существует даже мнение, что микросервисы более продвинуты, чем единая сущность. Однако так ли это на самом деле?

первый,Сначала нам нужно уточнить мономерда Что：«Одиночный» означает только то, что все вызовы основных процедур в системе являются внутрипроцессным взаимодействием.,Межпроцессное взаимодействие не происходит,Вот и все.Так В процессевызовда Грех?？да Рак?？Это конечно недаиз。На самом деле его не будетлюдивернотыобъяснять：Ты"Hello, Мир!» Вы не можете использовать монолитную программу, потому что монолитная архитектура — это рак.

Существует очень популярный аргумент, что «монолиты нелегко расширять». Давайте сосредоточимся на том, верна ли эта точка зрения. Давайте поговорим об этом с двух сторон: расширение производительности и расширение функций. Давайте сначала поговорим о расширении производительности: это слишком просто. Развернуть несколько копий службы и добавить сервер балансировки нагрузки перед ней, чтобы равномерно распределить трафик. Достигнет ли это расширения? Давайте поговорим о расширении функционала: я никогда не видел крупномасштабного системного кода, который не был бы многоуровневым по вертикали. Spring Мы все знаем, что написание службы в основном соответствует стандартному MVC Модель является многоуровневой для облегчения расширения; по горизонтали мы также можем разделить ее на разные модули по функциональным и другим измерениям (отсутствие связи или небольшое количество связи между модулями). Примечание: разделение модулей не означает, что это не единый сервис, один сервис. Это не означает, что в системе только один модуль), и каждый модуль можно повторять независимо. С этой точки зрения монолитные сервисы не уступают микросервисам с точки зрения «масштабируемости», а даже лучше с точки зрения разработки и отладки. Действующий единый сервис также имеет свои ограничения. Например, есть. C++ Внедренная система должна реализовывать часть AI Функция, очевидная Python Больше преимуществ, C++ казнен в Python Хотя его можно реализовать, он явно не так хорош, как независимый микросервис. Python модуль приходитизмилость。Оглядываясь назад, можно сказать, что мнение о том, что «монолитные сервисы нелегко расширять», не совсем верно.

Одиночный блок также имеет хорошую масштабируемость.

«Грех из одного корпуса» и «Большой из одного корпуса»,Главный грех «большого единого подразделения Служить» — изоляция. Приведите пример,Случайное написание ОШИБКИ приведет к сбою программы.,Если дамикросервисы приведут к сбою только одного модуля,Объем влияния зависит только от функции этого модуля.,Можетдаеслидамономер Служить,Весь код использует одно и то же пространство процесса,Сбой в какой-то момент напрямую приводит к сбою всего процесса.,это влияниеиз Область применения шире。Вот мы здесь Можетс простотойизобъяснять：Единый блок «Служить» проще и эффективнее в том же процессе, но за счет потери возможностей изоляции и технической масштабируемости.А какой из этих двух пунктов легче, а какой нет?Может Обобщать,От вас зависит, небольшой это магазин или большой супермаркет.

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

Создать крупномасштабное, но при этом надежное программное обеспечение очень сложно. Согласно закону Мерфи, если что-то (ОШИБКА) может случиться, то оно обязательно произойдет.,Добавьте непредсказуемости и «событий черного лебедя»,Поскольку масштаб команды исследований и разработок продолжает расширяться,,система недоступна и вероятность будет бесконечно увеличена,Приведу крайний пример: если в компании 100 000 человек,У всех, кто пишет системаиз, доступность 99,999%.,Но когда они вместе написали сингл «Служить».,Тогда доступность будет равна 99,999% из 100 000 раз.,Примерно равна 36,8%,Эта система просто недоступна,Более того, люди ненадежны.,В это времямономер Служить Плохая изоляцияиз Основные недостатки。микросервисы ПучокТочка зрения на построение надежной платформы изменилась с «стремления совершать как можно меньше ошибок» на «ошибки неизбежны».Уменьшите масштабы ненормального из-за разделения Служить,Что касается того, почему микросервисы могут повысить доступность систем, можно помочь понять пример: система человеческого тела состоит из отдельных ячеек (микросервисы).,В большинстве случаев коллапс одной или группы клеток не повлияет на нашу жизнь.,Наше нечеловеческое тело является примером ненадежной изсистемы, построенной из ненадежных частей.

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

Архитектура дымохода:На самом деле здесь нет Чтоглубокийизтеория,Не что иное, как итерации с системойиз,Разделить систему на несколько,После разделения они независимы друг от друга и не имеют делового взаимодействия.,Поэтому использование такой Архитектурасистемы еще называют островной информационной системой.,Вопрос: Действительно ли существует такая ситуация?,Если есть высокая вероятность, то с самого начала она будет спроектирована как двухсистемная.,Поскольку это Две системы не поместятся в один корпус. Если их соединить, то они неизбежно станут дапотными. чтоэти двоесистемаподелился некоторымиресурсиз,Например, хранение、Разрешения、Номер счета и т. д.

Микроядерная архитектура:Тип дымохода Архитектура Редко существует в реальности,потому После разделения существует высокая вероятность того, что изсистема и система будут иметь совместное использование ресурсов. В этом случае будет щедро собрать данные, ресурсы и публично служить в ядро, которое является взаимозависимым от всей бизнес-системы. конкретная бизнес-система основана на подключаемом модуле (Plug-in Modules）из Форма существует,Обратите внимание, что ядро ​​микроядра Архитектура лежит в микроядре.,Ядро отвечает только за общую бизнес-логику.,Не включает пользовательский код для особых ситуаций, особых правил или обработки сложных условий.,Без реализации плагина это должна быть микроядерная архитектура.,например MySQL Просто движок хранения сделан в виде плагина, и MySQL из Server Уровень является основной функцией и не может считаться микроядерной архитектурой. Эта архитектура существует до сих пор, Eclipse IDE Просто типичный представитель да, скачайте базовую версию Eclipse Продукт предоставляет только простой редактор.,После добавления плагинов он становится легко настраиваемым и практичным инструментом разработки программного обеспечения. Конечно, микроядерная Архитектура также имеет свои ограничения.,Так как заранее узнать какие плагины есть невозможно,Таким образом, при реализации плагина по умолчанию не предусмотрена возможность взаимодействия с другим плагином.,Плагины могут взаимодействовать только с ядром.

В настоящее время также широко используется в страховой отрасли.микроядро Архитектура,Из-за разных регионов, времени и событий правила подачи заявок очень сложны.,Правила урегулирования претензий превратятся в сложный комок грязи,Изменение одного правила влияет на другие правила,Разработка и тестирование крайне хлопотны.。использоватьмикроядро Архитектурамодель Можетдля решения многих из этихвопрос：

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

1.3 Эра архитектуры SOA

В эпоху первоначальной распределенной архитектуры упоминалось параллельное развитие мономерной и распределенной архитектуры. Когда монолитная архитектура исследует способы разделения и развития в архитектуру, управляемую событиями, распределенная архитектура также развивается постепенно, SOA. Скоро посадка Архитектураизэтап。

Новое в «СОА» «Управление», мне не очень понятно, что такое управление, SOA. Вроде бы то же самое, что и микросервисыда, и явной разницы нет. SOA (сервисно-ориентированный Architecture）да Для Служитьиз Архитектура……Жаль, что так много определений.,Я не нашел авторитетного или четкого объяснения,Но, судя по резюме, я чувствую, что все стороны достигли консенсуса, по крайней мере, по двум пунктам.

1. Для Служитьиз Архитектура «Служить» да относится к коду и данным, необходимым для выполнения полных, независимых бизнес-функций.,Обратите внимание на «код» и «данные».,Другими словами, да — самостоятельная функциональная единица.,Здесь из Служить очень похоже на событийно-ориентированную Архитектуру изребеноксистемы.,Это гораздо грубее, чем «Служить» в том, что мы сегодня называем измикросервисами.
2. SOA иззида повторного использования, и для этой цели был разработан ряд стандартов. Служить использует общие стандарты интерфейса и шаблоны архитектуры, поэтому его можно быстро интегрировать в новые приложения. Это избавляет разработчиков приложений от необходимости перерабатывать существующую функциональность, как это требовалось ранее, поскольку что существуют общедоступные стандарты интерфейсов и разработчикам не нужно понимать, как подключить существующий функционал 。

Посмотрите на это так SOA Он не решает новую проблему. Он по-прежнему предвидит трудности в решении проблемы, когда она была впервые предложена, но все равно решает проблему. SOA Иголкаверно Этивопросизрешатьплан Более конкретный、Более работоспособный,и сформировать пакет норм и стандартов,По сравнению с предыдущей версией Chimney Архитектура, микроядерной Архитектурой, событийно-ориентированной Архитектурой.,SOA Кажется более конкретным. Приведем несколько примеров: SOA. уточнил вопрос принятия SOAP Как удаленный вызов по протоколу, явное использование корпоративной шины (ESB) Осознание коммуникационного взаимодействия между различными подсистемами и т. д. с технической точки зрения SOA Успешно решили основные технические проблемы, возникшие в распределенной среде, затем SOA Почему их постепенно заменяют микросервисы?

потому что SOA Он слишком тяжелый, слишком строгий, определение пакета спецификаций приводит к чрезмерной сложности, а стоимость реализации очень высока. Звоним удаленно Служить (Remote Procedure Call,RPC）Например：Первоначальной целью RPC было сделать вызов удаленных методов таким же простым, как вызов локальных методов.,Некоторые люди до сих пор так думают,На самом деле сегодняизбольшинство RPC Технологии больше не преследуют эту цель, потому что что общение не да без затрат. Эндрю Tanenbaum Профессор опубликовал статью в 1987 году. Основной аргумент заключался в том, что локальные вызовы и удаленные вызовы следует рассматривать одинаково. Это привело к ошибке направления. Если сделать прерывистые вызовы прозрачными, это усложнит работу программиста. Эта точка зрения продолжала обсуждаться. в последующие годы, пока он не стал знаменитым Sun Большие боссы компании обобщили идею «восьми смертных грехов выполнения вычислений через Интернет», и она стала широко признанной и понятной. RPC да уровень языка по характеристикам, а не уровень дасистемы по характеристикам。

Поскольку это RPC да Уровень языка—функции, языков программирования так много, что идеально иметь единый набор спецификаций для их решения. RPC Три основных вопроса о том, как представлять данные, передавать данные и определять методы (фактически до сих пор RPC Протоколы все в хаосе, посчитайте их сейчас и они популярны. RPC Сколько соглашений?). Разработка этой спецификации очень сложна, наше внимание сосредоточено на на Исторический момент: W3C Выпущен в 1998 году. SOAP 1.0 осознать Web Service。SOAP В то время он был очень популярен. Хотя сейчас кажется, что он не идеален с точки зрения производительности и простоты использования, это не причина его упадка, а причина его упадка. что слишком «идеалистично» и рассчитывает решить все проблемы, которые могут возникнуть в расчетах, для которых определение огромно Web Service Стоимость изучения и использования семейства протоколов очень высока, и они оторваны от практики людей. SOAP Оно неизбежно будет постепенно погружаться в длинную реку истории. МЫЛО как SOA Быть на сцене Архитектуры – важное условие, и его упадок также означает SOA Архитектураизотклонить。

Оглядываясь назад на лекцию «Первоначальная распределенная эра»: Unix DCE Предложил цель распределенного Служитьиз, «чтобы разработчикам не приходилось беспокоиться о том, является ли Служитьда удаленным или локальным, и могли прозрачно вызывать Служить или получать доступ к ресурсам». Но сейчас SOA Это первоначальное намерение было отклонено, поэтому наступила эра микросервисов.

1.4 Эпоха микросервисной архитектуры

Настоящий рост микросервисов начался в 2014 году. В то время измикросервисы явно отличались от того, когда они были впервые предложены 9 лет назад. Сначала микросервисыда SOA из Облегченная версия, т.к. SOA слишком обременительный,Такмикросервисы Просто постарайтесь отказаться от этого, насколько это возможно. В SOA вы можете отказаться от всех ограничений и спецификаций.,Вернитесь к прозрачности и простотеиз Намерение новичка；Конечно сейчасмикросервисы Уже расстались SOA Станьте полностью независимым архитектурным стилем, Мартин. Fowler 《Микросервисы: A Definition of This New Architectural Объяснение микросервисов в статье «Термин» достаточно подробное и здесь повторяться не будет.

Итак, микросервисы и SOA Какая разница? Действительно, особого смысла обсуждать этот вопрос нет, потому что чтоотношения между ними слишком тонкие, говорят некоторые. ESB да SOA по характеристикам это на самом деле да слишком условно, микросервисы заброшены SOA Все в Можетотказатьсяиз Стандарты не представляютмикросервисы Определенно нет,не забываймикросервисыдабесплатноиз。нам просто нужно знать：Микросервисы выводятся взамен «нормативных стандартов» «практическими стандартами», Ориентированными на SOA решаются проблемы распределенного обслуживания в микросервисах, и разработчики могут свободно выбирать в зависимости от реальной ситуации.микросервисыда Обычный разработчикизкарнавал,Вы можете делать все, что захотите;,верно Архитектураразделениеиз Требования к мощности подняты до беспрецедентного уровня。микросервисы – это не панацея,Не надо его слишком мифологизировать,Неизбежны проблемы, возникающие в распределенной архитектуре, такие как обнаружение регистрации, управление отслеживанием, балансировка нагрузки, передача данных и т. д.,Это нужно решить или да нужно решить. Но да, в эпоху облаков,микросервисывводить новыеиз Возможность：Облачные технологии позволяют микросервисам развиваться от независимого реагирования на распределенные проблемы на уровне программного обеспечения к совместному реагированию между программным и аппаратным обеспечением.,Также известна как «эра постмикросервисов».

Когда проблемы не ограничиваются использованием программных методов, многие задачи становятся проще. Например, программное обеспечение можно масштабировать и расширять с помощью команд Служить.,Разве аппаратное обеспечение не может создавать соответствующие серверы приложений, балансировщики нагрузки и другую инфраструктуру, просто печатая на клавиатуре? Облако покупки криптонного золота Служить также может решить проблему,Технология виртуализации заставляет границы между программным и аппаратным обеспечением стираться.,Как только оборудование виртуализации станет достаточно гибким,Тогда все технические вопросы, не имеющие отношения к бизнесу, можно будет решить в рамках инфраструктуры.,Пусть исследования и разработки сосредоточатся на развитии бизнеса. Позже родилось множество новых концепций, таких как облачные решения.,нода По сути, то, что им нужноизцели имикросервисы Нет Чторазница。Достижения, достигнутые в эпоху микросервисов, неотделимы от огромного вклада технологий виртуализации.

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

1.5 Эра бесслужения

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

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

02. Монолит или микросервис

Мы потратили много времени, рассказывая об эволюции Архитектуры, чтобы выжить в волне истории.,Понять смысл и причины устранения каждой Архитектуры.,Решите реальные проблемы, с которыми мы сталкиваемся сегодня. Споры о том, хороша или плоха Архитектура, существуют и по сей день.,Самая горячая дискуссия идет о мономере дамикросервисы. Сначала поговорим о выводах,Если бизнес идет хорошо,Когда сложность системы вырастет до определенного уровня, неизбежно произойдет миграция от единого корпуса к микросервисам.,но до этого,Рекомендую монолитный.Давайте посмотрим нижеда Что Сложность драйверасистемаотмономер Кмикросервисымигрировать。

2.1 Зачем использовать микросервисы

Мир процветает,Все здесь ради прибыли; мир в смятении;,Все ради выгоды. Платите только тогда, когда есть прибыль,Как уже говорилось выше, поскольку мономер да настолько прост, зачем нам переходить на микросервисы? Для лучшей производительности? микросервисы можно свободно расширять и сжимать,Очень хорошо справляется с давлением производительности, вызванным развитием бизнеса.,Вопрос да С развитием облачных вычислений из,Одиночный блок также может быть развернут в кластерах и легко расширяться и уменьшаться.,И цена оборудования становится все дешевле и дешевле.,дажемономер Служитьтакже уменьшено RPC Причина вызванной потери производительности может показаться верной, но на самом деле она несостоятельна. Если вы выбираете распределенный только ради производительности, вам следует 40 много лет назад“оригинальныйраспределенныйэпоха”преследовалииз Цель。Спрос не такой.,Но ничего страшного, если ты этого не сделаешь,Точно так же должны быть причины для сложной миграции микросервисов.

2.1.1 Когда факторы личных способностей внутри команды становятся очевидными препятствиями для развития команды

Этот вопрос легко объяснить,Я уже приводил крайний пример: 100 000 человек пишут сингл «Служить».,если У всех, кто пишет системаиз, доступность 99,999%.,Тогда доступность этого единственного подразделения Служитьиз может достигать лишь 36,8%. Более того, никто не может гарантировать, что все привлеченные люди будут профессиональными и надежными.,Даже если сможешь, люди все равно нестабильны.,Под влиянием эмоций, состояния здоровья и межличностных отношений вы можете совершать всевозможные ненадежные поступки.,Трудно сделать целое Может Зависит отиз Большойсистема。Поскольку в мономере Архитектура нет физического разделения отношений между «целым» и «частью».,При возникновении ошибки эффективного метода блокировки не существует.,А небольшое количество экспертов не имеет возможности контролировать чью-то разработку определенной незаметной строки кода для создания ОШИБКИ и имеет глобальное влияние.

В этом случае,Уровень членов команды варьируется,Или команда выросла очень большой,микросервисы — лучший выбор. Под мономером Архитектура,система Качество может быть гарантировано в максимально возможной степени только за счет НИОКР и мер по управлению проектами.,А микросервисы уже предполагают, что система обязательно выйдет из строя.,Сама Архитектура стремится к независимости и автономии.,Позвольте экспертам высокого уровня разрабатывать и поддерживать критически важную инфраструктуру и бизнес-операции.,Что касается ошибок в других непрофильных функциях, то их можно восстановить, полагаясь на базовые настройки и возможности самовосстановления.,Сделав десять тысяч шагов назад, даже если удар невозможно восстановить, его все равно можно контролировать в небольшом диапазоне.,И система в целом по-прежнему остается высокодоступной.

2.1.2 Когда язык или техническая основа становятся очевидным ограничением для разработки системы.

Язык – это не хорошо и не плохо,Но подходит оно или нет?,Приведу очень простой пример: развитие искусственного интеллекта в последние годы идет полным ходом.,Все программное обеспечение обдумывает, как объединить искусственный интеллект, чтобы обеспечить превосходную эффективность.,Позвольте бизнесу войти во вторую кривую роста。нода Небольшое исследование покажет Python для AI Обучение не имеет аналогов на других языках, если используется оригинальная система. C++ Реализация, в настоящее время развертывание разных стеков технологий и разных фреймворков для реализации функций — это не вопрос того, хотите вы этого или нет, но выбора и неизбежности нет. Конечно, оно должно быть там C++ выполнить в Python Да, но затраты на обслуживание, вызванные использованием этих уловок, неизмеримы.

2.1.3 Когда организация и персонал Архитектура становятся существенным ограничителем развития организации

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

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

2.1.4 Резюме

Мы должны осознать, что микросервисы имеют издержки.,Если вы воспользуетесь таблицей здесь, чтобы сравнить, какие проблемы должны решать микросервисы в разных широтах, это может не дать вам прямого ощущения.,подда Знаменитое фото в Интернетеизкартина：Netflix В 2014 году компания обнародовала диаграмму связи вызовов. Я считаю Netflix 中Нет一个люди Можетчтобы уточнитьсистемаиз Служитьмеждувызовсвязь,Это черная дыра,Если микросервису необходимо изменить соглашение,Трудно определить, какие доверяющие стороны должны быть известны для внесения совместимых изменений.

Netflix выпустил граф звонков в 2014 году

После того, как основная ценность микросервисов будет разделена, изсистема может обеспечить гибкую разработку частичной или отдельной услуги.,Самое главное — эффективно отделить систему для физической изоляции.,Построение надежной изсистемы из ненадежных измикросервисов с помощью самодельных средств.,Однако, хотя микросервисы решают одну проблему, они также порождают множество дополнительных проблем.,Если баланс здесь неудовлетворительный, это приведет к снижению производительности.,Фундаментальная мотивация любой трансформации – «выгоды перевешивают затраты».,поэтому«Маленькая и средняя мономерная Архитектура – ​​лучшая из Архитектуры»,Только когда бизнес развился до определенного уровня,Кривые производительности мономерной Архитектуры и микросервисов Архитектура достигли пересечения,В это время выгодно запускать микросервисы. А есть ли у этого да эта точка пересечения, как об этом судить?,Вы можете проверить, отображаются ли указанные выше три пункта.

Источник изображения "Архитектура Феникса"

2.2 Предварительные условия для использования микросервисовиз

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

2.2.1 В организации есть специалисты, полностью разбирающиеся в микросервисах.

Я упомянул об этом, когда говорил об эпохе микросервисов.,микросервисы дают программистам полную свободу,Но преподаватель архитектуры выдвинул беспрецедентно высокие требования. В настоящей команде исследований и разработок не все являются мастерами,Не каждый будет изучать такие вопросы, как расширение, аутентификация, изоляция и т. д., не имеющие никакого отношения к конкретному бизнесу.,большинстволюди Обычные программисты тожеда Больше внимания уделяйте бизнес-кодуизписать。Можетдаиспользоватьмикросервисыно несосредоточиться Эти проблемы принесут огромные катастрофы. Приведу несколько примеров: Как маршрутизировать между микросервисами? Как выполнить аутентификацию разрешений между микросервисами? Как настроить таймаут микросервисов, чтобы избежать лавины повторных попыток? Какие стратегии используются для расширения или сокращения пропускной способности при изменении трафика? Если эти проблемы не решить, это, скорее всего, отразится на работоспособности всей системы. Команды, использующие микросервисы Архитектуры, часто сталкиваются с такой ситуацией: необоснованное разделение микросервисов Архитектуры приводит к большому количеству входов и выходов. Добавление поля необходимо изменить. N модули, тесты N интерфейс,Крайне неэффективно. Так что если вы хотите воспользоваться преимуществами микросервисов,Во-первых, эксперты должны признать риски,Надежная конструкцияиз Архитектура。Если во всей команде не хватает специалистов, способных поддержать костяк микросервисов Архитектура,Выгод от вынужденной миграции недостаточно, чтобы компенсировать издержки, связанные с увеличением сложности.

2.2.2 система должна иметь возможности автоматизации и мониторинга измерений с целью автономности.

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

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

2.3 Как практиковать микросервисы

Как практиковать микросервисы — огромная тема,Гораздо больше, чем одна статья может нести.,Книги по микросервисам включают в себя «Дизайн микросервисов», «Шаблон проектирования архитектуры микросервисов», «Практику разработки распределенной архитектуры микросервисов» и многие другие.,Здесь я лишь кратко упомяну несколько моментов, которые стоит обсудить с вами:

Если команда маленькая,Начало новогоизсистемаиз Я думаю, нам следует оставаться твердымиизвыбиратьмономер Служить。В это времякоманда надеждыдляделатьиспользоватьизмономериз Архитектураразделениеиметь достаточноиздоверять。На самом деле долгосрочные цели часто ставятся перед бизнесом в начале создания проекта.из Цель,Но с технической точки зрения все равно должно исходить из текущей ситуации.,Затем вносите своевременные коррективы в Архитектуру по мере развития бизнеса. Не надо винить Архитектуру, когда бизнес нужно дробить, когда бизнес развивается до определенного масштаба: «Я вначале сказал, что надо использовать микросервисы.,Вместо использования единого объекта, отсталого, как «из Архитектура», подумайте об этом объективно.,По сравнению с началом работы с микросервисами,Рабочая нагрузка сэкономлена за счет использования одного устройства на ранней стадии,По сравнению смигрироватьработа принеслада Хорошая сделкаиз。У нас тоже должно быть этоизсознание：Мы не можем создать что-то, что никогда не изменится и не будет идеальным.,Архитектура неизбежно меняется с развитием бизнеса.

Если размер команды больше,Вначале он состоит из множества более мелкихиз Команда завершаетсистема,Тогда давайте не будем бороться с Законом Конвея. Система должна быть разделена по бизнес-возможностям на относительно независимые службы и нести ответственность за разные небольшие команды.,Эти Служитьмеждуизвзаимодействиеиспользоватьединыйизспецификация。иРекомендую эти Служитьда децентрализованно,Другими словами, каждая команда может иметь свой собственный выбор при разработке программного обеспечения. Каждой Служить рекомендуется управлять своей собственной базой данных.,Даже если эти данные появятся в разных из Служитьиз,Но каждому Служить нужны разные атрибуты.,Также рекомендуется поддерживать его самостоятельно, чтобы команда могла выполнять итерации независимо. Фактически каждая небольшая команда поддерживает небольшую дочернюю систему.,Так Обратитесь к первому пункту«Если команда меньше»часизв заключение,Каждый небольшой тимбилдинг Служить также начинается с одиночного Служить Архитектура.,Нет необходимости дробить несколько более мелких из Служить с самого начала. Моя команда также изучает и практикует микросервисы.,Основные функции определенного бизнеса по-прежнему монолитны.,Бизнес растет уже три года.,Еще нетпотому что Использование мономера существенно замедляет эффективность в определенный момент.

03. Хвост

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

Ссылки

1. «Архитектура Феникс: Построение надежной и масштабной распределенной системы» Чжоу Чжимин
2. 《Microservices: A Definition of This New Architectural Term》 Martin Fowler、James Lewis

-End-

Автор оригинала ｜У Цзюньцзе