Начнем с небольшой истории: Чжан Сан — программист, который пошел работать в новую компанию во время золотой девятки, серебряной десятки сезонов. Новая компания выглядит многообещающе, и продукция, которую она производит, также находится на переднем крае отрасли.Чжан Сан поклялся, что разбогатеет здесь и использует свои превосходные технологии разработки, чтобы внести свой вклад в листинг компании.
В первый день инаугурации Чжан Саня компания открыла доступ к коду, и он был знаком с основными проектами компании. Результат был ошеломлен.Чжан Сан обнаружил, что проекты компании похожи на мусорную свалку, со всевозможными кодами, сваленными в горы, и что ему нужно было делать, это поддерживать эти старые проекты.В тот момент внутренняя иллюзия Чжан Саня была моментально сломался..
Но после того, как проект некоторое время поддерживался, все изменилось. Однажды, когда новый проект сошел на нет, начальник назначил ответственным Чжан Саня, который был в восторге и наконец-то смог проявить себя.
«Я должен сделать код элегантным и попрощаться с плохим кодом».
В начале Чжан Сан использовал различные шаблоны дизайна, сумасшедший абстрактный бизнес, все более и более энергичный, он чувствовал, что его талант, наконец, получил возможность проявить себя. Но проект представляет собой совместную работу нескольких человек.По мере того, как время идет, а проект продолжает повторяться, многие новые люди больше не разрабатывают код в соответствии с заранее определенными спецификациями.
Для удобства микросервисы появлялись один за другим, а разработчики наполняли код одним оператором if за другим. В результате Чжан Сан начал вручную ограничивать отправку кода, который не соответствовал спецификациям. Тем не менее, время проекта увеличивалось, и Чжан Сан, наконец, снял ограничения из-за давления доставки. Хотя проект был успешно сдан, странный код остался в проекте навсегда.
Постепенно оригинальный и красивый дизайн стал все больше и больше раздуваться, а логика стала крайне сложной. Никто не решается на рефакторинг, да и рефакторить невозможно. В конце концов, Чжан Сан больше не мог этого выносить, поэтому он ушел в отставку и устроился на работу в новую компанию. Новая компания выглядела многообещающе, и контент, который он производил, также был передовым продуктом отрасли. Чжан Сан еще раз поклялся, что он будет иметь большое будущее в новой компании и использовать свои превосходные навыки.Разработать технологию, чтобы внести свой вклад в листинг компании...
Подобные истории раз за разом разыгрываются в интернет-индустрии.Похоже, что по мере развития любого проекта с течением времени каждый патч со временем становится проектом «дерьмовой горы», наполненным различными историческими проблемами, а разработка новых функций становится все более и более актуальной. более Медленный и, в конечном счете, неспособный развиваться к концу проекта. Некоторые интернет-компании нанимают старших архитекторов программного обеспечения на определенном узле, чтобы продлить жизненный цикл проекта.Они часто знакомы с «Рефакторингом» и используют различные технические средства для задержки процесса.
Что такое архитектура продукта
Подобно архитектуре программного обеспечения, дизайн продукта структурирован.
Когда мы работали над проектом, мы чувствовали, что технически все проблемы могут быть решены, но весь проект шаг за шагом двигался к проекту типа «дерьмовой горы» по незнанию. Согласно мышлению исследований и разработок, корень проблемы в том, что абстракции недостаточно, технический уровень недостаточен, и для реконструкции необходим более мощный архитектор.
После найма старшего архитектора программного обеспечения в начале проект вроде бы стал лучше, но конечный результат не изменился, он просто затянулся, и на определенном этапе от него можно было только отказаться и начать заново.
После обзора мы обнаружим, что наша основная энергия направлена на решение технических проблем, игнорируя при этом уровень продукта. Согласно поговорке в Интернете, архитектура продукта — это логическая сортировка потока данных о продукте на основе полного понимания потребностей пользователей продукта.
И мое понимание архитектуры продукта начинается с **«мира идей»**. Программирование заключается в описании реальных вещей на языке, понятном компьютеру Какой язык понимает компьютер? это логика. При программировании разработчикам необходимо представить в уме всю картину происходящего и описать ее логическим языком.
В западной философии есть поговорка об «идеологическом мире», что примерно означает, что что бы люди ни делали, они предварительно конструируют в своем сознании онтологию вещей, а затем имитируют предварительно сконструированное содержание в реальности. Это очень похоже на процесс, который мы программируем, поэтому продукт следует этому процессу?
Оглядываясь назад на то, как мы думали, когда делали проекты в прошлом, я обнаружил, что это правда, нам более или менее нужно было строить траекторию продукта в наших умах. Но при работе над проектами, такими как R&D, мы все думаем о том, как использовать технологии для решения проблем, но мы игнорируем более важные вещи.Любой продукт существует для решения проблем клиентов.Решение проблем клиентов является фундаментальным, независимо от того, какие товар используется. значит......
Как спроектировать архитектуру продукта
Перед проектированием сначала решите проблему людей Какие люди подходят для архитектуры продукта?
архитектура продуктаПолностью понимать потребности пользователей в продуктахНа основе потока данных о продуктахлогическое расчесывание.
Итак, этот человек должен обладать следующими качествами:
- Умение исследовать и понимать потребности пользователей
- Способен узнать основную ценность продукта
- Умение понимать, как работает продукт
- Объектно-ориентированное дизайн-мышление
Вооружившись этими качествами, вы можете начать строить свой «мир идей».
Создайте мир идей
Построение «мира идей» на самом деле заключается в преобразовании того, что произойдет в реальности, в чисто логическое описание с использованием объектно-ориентированного проектного мышления.Этот процесс называетсяАннотация.
Например, если нам нужно создать продукт типа управления трафиком, процесс абстракции, вероятно, будет таким: управление трафиком в основном разделено на два основных компонента:Мониторинг трафика и управление трафиком, что является основной ценностью.
Традиционные инструменты управления трафиком в основном реализованы в виде SDK и обычно имеют следующие проблемы:
- Инвазивный
- Неполное управление
- Много контента, высокий порог
- Сложность эволюции промежуточного программного обеспечения
- Сильно фрагментированная версия
- Высокая стоимость обновления
Если проблема такого типа может быть решена, это сделает сервисную сетку лучше, чем подход SDK в решении управления трафиком, что является сравнительным преимуществом.
На основе вышеприведенного анализа можно сделать вывод, что если вы хотите, чтобы продукт быстро обновлялся и был менее навязчивым, он не должен быть сильно привязан к коду клиента, ему нужен независимый от языка метод, который может отслеживать и управлять трафиком. можно найти только в операционной системе.
Если вы можете манипулировать некоторыми функциями операционной системы так, чтобы трафик поступал в написанную программу перед входом в службу, он не будет зависеть от языка.
Идея, наверное, такая: когда приходит запрос, он сначала пересылается в написанную программу операционной системой, затем написанная нами программа сообщит данные во что-то и сохранит их, и, наконец, программа будет переадресована в реальный сервис , и мониторинг трафика выполнен. В то же время также необходимо что-то для хранения сообщаемых данных, и оно должно иметь возможность сохраняться.
В этом процессе используется шаблон проектирования, называемый режимом SideCar, с помощью которого sIDECAR вызывает нас для написания программы и хранения базы данных.
Далее выводим логику управления потоком.Для достижения управления потоком нам нужно использовать sidecar.Ведь трафик был направлен в sidecar операционной системой, и мы можем перенаправить его на реальный сервис после обработки. Затем нужно еще что-то, чтобы сообщить сайдкару, как обрабатывать трафик, ведь каждый сайдкар должен обрабатывать разные вещи, и содержание политики должно быть постоянным, иначе не может быть найдена соответствующая связь с сайдкаром. называется управляющей стороной.
Таким образом, процесс выглядит примерно так: контроллер настраивает политику управления трафиком, контроллер отправляет политику в sidecar, приходит запрос трафика и перенаправляется в sidecar операционной системой, sidecar сначала сообщает данные о трафике в базу данных, и затем обрабатывает трафик в соответствии с политикой трафика, обрабатывает и, наконец, перенаправляет запрос в реальную службу.
В совершенно идеальном состоянии через такой процесс в основном реализуются основные возможности управления трафиком, и этот процесс имеет больше преимуществ, чем метод SDK.Это процесс построения так называемого «мира идей», который чисто логическое описание.
Подтвердите мир идей
Единственная мера того, является ли «мир идей» правильным, состоит в том, описывает ли он реальность полностью и правильно, точно так же, как отношения между классами и объектами в объектно-ориентированном мышлении, «мир идей» является абстракцией реальности.
Чтобы узнать, хороша абстракция или нет, есть очень эффективный способ. Просто найдите несколько человек и объясните свою логику.Если процесс высказывания проходит гладко, другая сторона может понять и не чувствует никаких логических упущений, эта абстракция лучше.
При работе над проектом можно максимально подробно описать процесс людям на разных должностях, при этом углубляя понимание продукта членами команды, и в то же время улучшая содержание процесса, не считаясь с совершенством за счет непрерывного выражения.
Как приземлиться
Когда «мир идей» создан, его необходимо сымитировать в реальности.В программной инженерии этот шаг начинает переход от проектирования к этапу практической эксплуатации. Общие проекты делятся на две категории: одна — с нуля, а другая — стандартные проекты.
Проект с нуля
Прежде чем начать проект с нуля, обычно возникает два вопроса: с чего начать? Сколько подражать?
В процессе можно обнаружить, что следующие являются краеугольными камнями всего.
1. Манипулировать некоторыми функциями в операционной системе, чтобы трафик поступал в sidecar, который мы написали перед входом в сервис
2.sidecar
3. База данных
Поэтому, когда нет внешних особых обстоятельств, чтобы помешатьФункция мониторинга трафикаопределенно имеет приоритет надуправление потокомФункция сделать, это то, с чего начать.
Что же касается степени ее достижения, то она в основном зависит от времени, взаимоотношений между персоналом и фактической ситуации. Но сколько бы ни было сделано, пока направление правильное, итерация всего продукта имеет положительное значение.
По этой цифре стало ясно разделение услуг во время исследований и разработок, границы каждой службы также четко определены. Даже если для исследователей появление новобранцев или уровень явления смешанного, деструктивное в этих рамках также может быть вызвано ограниченными и не вызовет структурных проблем для всего произведения, а лишь найдет достаточно сильное в какой-то момент в будущем ре -развитие пишите еще раз, проблема решена.
стоковые товары
Реализация стоковых проектов очень сложна, да и наследие истории не мелкое...
Большая идея должна заключаться в том, чтобы сначала использовать «абстрактный» для отражения реальности, чтобы увидеть, полностью ли текущий код соответствует «абстрактному» «процессу», а затем выяснить, как обрезать ветви и листья.
Если появляется новое требование, его нужно сначала абстрагировать.Любое законное требование логично.Если абстракция не логична, должно быть, что интеллектуального анализа требований недостаточно, и код нельзя добавлять вслепую.
Опять же, если вам нужно добавить сайдкар-мониторинг, процесс будет выглядеть следующим образом.
Но нужно ли проводить мониторинг отдельно? Если нет необходимости, процесс может стать таким.
Между этими двумя формами нет преимуществ или недостатков, и вы можете выбирать в соответствии с конкретной ситуацией.
Суммировать
Если кто-то, кто знаком с сервисной сеткой, должен был обнаружить ее очень рано, то пример, упомянутый в обращении, — это рождение слабой версии Istio.
Я пытаюсь чисто логически вывести архитектуру Istio из требований. Почему многие известные проекты с открытым исходным кодом после стольких лет становятся все более и более совершенными, должно быть что-то стоящее изучения.
Эта статья предлагает только способ решения проблемы.Суть решения проблемы зависит от людей, группы воротил, независимо от того, какой метод используется для того, чтобы сделать вещи красивыми и элегантными.