Архитектура простая: Простая чистая архитектура / Хабр

Простая чистая архитектура / Хабр

Привет, Хабр! Зачем нужна архитектура приложения и какие цели она должна выполнять?

Разработка архитектуры ПО — это искусство и наука проектирования программного обеспечения таким образом, чтобы оно удовлетворяло всем заявленным требованиям, а также обеспечивало максимальную простоту доработки, развертывания и масштабирования приложения.

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

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

Вот например Microsoft предлагают монолитную структуру кода в одной сборке, как одно из решений.

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

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

💡 Разделение между бизнес-логикой и инфраструктурой

Посмотрим на представление Чистой архитектуры приложения ASP.NET Core от Microsoft

Выделены три блока: Ядро, Инфраструктура и Фреймворк, который их объединяет. Обратите внимание, что нет явного слоя представления. Его компоненты находятся рядом с контейнером зависимостей и конвейером обработки запросов. Если мы еще вспомним, что все современные системы делятся на фронтенд и бэкенд, то API может содержать только контроллеры.

💭Будь проще

Python является простым и гибким языком программирования, который подходит для разработки различных приложений и систем. Он имеет свою философию, известную как «Дзен Пайтона», которая включает в себя ряд принципов и рекомендаций, выделю два:

💡 Явное лучше, чем неявное. Простое лучше, чем сложное.

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

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

Не создавайте дублирующие Model, Entity, DTO, наследуя их от абстракции. Создайте модель сразу в ядре и используйте ее для всех слоев, если она нигде не отличается. Этого достаточно для прототипа. Когда продукт-менеджер захочет добавить новую функцию в базу, тогда уже будет создана сущность Entity и абстракции. Однако, стоит заметить, что в 80% случаев проекты не продвигаются дальше этапа прототипа.

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

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

☝️С чего начать?

Чистая архитектура говорит про сценарии. Заказчики чаще всего используют блок-схемы и диаграммы последовательности для обозначения своих мыслей, что делает легче мыслить сценарии использования (use cases). В DDD используется концепция ubiquitous language — единого языка. Давайте использовать это как наш единый язык.

💡 Начинать систему надо со сценариев(use cases)

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

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

Если проект начнет расти, то можно создавать слои, но эти слои будут расширениями существующих, а не промежуточными. Т.е. если у нас появятся слои Persistence, Domain, Application. То это будут слои расширения для существующих т.е. Infrastructure.Persistence, Core.Domain, Core.Application.

💡 Никто из инфраструктуры не может использовать Use case!

Избегать вызова сценариев непосредственно из уровня инфраструктуры. Это может привести к потере контроля над кодом

🏅Итоги

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

• Главное соблюдать логическое деление бизнес логики и инфраструктурного кода, а не физическое разделение слоев. Для этого лучше сразу использовать use cases.

• Ваша архитектура приложения может стать как в примере у Дяди Боба, но это должно прийти с требованиям к проекту.

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

Простая Enterprise Architecture.

Архитектура компании садоводов / Хабр

http://www.hanvanroosmalen.nl/nl/bnl-dragon1-visualisatie

Эпиграф

Куплет будущего гимна архитекторов касаемо скелета (Framework) компании (Enterprise): Enterprise architecture framework

Под грустное рычание,
Под бодрое мычание,
Под дружеское ржание
Рождается на свет
Большой СКЕЛЕТ для маленькой,
Для маленькой такой компании,
Для скромной такой компании
Огромный такой СКЕЛЕТ!

Введение

Задача простая: Построить архитектуру садового товарищества – как элементарный пример Enterprise Architecture небольшого предприятия (товарищества). В сети не нашел ни одного полного Enterprise Architecture Example хоть какого-либо ЕА-framework: TOGAF & Co (Zachman, D/MoDAF), кто найдет пишите – добавим к статье (очень интересно).

Enterprise Architecture (ЕА) – это общая (верхнеуровневая) структура предприятия, которая позволяет понять, что собой представляет предприятие и как оно работает. Архитектура = укрупненная структура (масштаб организации, входы и выходы, процессы, активы, поведенческий профиль и т.п.), т.е. Предприятие «в крупную клетку» и что вокруг него. Следует учитывать, что в общем случае Архитектура предприятия – это не Архитектура информационной системы (ИТ-системы) предприятия. Точнее: информационная система предприятия – это не только ИТ-технологии в привычном понимании, но и вся (не только ИТ-шная) информационная составляющая предприятия, в том числе, которая (информация) существует исключительно в виде бумажных документов и циркулирует в неавтоматизированных процессах.   

Ниже строим СКЕЛЕТ для маленькой, Для маленькой такой компании садоводов, т.е. архитектуру Садового (некоммерческого) товарищества (СНТ). Итак, встречаем первую опубликованную Enterprise Architecture (уровня 0-1-2).      

Краткое описание компании

Объект исследования архитектуривания: типовое (самое обычное) садовое некоммерческое товарищество. Из инфраструктуры: силовая электросеть подачи 220В на участок садовода, поливочная сеть (для огорода), общий мусорный контейнер товарищества, сторожка, сайт СНТ и т.п.

Орг-структура (штат СНТ, сотрудники компании садоводов, рабочая сила, hr-ресурс и т.п.): правление (коллегиальный орган), председатель (единоличный исполнительный орган), электрик, водолей, сторож, бухгалтер, казначей, системный администратор (админ).

Собственник (владелец, хозяин предприятия) формально представлен высшим органом власти — общим собранием садоводов (аналог для коммерческих компаний: общее собрание акционеров). Клиенты компании – это сами члены СНТ. Ссылки по запросу «Что такое СНТ» см. в конце статьи.

Пусть будет 100 участков на 10 гектарах земли. Можно взять 50 или 500 участков – это совсем не принципиально. Если кто-то ни разу не интересовался «что такое СНТ», то можно посмотреть по ссылкам сайтов СНТ (первые попавшиеся):

Пищевик      Хуторок Химик-2 Колос-Сад Выпрабавальник

Далее по тексту будут лишь краткие выжимки (с комментариями к ним) из опубликованной архитектуры СНТ (CHTv0. 1): Web, Html   https://bpmbpm.github.io/EA-example/ea1_CHT.html

поэтому можно идти «прямо в архитектуру» и пропустить «много букв».

Другие ссылки на Enterprise Architecture Example: Файл Pdf          Комплект на github

— Связанные данные через интеграцию visio и excel, включая: Файл Visio        Файл Excel        

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

1. Мета Архитектура

Рис. Три кита предприятия

Предприятие «держится» на трех главных каталогах (наборах, kit, китах) компании: продуктов, процессов, ресурсов. В каталоге ресурсов первым следует подкаталог HR-ресурсов (орг-штатная структура компании). Это скорее по-старинке: «Кадры решают всё, а не кобылы и машины»), т.е. в какой-то момент изначально занимающий пьедестал Каталог оборудования (инструментальных ресурсов, включая машины и тяговую силу) проиграл первенство кадровому обеспечению. Однако в перспективе лозунг «Кадры решают всё!» должен уступить место «Процессы решают всё!», т.е. Каталогу процессов предприятия, на чем и основана актуальность процессо-центричности архитектуры.

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

Рис. Процессо-центричная МетаАрхитектура

Этот принцип не столько существенен при «ломке копий» типа «А какой же концепт построения архитектуры более правильный и более «архитектурный»?», сколько позволяет провести понятную структуризацию, классификацию и кодификацию объектов архитектуры.

2. Технологические концепты архитектуры (конструктор архитектуры)

Архитектура — это не просто схема (альбом схем), а визуализированный репозитарий объектов (элементов) архитектуры. Ключевой технологический компонент (смысл) в понятии «Архитектура» — это учет объектов (учетная система) и их визуализация в графическом виде (в 90% случаев — схемами иерархии, структурные схемы). В этом заложен «второй» смысл «связанные данные», т.е. архитектурное представление в конечном счете предполагает визуализацию в виде схем, но с аналитической подсистемой «под капотом» (к аналитике нужно и хранилище данных). Это может быть, как классическая Linked Data (rdf, и другие рекомендации консорциума W3C), так и другие технологии «Связанных данных с визуализацией», например, интеграция drawio + гугл таблица, штатная интеграция visio + excel или встроенные («подкапотные») механизмы в EA-ориентированные специализированные инструменты. Примерами последних служат ARIS, где сделан крен на визуализацию объектов, включая непревзойденный по сей день SmartDesign и open source Essential Project компании EAS, где сделан крен на работу с репозитарием объектов и онтологию.

Каждый элемент (объект) рассматриваемого уровня ЕА классифицирован и кодирован (присвоен ID, см. схемы архитектуры) и сохранен в репозитарии (репозитОрии) EA, который в данном примере представлен файлом (книгой) excel.

Основные отношения между элементами (поле «Родитель»): «Включает» (задает подчинение и структуру) и «Предшествует» (в excel выделено курсивом, используется в VAD-диаграммах примера), а также «является владельцем/ исполнителем процесса». Каждый учетный элемент визуализирован на схеме.

Задача архитектуры: определить уровень (архитектурный слой) и все объекты этого уровня «собрать в кучку» (поэлементно выделить) и показать каким образом они связаны (включая тип связи) как между собой, так и с окружением, в том числе, объектами других уровней ЕА.

Инструментально самым доступным, простым и с хорошей наглядностью является инструмент связывания данных visio + excel (штатные функции MS Visio). Для нечто подобного в части связывания данных и визуализации связей «штатным» распространенным («народным») ЕА-инструментам типа Archi (Archimate), – еще далеко.

Рис. Инструмент связывания данных visio + excel

Возможен переход от данных из таблицы справа (при нажатии будет последовательный перебор всех связанных фигур-объектов) и переход от фигуры к строке в таблице, при этом если объект связан с несколькими таблицами, то будет возможность выбора таблицы. Visio позволяет двухстороннюю синхронизацию (в примере связь односторонняя). В качестве репозитария может быть присоединен не только excel файл, но и любой источник данных, связанный по ODBC.  

Из ширпотребных (и понятных тем, кто впервые раз слышит «Enterprise Architecture») аналогов ЕА — это ZettelKasten компании для ее верхнеуровневых элементов. Современный ZettelKasten (Obsidian, Loqseq) имеет графическую (графовую) подсистему, которая позволяет «проваливаться» в выбранный объект или связь, отображать свойства объекта и взаимосвязи. 

Если сами картинки (схемы) позволяют увидеть только верхнюю часть айсберга, например, при просмотре в pdf (ссылка на pdf была ранее), то размещенная «под капотом» linked data на базе visio + excel позволяет синхронизацию и глубокую аналитику (погружение в свойства объектов, включая фильтрацию, сортировку, группировку).   

3. Уровни ЕА

Уровни 0-1-2 можно назвать макроАрхитектурой компании. Корневой уровень (CHT₀) показывает окружение компании: место предприятия в общей картинке мира. Базовый уровень (уровень 1) всего лишь детализирует Рис. Процессо-центричная МетаАрхитектура, а все дальнейшие схемы детализируют базовый уровень.

Схемы иерархии продуктов, процессов, ресурсов вначале представлены в древовидном виде. Выделяется высокоуровневая цепочка процессов формата «end to end» — «процесс как полная совокупность действий, приводящая к достижению ценного, с точки зрения заказчика, результата или предоставлению услуги». Этот набор (слой) верхнеуровневых сквозных процессов показан картой процессов верхнего уровня в нотации VAD (value added chain diagram можно заменить на IDEF0).

Если в примере простой компании (СНТ) приведено всего восемь схем-листов VAD (можно было больше, но для примера вполне достаточно), то объем каталога верхнеуровневых сквозных процессов для крупной (1-2 т. сотрудников) компании может составлять более 200 листов (например, 100 верхнеуровневых процессов по 2 листа на каждый). Собственно, поэтому вся «механика» (механизмы, по которым работает компания) компании визуализируется именно процессами, что более подробно рассматривает смежное (скорее конкурирующее) направление ВРМ (Business Process Management).

Паспорта объектов (продуктов, процессов и т.д.) хранятся в листах excel (в примере четыре листа). Так как для каждого типа объектов требуются разные поля (разная номенклатура атрибутивной информации), то целесообразно использовать отдельный лист для каждого типа, т.е. заголовок колонки таблицы – это тип атрибута объекта. Выделение верхнеуровневых процессов (процессная архитектура) и их классификация – отдельная обширная и тема (см. APQC PCF и другие референтные классификаторы процессов), в представленном примере выделено четыре вида процессов.

4. Используемые в примере инструменты

Базовый: штатная интеграция visio + excel (без VBA). Методичка по связыванию: Связывание схем с внешними данными

В примере использована ручная привязка, хотя может быть настроена автоматическая (не путать с автопостроением, типа visio мастер орг-диаграмм).

Дополнительно к visio файлу, визуализация предусматривает экспорт из visio в формат pdf и html (svg, js). Для выгрузки в html в примере ЕА использован Add-ins SvgPublish который позволяет не только транзит «Внешних данных» (исходно полученных из excel-репозитария) в html (интерактивную схему с отображением свойств объектов), но и экспорт «по кнопке» на githib (Pages). Штатный экспорт visio в html – это «какое-то недоразумение».

Заключение

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

Есть тезис, что раз каждая компания уникальна, то и её архитектура также уникальна. Может быть тогда и framework нужен уникальный для каждой компании? Полагаю, что если взять десять СНТ и разрисовать по приведенному примеру (шаблону, framework) их архитектуры – верхнеуровневые структуры, то среди полученных ЕА найдется немного различий, что позволит сказать об однотипной (типовой, эталонной) архитектуре.

Предвижу замечания типа: Какая же это архитектура? Дескать, в других умных книжках типа EABOK, TOGAF & Co или эталон-моделях типа dragon1, других Best Practice (см. Enterprise architecture framework ) вроде бы про другие архитектурные подходы рассказывают. Предметное обсуждение различий целесообразно исключительно при наличии публикаций полноценных примеров ЕА, построенных по сравниваемым методологиям.

Перечень приведенных ссылок:

1. ЕА example

Html      https://bpmbpm.github.io/EA-example/ea1_CHT.html
Pdf        https://bpmbpm.github.io/EA-example/ea1_CHT.pdf
Visio      https://bpmbpm.github.io/EA-example/ea1_CHT.vsd
Excel     https://bpmbpm.github.io/EA-example/ea1.xlsx
Github https://github.com/bpmbpm/EA-example

2. Инструменты visio

Связывание схем с внешними данными Экспортер в html, Add-ins SvgPublish

3. Специальные инструменты

ARIS SmartDesign Essential Project (open source)

4. Linked Data, rdf

Стартовая страница rdf-grapher Пример окружения (eng)         

Также были упомянуты (без ссылок): APQC PCF, dragon1, Archi (Archimate), ZettelKasten (Obsidian, Loqseq)

5 Что такое СНТ

раз два

Компетенция общего собрания

Статья 17. Компетенция общего собрания членов товарищества

Правила внутреннего распорядка СНТ «Станкостроитель»

Должность председателя СНТ

PS:

Продолжение: Простая Enterprise Architecture. Автопостроение схемы архитектуры по данным репозитария

фотографий простой архитектуры | Скачать бесплатные картинки на Unsplash

Simple Architecture Pictures | Скачать Free Images на Unsplash

• ФотоФотографии 10k
• Стопка фотографийКоллекции 506k
• Группа людейПользователи 0

небоскреб

архитектура

город 9 0011

узор

здание

небо

минимум

город

минимализм

окно

офисное здание

Плитка

Логотип Unsplash Unsplash+

В сотрудничестве с Aakash Dhage

Unsplash+

Разблокировать

Hq фоновые изображения3d обоиHd обоиHd обои

K лим Мусалимов

Hd обоиHd серые обоиHd обои небо

–––– ––– – –––– – –––– – –––– –– – –– –––– – – –– ––– –– –––– – –.

Victor

Hd синие обоиТекстура фоныmarina Bay Sands Hotel

Keith Camilleri

barbican centerЛондонВеликобритания

Виктор

АрхитектураКоричневый фонФутуристический город

Виктор

РоттердамПромышленные Нидерланды

Логотип Unsplash Unsplash+

В сотрудничестве с Aakash D hage

Unsplash+

Разблокировать

Hq фоновые изображенияФиолетовые обои высокого разрешенияцифровое изображение

Saj Shafique

Дубай — Объединенные Арабские Эмиратысовременная архитектура

Клим Мусалимов

небоскребHd небо обоинебо фото

Victor

искусствонаучный музейкрышаHd windows wallpapers

Saj Shafique

Объединенные Арабские ЭмиратыДубайБлижний Восток

Frank Weichelt

Германияофисное зданиеминимализм 900 11 Unsplash logo Unsplash+

В сотрудничестве с Aakash Dhage

Unsplash+

Unlock

3d renderred подиумы

Saj Shafique

Современные обои HD Простые обои HD Обои с узором HD

Виктор

Сингапурмарина бухтамарина бэй песок

Виктор

зданиемногоквартирный домвысотное здание

Эллисон Хейн

Лос-АнджелесСШАВинтажные фоны

Фрэнк Вейчелт 9 0011

düsseldorffree imageбрутализм архитектура

Логотип Unsplash Unsplash+

В сотрудничестве с Габриэль Маурер

Unsplash+

Разблокировать

минимальный airbnbaccommodation

Frank Weichelt

deutschlandimmobiliegrafic

Hq фон фотографииHd 3d фоткиHd обои

Hd синий фоткиТекстура фоныmarina Bay Sands Hotel

архитектураКоричневый фонфутуристический город

Hq фон фото hd фиолетовые обоицифровое изображение

дубай — объединенные арабские эмиратысовременная архитектура

искусствомузей наукикрышаhd windows wallpapers

германияофисное зданиеминимализм

сингапурмарина баймарина бэй сэнд

зданиежилой домвысотное здание

düsseldorffree imageбрутализм архитектура

deutschlandimmobiliegrafic

–––– –––– –––– – –––– – –––– –– –– –––– – – –– ––– –– –––– – –.

HD картинкиСерые картинкиHD обои небо

barbican centerлондон Великобритания

rotterdamindustrialnetherlands

небоскребHD обои небонебо фото

объединенные арабские эмиратыдубаближний восток

3D RenderRender Подиумы

Hd современные обоиHD простые обоиHd узор обои

лос-анджелесСШАВинтажные фоны

минимальныйairbnbaccommodation

Hq фон фото3д обоиHd обоиHd обои

barbican centerlondonunited Kingdom

Hq фон фото hd фиолетовый обоицифровое изображение

дубай — объединенные арабские эмиратысовременная архитектура

United Арабские ЭмиратыДубайБлижний Восток

Современные обои HDПростые обои HDОбои высокого качества

düsseldorfбесплатное изображениебрутализм архитектура

hd картинкиhd серые фоткиhd обои небо

rotterdamindustrialnetherlands

искусствонаучный музейкрышаhd windows обои

германияофисное зданиеминимализм

90 010 Лос-АнджелесСоединенные ШтатыВинтажные фоны

deutschlandimmobiliegrafic

–––– –––– –––– – –––– – –––– –– – –– –––– – – –– ––– –– –––– – –.

Hd синие картинкиТекстура фоныmarina Bay Sands Hotel

архитектураКоричневый фонфутуристический город

небоскребHd небо обоинебо фото

3d визуализациякрасные подиумы

сингапурмарина бухтамарина бухта песок

зданиемногоквартирный домвысотное здание

minimalairb nbaccommodation

Unsplash logo

Сделайте что-нибудь потрясающее

В защиту простых архитектур

Wave стоит 1,7 доллара Компания B с 70 инженерами ¹ , чьим продуктом является приложение CRUD, которое складывает и вычитает числа. В соответствии с этим наша архитектура представляет собой стандартную архитектуру приложений CRUD, монолит Python поверх Postgres. Начав с простой архитектуры и по возможности решая проблемы простыми способами, мы смогли масштабироваться до такого масштаба, в то время как инженеры в основном сосредоточились на работе, которая приносит пользу пользователям.

Stackoverflow успешно увеличил монолит (архитектура 2013/2016) и в итоге был приобретен за 1,8 млрд долларов. Если мы посмотрим на трафик, а не на рыночную капитализацию, Stackoverflow входит в число 100 самых посещаемых сайтов в Интернете (многие другие примеры ценных компаний, построенных на основе монолитов, см. в ответах на эту ветку Twitter. Мы не знаем). у нас много веб-трафика, потому что мы являемся мобильным приложением, но Alexa по-прежнему помещает наш веб-сайт в топ-75 тысяч, хотя наш веб-сайт, по сути, просто способ для людей найти приложение, а большинство людей даже не находят приложение через наш сайт).

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

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

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

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

В настоящее время мы используем скучный, синхронный Python, что означает, что наш сервер обрабатывает блокировку в ожидании ввода-вывода, например, сетевых запросов. Ранее мы пробовали Eventlet, асинхронный фреймворк, который теоретически позволил бы нам получить больше эффективности от Python, но столкнулись с таким количеством ошибок, что решили, что затраты ЦП и задержки на ожидание событий не стоят операционных проблем, которые у нас были. взять на себя решение проблем Eventlet. Это и другие хорошо известные асинхронные фреймворки для Python, но пользователи масштабируемых фреймворков часто также сообщают о значительных последствиях использования этих фреймворков в масштабе. Использование синхронного Python обходится дорого в том смысле, что мы платим за ЦП, который ничего не делает, кроме ожидания во время сетевых запросов, но поскольку мы обрабатываем только миллиарды запросов в месяц (на данный момент), стоимость этого низка даже при использовании медленный язык, такой как Python, и оплата общедоступных облачных цен по розничным ценам.

Стоимость нашей инженерной команды полностью преобладает над стоимостью систем, с которыми мы работаем ² .

Вместо того, чтобы брать на себя сложность создания асинхронного монолита, мы передаем в очередь длительные задачи (на которые мы не хотим блокировать ответы).

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

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

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

Некоторые варианты, в которых мы не уверены (поскольку это вещи, которые мы либо думаем об изменении, либо рекомендуем другим командам, начинающим с нуля, рассмотреть другой подход), заключались в использовании RabbitMQ (для наших целей Redis, вероятно, работают так же хорошо, как очередь задач, и простое использование Redis уменьшит операционную нагрузку), используя Celery (который слишком сложен для нашего варианта использования и был связан с несколькими сбоями, например, из-за проблем с обратной совместимостью во время обновления версии), используя SQLAlchemy (что делает разработчикам трудно понять, какие запросы к базе данных будет генерировать их код, что приводит к различным ситуациям, которые трудно отлаживать и требуют ненужной операционной боли, особенно в связи с приведенным выше пунктом о границах транзакций базы данных), а также с использованием Python (который был правильный первоначальный выбор из-за технического опыта нашего технического директора-основателя, но его поддержка параллелизма, производительность и обширный динамизм заставляют нас задаться вопросом, является ли это правильным выбором для крупномасштабной серверной кодовой базы).

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

Некоторые области, в которых мы довольны своим выбором, даже если они могут показаться не такими простыми возможными решениями, как наш API, где мы используем GraphQL, с нашими транспортными протоколами, где у нас какое-то время был собственный протокол, и наши управление хостом, где мы используем Kubernetes. Для наших транспортных протоколов мы использовали специальный протокол, работающий поверх UDP, с откатом SMS и USSD по соображениям производительности, описанным в этом докладе. С внедрением HTTP/3 мы смогли заменить наш пользовательский протокол на HTTP/3, и обычно нам нужен только USSD для таких событий, как недавние отключения интернета в Мали).

Что касается использования GraphQL, мы считаем, что плюсы для нас перевешивают минусы:

Плюсы:

• Самодокументирование точного типа возвращаемого значения
• Генерация кода точного возвращаемого типа ведет к более безопасным клиентам продуктивность win
• Наши различные приложения (пользовательское приложение, приложение поддержки, приложение Wave Agent и т. д.) могут в основном использовать один API, что снижает сложность построить большое количество конечных точек специального назначения
• Исключает байкшеринг по поводу того, что считается RESTful API

Минусы:

• Библиотеки GraphQL были не очень хороши, когда мы приняли GraphQL (базовая библиотека Python была портом библиотеки Javascript, а не Pythonic, Graphene требовала много
• Кодировка GQL по умолчанию избыточна, и мы очень заботимся об ограничении размера, поскольку у многих наших клиентов низкая пропускная способность

Что касается Kubernetes, мы используем Kubernetes, потому что знали, что если бизнес был успешным (каким он был), и мы продолжали расширяться, в конечном итоге мы расширились до стран, которые требуют от нас предоставления наших услуг в стране. Точные правила различаются в зависимости от страны, но мы уже расширяемся на один крупный африканский рынок, который требует, чтобы мы управляли нашим «основным центром обработки данных» в стране, и есть другие с правилами, которые, например, требуют, чтобы мы могли переключаться на дата-центр в стране.

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

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

Спасибо Бену Куну, Сьерре Ротими-Уильямс, Джун Сейф, Камалю Мархуби, Рути Байерс, Линкольну Квирку, Калуму Боллу, Джону Хергенродеру, Биллу Миллу и Финбарру Тимберсу за комментарии/исправления/обсуждение.

---

1. Если вы хотите рассчитать соотношение, у нас было около 40 инженеров, когда мы в последний раз собирали средства, и мы оценивались в 1,7 миллиарда долларов. ^{[возврат]}
2. Существуют бизнес-модели, для которых это было бы неверно, например, если бы мы были компанией социальных сетей, поддерживаемой рекламой, уровень трафика, который нам потребуется для поддержки нашей компании по мере ее роста, будет настолько большим, что мы понесли бы значительные финансовые затраты, если бы не тратили значительную часть нашего инженерного времени на работу по оптимизации и сокращению затрат.