В этом выпуске у нас есть эксклюзивное интервью с Лян Синем, главой CreditEase Development Platform (SIA), чтобы поговорить с вами об архитектуре микросервисов и стратегии ее применения на предприятиях.
Часть 1: Рождение, эволюция и стратегии применения микросервисов
Репортер: В последние годы метод проектирования микросервисной архитектуры предлагался, практиковался и внедрялся на все большем количестве предприятий, но те, кто плохо знаком с микросервисами, все еще не знают, с чего начать. Можете ли вы рассказать о разработке и характеристиках микросервисов на основе истории развития архитектуры программного обеспечения.
Лян Синь: Микросервисы — это, по сути, стиль архитектуры.Если вы хотите понять микросервисы, я думаю, вам нужно понять разработку всей архитектуры.
Архитектура программного обеспечения постоянно развивается. Если мы вернемся на 20 лет назад, то в то время модель C/S была основным направлением исследований и разработок в области корпоративного уровня, а программное обеспечение для разработки, такое как PB и Delphi, было основным направлением разработки корпоративных приложений.
Со временем мы обнаружили, что у стандартизированного клиента есть некоторые недостатки, например, у меня тысяча терминалов, а версия с апгрейдом требует обновления каждого терминала, что очень хлопотно. Затем исследования и разработки корпоративных приложений начали учиться в Интернете и использовать браузер в качестве клиента, чтобы избежать этой проблемы. Поэтому архитектура B/S на основе браузера постепенно становится популярной.
В начале это был ASP, а потом появился JSP.Из-за прекомпилированного режима Java производительность была значительно улучшена, а затем все более популярной стала архитектура J2EE, основанная на языке Java. На данный момент архитектура претерпела переход от традиционной модели C/S к модели B/S.
Исходная архитектура B/S представляет собой в основном единую архитектуру, каждая система относительно независима, и им часто не нужно взаимодействовать друг с другом, а если и есть какое-то взаимодействие, то большинство из них находится на уровне данных. На этом этапе инструменты ETL быстро разрабатывались для решения таких хранилищ данных.
С появлением все большего количества корпоративных приложений взаимосвязь между системами становится все теснее и теснее, и все больше требований к интерактивному доступу между системами в реальном времени. В это время инженеры обнаружили, что независимо от того, на каком языке разрабатывается программное обеспечение, оно в основном поддерживает язык, называемый XML, поэтому они предложили техническое решение для взаимодействия в реальном времени: удаленные вызовы между корпоративными прикладными системами через язык XML. В результате была предложена концепция SOA, и WebService стал популярным.
Когда пришла вторая волна Интернета, чтобы адаптироваться к более гибкому развитию бизнеса, многие компании заменили исходный громоздкий WebService на протокол HTTP и стиль архитектуры Restful, а на смену XML пришел лаконичный и понятный JSON. В то же время в архитектуре SOA часто используется технология служебной шины, что, несомненно, добавляет очень проблемное узкое место в архитектуру системы. Если механизм регистрации и обнаружения используется для прямого вызова сервисных процессов, он больше подходит для разработки корпоративных приложений. Это исторический контекст микросервисной архитектуры с технической точки зрения.
Существует два основных принципа определения микросервисов в «Проектировании микросервисов»: слабая связанность и высокая согласованность. То есть «собирать вещи, которые изменяются из-за одних и тех же факторов вместе, и разделять вещи, которые изменяются из-за разных факторов». его размер аналогичен, в то же время он может соответствовать принципу «слабой связи и высокой сплоченности».
Микросервисы имеют много преимуществ, если назвать лишь некоторые из них.
Неоднородность: микросервисы могут помочь нам легко внедрять различные технологии и понимать преимущества этих новых технологий. Эксперименты с новой технологией обычно сопряжены с риском, но если вы уменьшите количество услуг, всегда будет момент, когда вы сможете выбрать услугу с наименьшим риском для внедрения новой технологии и снижения риска.
Отказоустойчивость. Очевидно, что микросервисы могут хорошо справляться с недоступностью сервисов и функциональным ухудшением, потому что они могут формировать множество узлов.
Изоляция. Архитектура микрослужб разбивает систему на независимые операционные блоки, что обеспечивает лучшую изоляцию системы. Независимым микрослужбам легче обнаруживать и изолировать проблемы при возникновении исключений. Изоляция также является основой для масштабируемости службы.
Масштабирование: огромный монолитный сервис можно масштабировать только целиком, даже если проблемы с производительностью возникают только у нескольких модулей в системе, необходимо масштабировать всю систему. Архитектура микросервисов может горизонтально масштабировать различные модули в соответствии с потребностями в производительности.
Простое развертывание. В архитектуре микрослужб развертывание каждой службы является независимым, что позволяет быстрее развертывать определенные части кода. Кроме того, проще быстро откатиться в случае сбоя службы, а гибкая доставка и развертывание обеспечивают лучший опыт реагирования на потребности бизнеса.
Гибкость: в микросервисной архитектуре система будет открывать множество интерфейсов для внешнего использования, при изменении ситуации приложения можно строить по-разному. Разложение монолитного приложения на несколько микросервисов может обеспечить многократное использование и компоновку.
Репортер: Сообщается, что ранее вы опубликовали статью «Почему компании необходимо создать единую структуру разработки?» Как вы думаете, для решения какой проблемы компания устанавливает единую структуру разработки?
Лян Синь: Это вопрос, где доброжелательный видит благожелательный, а мудрый видит мудрость. Отправная точка у всех разная. Некоторые люди могут выступать за необходимость объединения, а другие могут отвергать объединение. Основываясь на своем опыте и практике, я думаю Компания представляет собой единую структуру развития.
За последние десять лет развитие Интернета подорвало многие традиционные отрасли, и появилось много новых компаний. Это связано с быстрым ростом экономики Китая и бурным развитием Интернета. Однако этот быстрый процесс развития сопровождается недостатками, которые нельзя игнорировать:
Недостаток 1: Самораспространение
В процессе бурного развития компании часто возникает такая цепочка. Добавить новую часть бизнеса -> нанять старший технический персонал -> создать техническую команду вокруг этого коллеги -> бизнес в основном отвечает за эту команду, а затем формируется замкнутый цикл. Когда возникает необходимость взаимодействовать с другими предприятиями, зачастую это вопрос самоопределения между техническими лидерами. Это создает состояние самовоспроизводства.
Недостаток 2: контрольные барьеры
С быстрым развитием масштаба бизнеса эта команда быстро сформировала отдел.Лица, принимающие решения в команде, обычно учитывают свои собственные интересы и надеются свести к минимуму зависимость от внешних отделов, будь то выбор технологии, установление спецификации, выбор компонентов и операционная среда в состоянии контролировать себя.
Недостаток 3: Эффект скалы
Как только будет сформирована такая техническая атмосфера, влияние одного сотрудника на один проект станет очень огромным. Продукт часто становится неустойчивым из-за ухода одного или двух основных сотрудников, и, в конце концов, приходится заново разрабатывать новый продукт.
Недостаток четвертый: пустая трата ресурсов
Когда каждая команда пытается построить свой собственный законченный процесс НИОКР. На технические исследования, разработку продуктов и управление эксплуатацией и техническим обслуживанием будет потрачено много ресурсов.
Недостаток пятый: трудно оценить
Как измерить, кто лучше, шеф-повар из провинции Сычуань или шеф-повар из провинции Шаньдун? Когда каждая команда представляет собой замкнутый цикл, использующий разные технологические стеки, разные технологические компоненты, разные методы обслуживания и спецификации, невозможно судить о производительности команды по выходной эффективности, и очень сложно установить показатели KPI.
Создание единой платформы разработки на уровне компании может эффективно решить вышеуказанные проблемы. С технической точки зрения, если можно будет сформировать единую платформу разработки на уровне компании, это принесет большие преимущества в реальном производственном процессе.
Во-первых, можно избежать повторяющихся технических исследований и сэкономить трудозатраты. Создайте базовую архитектурную платформу разработки под командой проекта, извлеките общие технические проблемы и передайте их специальной команде для их решения, чтобы команда проекта могла посвятить свою энергию бизнесу.
Во-вторых, стандартизировать технические спецификации и повысить качество продуктовых проектов. Для инженерного дела нужны тысячи людей, а не тысячи людей. После принятия единой платформы разработки может быть сформирован стандартизированный режим вывода технологий с точки зрения технологических стеков, технологических компонентов, решений для реализации технологий и даже спецификаций кода Эффект стандартизации заключается не только в быстром повышении эффективности разработки, но и в продукт Значительное улучшение качества.
В-третьих, можно проводить технические осадки, чтобы улучшить общие технические возможности компании и не попасть в ловушку способности одного человека решать проект. Развитие технологий происходит за счет непрерывного накопления и осаждения технологий, а также создания единой структуры разработки (платформы) на уровне компании.Команда проекта проводит собственные исследования и разработки проекта на основе этой платформы и больше не нуждается в сосредоточиться на реализации базовой технологии, но необходимо сосредоточиться только на бизнесе. Более того, чтобы лучше удовлетворять технические потребности проектной группы, коллеги, которые сосредоточены на платформе, постоянно улучшают платформу, чтобы достичь цели накопления и осаждения технологий.
Наконец, входные и выходные данные НИОКР могут быть измерены, а команда НИОКР может эффективно управляться и оцениваться. Когда устанавливаются стандартизированные технические спецификации, основанные на одной и той же платформе разработки, кодовая реализация бизнес-функций может быть относительно эффективно оценена и рассмотрена, и можно избежать различных проблем, вызванных различиями в технической реализации. Это огромная помощь для формулирования и оценки KPI.
Такую идею я выдвинул еще в позапрошлом году, и после более чем года напряженной работы уже добился определенных результатов в компании. Наша единая платформа разработки позиционируется на техническом уровне, и ее основной целью является унификация технической базы и инструментов разработки, используемых в исследованиях и разработках связанных продуктов и реализации проектов внутри компании, эффективное улучшение единой технической поддержки, формирование непрерывного средства технологии. накопление и улучшение технического персонала.Использование и снижение зависимости от персонала и, в конечном итоге, улучшение крупномасштабных и конвейерных производственных мощностей программного обеспечения.
Репортер: В последнее время постоянно упоминаются такие слова, как «Spring Boot» и «Spring Cloud». Основываясь на своем опыте, каким, по вашему мнению, может быть будущее развитие микросервисов?
Лян Синь: Я один из первых исследователей стека технологий Spring Cloud в компании и член китайского сообщества Spring Cloud. Spring Cloud — самая популярная среда разработки микросервисов в 2017 году. Однако есть вопрос, который необходимо рассматривать диалектически. «Это не означает, что использование платформы Spring Cloud реализует архитектуру микросервисов и будет иметь преимущества архитектуры микросервисов». имеет преимущества микросервисной архитектуры».
Причина, по которой Spring Cloud может выделиться среди других фреймворков и стать самым популярным фреймворком, заключается в целостности его собственной системы. Это можно понять интуитивно, сравнив Spring Cloud, Dubbo и ServiceComb на следующем рисунке.
Кроме того, Spring имеет широкую массовую базу в Китае, и я также уважаю эту идею исследований и разработок «конвенция над конфигурацией», которая не требует полностью полагаться на стандартизированные вещи.
Я не осмеливаюсь говорить о будущем направлении микросервисной архитектуры. Исходя из текущей ситуации, я думаю, что текущая технология контейнеризации Spring Cloud + Docker является лучшим выбором для микросервисной архитектуры. Очень интересный термин, с которым я согласен, — это «генетическая архитектура», что означает: архитектура спроектирована так, чтобы меняться с самого начала, поэтому чем проще изменить вашу архитектуру, тем лучше. Я думаю, что будущее архитектуры идет по этому пути.
Построение нашей единой платформы разработки основано на стеке технологий Spring Cloud.
Репортер: Горячая тема в индустрии исследований и разработок программного обеспечения в этом году — «промежуточная стадия». На архитектурном уровне некоторые люди предложили сделать промежуточную стадию микросервиса. Что вы думаете об этом?
Лян Синь: В прошлом году развлекательное шоу «Возьми это» произвело большой фурор. В сериале есть поговорка "Сухой, хромой, совсем не круглый, хрен с ним!". Позже, когда дело доходит до тарелки, неважно, что это такое, можно ли ее держать в руке или нет, тарелка — это все, что нужно. Звучит ли это особенно волшебно, а тут еще фраза "все можно сыграть". На самом деле это просто шутка, и на самом деле это не означает, что люди видят то, что видят. Что интересно, вы можете серьезно и глубоко все обдумать, не будете ли вы совершать какие-то, казалось бы, нелепые ошибки?
Одним из самых популярных терминов в технологическом кругу в этом году является "Zhongtai". Когда его применяют здесь, он превращается в "Все может быть Zhongtai". Этот термин используется везде. Я думаю, что многим компаниям следует избегать слепого следования тренду и делать "Zhongtai". "ловушка существительное.
Столкнувшись с новой технологией или тенденцией, мы должны сначала понять ее источник и основы. Источник Zhongtai должен быть прослежен до Али. В 2015 году Alibaba Group запустила китайско-тайваньскую стратегию с целью создания инновационного и гибкого механизма «большого, среднего и малого фронт-офиса» в соответствии с эпохой больших данных в Интернете, то есть передовой бизнес станет более гибким, его можно будет быстрее применять к постоянно меняющемуся рынку, а Zhongtai соберет возможности операционных данных и технические возможности продукта всей группы, чтобы сформировать сильную поддержку для каждого внешнего бизнеса.
Тогда почему Ali Group создала структуру «большой, средней и маленькой стойки регистрации»? В книге «Путь трансформации корпоративной ИТ-архитектуры — практика стратегического мышления и архитектуры Alibaba на Среднем Тайване» есть подробное введение в этот вопрос. Начиная с истории развития общего бизнес-подразделения Али, сначала у Али было только одно подразделение Taobao, а затем было создано подразделение Tmall.В это время техническая команда Taobao поддерживала оба подразделения. В то время системы электронной коммерции Taobao и Tmall, как и многие из наших крупных предприятий, были разделены на две независимые системы дымоходов.Обе системы включали такие функции, как товары, транзакции, платежи, оценка и логистика. По вышеуказанным причинам Alibaba Group создала общее бизнес-подразделение, члены которого в основном из предыдущей технической команды Taobao.В то же время были отсортированы и ускорены два набора предприятий электронной коммерции, а общий и общий бизнес функции двух платформ были ускорены. Перейдите к общему бизнес-подразделению, чтобы избежать дублирования строительства и обслуживания.
Как ветеран с более чем 10-летним опытом программирования, один из вопросов, о котором я часто думаю, - это закон развития системы. Я могу понять смысл через его форму и рассмотреть развитие архитектуры. Я думаю, что могу подытожить одну вещь. : "быстро". Конечно, для этой скорости есть предпосылки, такие как показатель точности и ограничения по ресурсам, искать скорость нужно при условии стабильности и минимизации потребления ресурсов.
«Быстро» можно снова разложить: с точки зрения разработки необходимо быстрее писать код, быстрее разрабатывать, быстрее выполнять функциональное тестирование, быстрее развертывать среду, быстрее запускать и останавливать сервисы, с точки зрения производства — скорость. при которой программа работает. Чтобы быть быстрым или быстро ожидать при высокой степени параллелизма.
Причина, по которой микросервисная архитектура популярна, заключается в том, что сервисы разделены на небольшие части, которые можно многократно использовать повторно, и нет необходимости часто писать и изменять код, что экономит много времени; причина, по которой технология контейнеризации популярен потому, что технология контейнеризации может создавать рабочую среду и тестировать Среда является согласованной, что экономит много времени на развертывание среды и снижает вероятность ошибок Вы также можете добавлять узлы контейнера по желанию, расширять возможности бизнес-обработки и обеспечивать быстрый ответ при высоком уровне параллелизма. То же самое относится и к распределенной архитектуре.Архитектура микросервисов на самом деле представляет собой эволюцию распределенной архитектуры. Все изменения неотделимы от оригинала, носят погоню за «скоростью».
Возвращаясь к теме «Чжунтай», цель строительства «Чжунтай» состоит в том, чтобы избежать дублирования строительства и технического обслуживания и быстро реагировать на спрос. Фоновые и платформенные системы относительно стабильны и, как правило, не изменяются легко, и с точки зрения стабильности количество обновлений фоновых и платформенных систем должно быть сведено к минимуму. пользователей. Существует противоречие между поиском изменений и поиском неизменности. В настоящее время мы надеемся создать промежуточную платформу между ними, централизовать многоразовые вещи во внешнем и внутреннем интерфейсе на этой промежуточной платформе, а также переупаковать и объединить предоставлять услуги внешнему миру, что соответствует идее «быстро».
Это источник и основа Чжунтай.Прежде чем строить Чжунтай, предприятие должно сначала понять это, чтобы увидеть, соответствует ли строящийся Чжунтай идее «избегания повторного строительства и обслуживания» и соответствует ли он « Принцип «быстро».
Часть II: Ключевые вопросы, которые необходимо решить при применении микросервисов в бизнесе
Репортер: В этом году CreditEase открыл исходный код платформы планирования задач микросервиса SIA-TASK.Эта платформа широко использовалась в технической группе CreditEase, а также была поддержана многими разработчиками после открытия исходного кода. Можете ли вы представить идеи дизайна и основные функции этой платформы? (Какую проблему вы хотите решить, проектируя и разрабатывая эту платформу)
Лян Синь: Я говорил о Чжунтай ранее. На самом деле, я думаю, что «Чжунтай» — это просто название. Пока оно соответствует двум принципам: «избегать повторного строительства и обслуживания» и «быстро», его можно назвать как угодно, Например, наша платформа планирования микросервисов SIA-TASK — это система, очень похожая на China Taiwan.
Прежде чем представить идею дизайна SIA-TASK, позвольте мне представить ее предысторию. Будь то интернет-приложение или приложение уровня предприятия, оно заполнено большим количеством задач пакетной обработки. Часто требуется некоторая система планирования задач, чтобы помочь разработчикам решать проблемы. С постепенным развитием микросервисной архитектуры монолитная архитектура постепенно превратилась в распределенную микросервисную архитектуру. Многие исходные платформы планирования задач больше не могут удовлетворять потребности бизнес-систем, поэтому появились некоторые распределенные платформы планирования задач. Каждая из этих платформ имеет свои особенности и недостатки, такие как отсутствие поддержки планирования задач, высокая связанность с бизнесом, отсутствие поддержки кроссплатформенности и т. д., которые не отвечают потребностям нового поколения микросервисной архитектуры, поэтому мы разработали Платформа планирования задач микросервиса (SIA-TASK).
SIA-TASK использует систему SpringBoot в качестве выбора архитектуры, выполняет вторичную разработку на основе Quartz и Zookeeper и поддерживает соответствующие возможности и функции.Логическая архитектура SIA-TASK показана на следующем рисунке:
SIA-TASK — это универсальное решение для платформы планирования задач, которое соответствует текущему режиму микросервисной архитектуры и обладает характеристиками кроссплатформенности, оркестрации, высокой доступности, отсутствия вторжений, согласованности, асинхронного параллелизма, динамического расширения, реального контроль рабочего времени и так далее.
Чтобы понять платформу планирования задач, вам нужно сначала понять планирование задач. Задачи можно условно разделить на три типа: задачи, которые выполняются регулярно; задачи, которые выполняются через равные промежутки времени, но не могут быть параллельными; задачи, которые выполняются через равные промежутки времени, но могут быть параллельными. Между задачами также могут быть некоторые порядковые отношения, такие как: последовательный, параллельный, ветвящийся и т. д.
Когда мы планируем задачи, часто возникают следующие проблемы.
Забыв, что проект имеет пакетное выполнение задачи, и процесс пакетного выполнения продолжается после того, как проект отключен, и он не обнаруживается, пока сгенерированный журнал не заполнит дисковое пространство;
Единая точка, процесс пакетного выполнения проекта всегда является одной точкой, и процесс останавливается после сбоя машины;
Зависимость, пакетные процессы A и B проекта зависят друг от друга, и вы можете установить только время двух задач, которые будут распределены по времени.Если возникает задержка, вам необходимо вручную обработать данные об ошибке.
Когда мы разрабатывали SIA-TASK, мы разделили платформу и работу команды проекта. SIA-TASK включает в себя пять модулей, исполнитель задач, то есть бизнес, реальная бизнес-логика которого требует запуска пакетов, принадлежит команде проекта.Когда команда проекта запустится, она выставит выполненную задачу как сервис, и этот сервис будут зарегистрированы в центре регистрации задач; Центр регистрации задач получает задачу, сохраняет ее в базе данных постоянного хранения и одновременно распределяет ее по задачам с зависимостями; наконец, центр планирования задач получает задачи, которые были запланированы в центре планирования задач и должны быть выполнены.Совершите удаленный вызов.
Во всем процессе планирование, организация и выполнение задач отделены от команды проекта.Команде проекта нужно только заботиться о коде бизнес-логики планирования задач, а все остальное выполняется на платформе SIA-TASK, что эквивалентно атомизируя каждую проектную задачу, он был преобразован в микросервис.
В команде проекта остается только бизнес-логика, планирование, организация и выполнение классифицируются платформой, а все, что требует обработки кода, реализуется конфигурацией, что также соответствует идее «избежания повторяющихся действий». строительство и техническое обслуживание» в центре и на Тайване.
SIA-TASK в настоящее время имеет открытый исходный код, и конкретные идеи дизайна, функции и операции развертывания можно просмотреть на GitHub по адресу:GitHub.com/SooIf/Die-…
Репортер: Для каких сценариев подходит платформа планирования задач микросервиса (SIA-TASK)?
Лян Синь: SIA-TASK основан на протоколе HTTP для удаленного планирования.В реальном бизнесе поддержка обработки планирования с высокой степенью параллелизма определенно не идеальна. Если в бизнесе много параллелизма и необходимо активировать десятки тысяч задач в секунду, SIA-TASK не подходит. Кроме того, SIA-TASK можно использовать практически во всех других сценариях.