Саманный монолит: новая жизнь старой технологии – Добрострой

новая жизнь старой технологии – Добрострой

Дом и стройка, Журнал

• 
  22.08.2022

• Опубликовано

  dbs_adm

22

Фев

В странах Средней Азии, в Крыму, на юге Украины и в Молдове до сих очень много саманных домов, построенных в прошлом и даже позапрошлом столетиях. Недвижимость такого толка никогда не считалась престижной.

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

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

Состав самана

Кроме очевидной экологичности, саман еще и самый дешевый, доступный стройматериал. Его компоненты:

• глина
• солома
• песок
• вода

Несмотря на то, что все сырье «подножное», глина, песок и даже вода должны быть подготовленными и соответствовать определенным параметрам качества.

Глину предварительно перебирают, например, лопатой, вынимают из нее камни, разбивают комки, удаляют мусор и дают вылежаться.

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

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

Способ изготовления

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

Для этой цели надо выкопать небольшое углубление размерами примерно 2 на 2 метра. Его выстилают брезентом или пленкой. И наливают в подготовленный котлован воды где-то на треть его высоты.

Теперь самое время определить оптимальное соотношение главных компонентов. Оно во многом зависит от жирности глины и может быть 3 части глины на часть песка, 2 части и даже 1:1. Используя различные пропорции того и другого, делают пробы. То есть лепят небольшие, диаметром 3 см, шарики. А когда они высохнут (на это уйдет не больше получаса), с высоты бросают их на твердое. Если шарик не только уцелел, но не расплющился и не потрескался, то правильный состав найден.

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

Соломы потребуется 2-4 части на кубометр глиняно-песчаного состава. Засыпают ее порциями, как муку в тесто: когда смесь окажется достаточно пластичной и перестанет сочиться водой, соломы достаточно.

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

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

Этапы производства

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

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

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

Если саманный кирпич не промокнет и если его переворачивать время от времени, то высохнет он уже за полторы-две недели.

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

Правила строительства

• Если возводится монолит, то за одну рабочую смену нельзя наливать больше, чем 30 см смеси. Иначе стены деформируются, «поплывут».
• В дождливую, сырую погоду работать не стоит, а постройку в эти дни нужно защищать брезентом или полиэтиленом.
• Под крышу, опорные стропила лучше подложить доски, чтобы уменьшить неравномерную нагрузку на саман.
• Выступы крыши делайте широкими, не меньше 70 см, чтобы стены не мокли.
• Штукатурить саманные стены можно известковым раствором и спустя примерно год после постройки – когда они дадут естественную усадку.

Лучше всего выглядят каркасные дома, заполненные саманной смесью, в которой соломы несколько больше, чем обычно. Такие стены получаются ровнее, крепче и теплее. Правда, и обойдется строительство каркасно-саманного дома значительно дороже, ведь потребует немало древесины.

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

Саманно-камшитовые здания — ТехЛиб СПБ УВТ

К этой группе капитальности относится обычная украинская хата мазанка.

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

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

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

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

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

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

На территории Украины вплоть до развала СССР работали сельские фабрики по производству самана. Сейчас таких фабрик единицы, их продукция продолжает пользоваться спросом у селян.

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

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

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

Хата возводилась по принципу подъемно переставной опалубки. Этот процесс был довольно тяжелый и продолжительный. Необходимо было подготовить смесь, установить опалубку, уложить смесь с послойным уплотнением,  дождаться набора конструктивной прочности, после чего снимали опалубку, ставили подмости и все повторяли сначала.  Высота заливки за один раз 300-400 мм.  Над одним домом одновременно могли работать до 20 человек, а то и больше.

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

Мазанка. Мазанка — самое теплое жилье из глины, самая быстрая в строительстве, но не менее трудозатратная. В качестве фундамента использовался обожжённый топляк, крупные камни. Поперечинами каркаса служили ветки срубленной акации. Каркас выполнялся без гвоздей надо сказать, все соединения выполнялся с помощью врезок и врубок. Когда рубили большое дерево, то один ствол диаметром 300-400 мм кололи на 2 или 4 части и использовали как опоры под углы. Если использовали более молодые деревья, то на опоры каркаса шли стволы диаметром от 100 до 200 мм. Затем в поперечины вплетали ветки, чтоб получилась своеобразная «корзина». После этого каркас обмазывался. Использовалась глиняно-соломенная смесь, количество соломы составляло от 10 до 70% по массе.

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

В северных вариантах мазанка выполнялась по срубу на 3-4 венца, который обмазывался каолиновой глиной. Такой способ одновременно решал проблему конопатки швов и придавал традиционный белый цвет.

 До сих пор мазанки возводятся по традиционной технологии с использованием современных твердеющих растворов и широкого ассортимента древесины.

Как правило, под мазанку выполняется ленточный фундамент. Затем приступают к возведению несущего каркаса. Деревянный каркас, на основе которого строится стена хаты, обычно изготавливается из древесины сосны или дуба. Стены дома, кроме традиционного метода на сохах (каркасе), обычно производятся на основе специально изготовленных саманных блоков или складываются из сырцового кирпича.

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

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

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

Толщина, которую имеет стандартная камышовая кровля, превышает тридцать сантиметров, поэтому в дальнейшем не требует утепления.

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

Усиленный монолит Adobe (Cob) Тестирование

Хотите поддержать это революционное тестирование? Наш партнер по исследованиям Quail Springs, некоммерческая организация 501 (c) 3, принимает пожертвования.

Монолитное здание из самана (самобумага) предлагает множество преимуществ:

• Качественное, доступное, устойчивое жилье
• Безопасный для климата
• Экологичный
• Устойчивость к огню и селевым потокам
• Красиво и душевно

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

Oasis Design сотрудничает с Quail Springs, Cal Poly San Luis Obispo и Verdant Engineering в Беркли, чтобы разработать удобную в использовании арматуру, позволяющую глыбе соответствовать стандартам землетрясений во всех сейсмических зонах. Мы работаем с инженерным отделом Oasis и Cal Poly San Luis Obispo над созданием испытательных стен для разрушающих испытаний, чтобы получить необходимые технические значения для различных режимов армирования.

Стены будут подвергаться «обратным циклическим испытаниям в плоскости», то есть толканию и вытягиванию из верхнего угла в плоскости стены с помощью переносной нагрузочной рамы, способной оказывать усилие до 100 000 фунтов, пока полностью оборудованные стены не выйдут из строя. Эти данные дадут сопротивление на погонный фут стены для каждого типа арматуры. Эти значения можно использовать для выполнения вызовов, необходимых для создания структуры любой формы, включая органические кривые, как в этом пилотном проекте, который Арт Людвиг предлагает для центра Санта-Барбары (см. oasisdesign.net/shelter/safetycottage).

Хотите поддержать это революционное тестирование? Наш исследовательский партнер Quail Springs, некоммерческая организация 501 (c) 3, обрабатывает пожертвования.

Испытание на огнестойкость армированной монолитной стены Adobe Wall (видео) подрыв пожарным рукавом.

Изображения:

• Обзор стеновых испытаний , июль 2018 г. (pdf).
• Фотогалерея: Конструкция стены для испытаний в плоскости с обратным циклом в Куэйл-Спрингс, июль 2018 г.
• Промежуток времени части конструкции стены для обратно-циклических испытаний в плоскости в Quail Springs
• Фотогалерея: Тестирование модели Mix и масштаба 1:12 2013
• Пилотный проект Adobe Safety Cottage 9Обзор | Каталог

  www.oasisdesign.net
  © Oasis Design, 1997–2022 гг. Я продолжаю пользоваться отпуском по уходу за ребенком.

  Принимая участие в многочисленных беседах с сообществом в последнее время, я понял, что многие люди знают или, по крайней мере, слышали о том, что Adobe Commerce уже довольно давно разбирает Монолит, и активно внедряются новые сервисы. Но общая стратегия и Полярная звезда, к которой мы идем, не всегда ясны. Таким образом, когда всплывает какая-то терминология, вроде «изолированные сервисы», «сервисы», «микросервисы», «душитель» и так далее, иногда это вносит больше непонимания и, как следствие, разочарования, чем приводит нас к одному и тому же. страница.

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

  Начнем с монолита и почему мы начали его менять. Второй закон термодинамики, в принципе, утверждает, что беспорядок в замкнутой системе не может быть уменьшен. Она может только оставаться неизменной или увеличиваться. Мерой этого беспорядка является энтропия. Этот закон также кажется правдоподобным для программных систем; по мере модификации системы ее беспорядок, или энтропия, имеет тенденцию к увеличению. Это именно то, что происходит с монолитом, начиная с Magento 1. В Magento 2, представив Dependency Injection (DI), многие из тех скрытых проблем, которые существовали со времен M1, стали неприкрытыми для всех.

  Модульность

  Модульность — это то, с чего мы начали, и для этих целей мы ввели сервисный слой Magento.

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

  Проблема возникла, когда мы начали интегрировать сервисный уровень в кодовую базу монолита. Учитывая, что уровень представления был тесно связан с бизнес-логикой предметной области, введение посредника между ними оказалось довольно сложной проблемой, иногда требующей полного рефакторинга обоих. Цитируя Мартина Фаулера: « Если вы перепишете Большой взрыв, единственное, в чем вы будете уверены, — это Большой взрыв ». Это основная причина, по которой сервисный уровень в основном используется для веб-API (REST/SOAP), хотя он не полностью включен в приложение Magento, что заставляет нас распознавать и поддерживать низкоуровневые API-интерфейсы ресурсов/моделей вместе с сервисным уровнем и делает мульти многоуровневая архитектура выглядит так:

  Распределенный монолит

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

  На уровне данных мы представили возможность разделения баз данных оформления заказа и управления заказами с помощью решения для разделения базы данных ( Функция разделения базы данных в настоящее время устарела, начиная с версии 2.4.2 Adobe Commerce ).

  Хотя есть причина, по которой многие считают распределенный монолит антипаттерном. На самом деле, набор причин:

  • Такие «сервисы» все еще были тесно связаны (поведенческая связь/временная связь/связь реализации).
  • Масштабируемость по-прежнему оставалась проблемой, главным образом из-за высокой связанности. В более поздних выпусках мы представили больше сервисных контрактов, и больше модулей было переключено на обмен сервисными контрактами. Однако нежелательные устаревшие зависимости (прямые межмодульные зависимости от модели к модели и зависимости от представления к модели) все еще существовали.
  • Наши сервисные контракты не предназначены для связи по проводам. Вот почему некоторая бизнес-логика имела чрезмерно болтливую служебную связь, которая при переключении на проводные вызовы приводила к резкому снижению производительности. Это также анти-шаблон, позволяющий бизнес-логике абстрагироваться от того, является ли вызов API локальным или по сети.

  Изоляция служб

  Публикация концепции Magento Service Isolation определила курс на SOA. Введение понятия услуг и установление требований к ним. Основным результатом изоляции служб было определение границ домена и разделение между службами, принадлежащими управлению магазином (с которыми имеет дело пользователь-администратор) и службам витрины (с которыми имеет дело покупатель).

  Согласно видению, служба реализует определенное бизнес-поведение. Услуга состоит из одного или нескольких модулей. Связь между службами зависит только от сервисных контрактов. Службы, совместно развернутые в одном экземпляре Magento, используют сервисные контракты как вызовы внутри процесса PHP. Службы, развернутые отдельно в выделенных экземплярах Magento, используют сервисные контракты как удаленные вызовы через API REST, SOAP или AMQP.

  Требование об обмене данными через сервисные контракты применяется только к обмену данными между сервисами. Модули в рамках одной службы могут использовать прямую связь и расширяемость. Предполагалось, что платформа и основные API останутся прежними (PHP, Magento Framework).

  Ярким примером сервиса, разработанного в соответствии с требованиями изоляции сервисов, стал Multi-Source Inventory (MSI).

  Основными проблемами, связанными с этим подходом, были:

  • Чтобы сохранить обратную совместимость, интегрируя новые сервисы в существующую кодовую базу, сохраняя устаревшие API и настройки поверх них.
  • Низкий уровень внедрения. Поддерживая оба подхода одновременно в течение достаточно долгого времени. Общий выпуск MSI был выпущен 28 ноября 2018 г. (3 года назад), но поскольку MSI можно было легко отключить, большинство разработчиков начали отключать его по умолчанию, выбирая вместо этого устаревшую реализацию инвентаризации. После трех лет использования GA статистика экземпляров с включенным и отключенным MSI составляет 80% включенных и 20% отключенных (среди продавцов Adobe Commerce Cloud).

  SaaS-сервисы с одним арендатором на основе PHP и «душитель»

  Принимая во внимание, что безголовое использование Magento становится необычайно распространенным явлением, PWA, а затем и AEM привлекали все больше и больше внимания со стороны сообщества Magento. В результате количество инсталляций, которые интегрировались с Magento исключительно через Web-API (REST и GraphQL), выросло, не говоря уже о том, что де-факто headless становится отраслевым стандартом — мы решили сохранить общую идею декомпозиции сервисов, но изменить фокус на другом уровне абстракции, с которым мы работаем, — продвигаемся «вверх по модели OSI», начиная создавать Facade через Web-API, а не через интерфейсы PHP.

  В нашем случае «паттерн Душитель» был представлен на уровне автономного сервера GraphQL на базе Node.js. Кроме того, это дало нам возможность разрабатывать сервисы с нуля, никак не затрагивая монолит и не обременяясь гайдлайнами PHP BiC. Настройка и расширение выполняются на уровне схемы GraphQL посредством внепроцессной расширяемости (OOPE) через Adobe IO Runtime.

  Помимо возможности сохранения прямой совместимости для текущих безголовых применений Magento, использование GraphQL API имеет еще одно дополнительное преимущество по сравнению с PHP Service Layer: эволюция GraphQL API возможна без использования версий (GraphQL предоставляет способ развития API без необходимости для его версии, или говоря по-другому, все версии API представлены в одной схеме). Теоретически (и в настоящее время на практике) это позволяет избежать BiC.

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

  Планировалось иметь один экземпляр сервиса и поддерживающую его инфраструктуру/хранилище данных на одного продавца (однократная аренда).

  Идея начала быстро развиваться, поскольку независимое развертывание служб приложений и соблюдение принципов проектирования, определенных в Magento Service Isolation Vision, таких как « Все операции доменных служб ДОЛЖНЫ БЫТЬ без сохранения состояния », сделали возможным использование Stateful PHP (Roadrunner) в качестве сервера приложений для запуска PHP.

  За это время мы начали использовать определение «микросервис» для новых сервисов, чтобы показать разницу с предыдущим подходом.

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

  Вероятно, использование терминологии «микросервис» наряду с «душителем» привело к довольно разрушительному эффекту и многим недоразумениям относительно судьбы монолита.

  Хотя наряду с многочисленными «плюсами» у этого подхода было и довольно много «минусов»:

  • в Roadrunner/Swoole нет полной поддержки потоковой передачи gRPC. Некоторые части нужно сделать на Go lang. Это может быть не большой проблемой, но если мы вводим жесткое требование иметь Go, почему бы не быть полностью независимым от языка программирования и использовать, скажем, Java Spring Boot для сервисов.
  • поскольку первоначальный план состоял в том, чтобы открыть исходный код этих недавно созданных PHP-сервисов, мы поняли, что невозможно предотвратить внутрипроцессное расширение с помощью плагинов/DI и т. д. и использовать только OOPE для сервисов. Это сделало бы модель гибридной расширяемости даже в объеме услуг (расширение внутри процесса, используемое вместе с расширением вне процесса), что в конечном итоге приведет к тем же проблемам с возможностью обновления, которые мы имеем сейчас с монолитом. В то время как основная цель состояла в том, чтобы обеспечить беспрепятственный апгрейд сервиса для продавцов.
  • , принимая во внимание, что эти сервисы должны быть предоставлены, развернуты и иметь сложную CI/CD — продавцу также было непросто использовать их вне Adobe Commerce Cloud.

  Компонуемая коммерческая архитектура с мультиарендными сервисами SaaS

  Принимая во внимание минусы, упомянутые в предыдущем подходе, мы пришли к идее мультиарендных сервисов SaaS.

  Хотя это не единственное эволюционное изменение, присутствующее в этом подходе.

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

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

  Итак, мы склонились к использованию GraphQL Mesh.

  Следующий способ работы GraphQL Mesh:

  • Сбор спецификаций схемы API со всех служб
  • Преобразование API каждой службы в схему GraphQL, если необходимо, поддерживаются следующие протоколы для преобразования в GraphQL:
  1. OpenAPI/S болтать
  2. gRPC
  3. SOAP
  4. GraphQL (федерация Apollo)
  5. SQL
  • Применение пользовательских преобразований схемы и расширений схемы. Помимо простой обертки API службы слоем GraphQL, GraphQL Mesh также позволяет расширять, изменять (например, объединять несколько API в один запрос GraphQL) преобразованную схему, и все это с помощью полностью типизированного SDK.
  • Создает полностью типизированную единую схему

  Кроме того, в качестве положительного побочного эффекта мы получаем полное разделение между API уровня представления (GraphQL) и API бизнес-логики доменных служб (gRPC/REST). Чтобы мы могли сделать GraphQL из любого API, не заставляя команду, ответственную за этот API, вообще знать об этом, и никакой инфраструктурной работы не требовалось.

  Этот метод приближает управление схемой GraphQL к разработчикам и позволяет им изменять и управлять схемой GraphQL в соответствии с потребностями своего приложения.

  Давайте посмотрим, как может выглядеть это разделение:

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

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

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

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

  В общем, предоставление возможности определять каждый API через GraphQL и использовать все существующие инструменты GraphQL для работы с этими API, но наряду с этим сохранять вызов через собственный протокол, такой как gRPC, может быть хорошим решением для создания платформы расширения API для API. различной степени зернистости (как крупнозернистой, так и мелкозернистой).