Монолитные технологии: Сайт посвященный технологии монолитного строительства

Роль «монолита» в современном строительстве

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

Чем же объясняется «живучесть» строительства из сборного железобетона при очевидных преимуществах монолитного строительства? Это обусловлено «давлением» созданной в минувшие годы огромной производственной базы. Она жестко диктует условия, если это домостроительный комбинат, где работают 2-2,5 тысячи рабочих. При повсеместном переходе на «монолит» остро встанут вопросы социального плана.

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

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

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

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

Новые строительные технологии помогают экономить. С началом активного инвестирования в российскую недвижимость неизбежно начнется и массовое внедрение новых строительных технологий. Некоторые в России уже прижились, другие только-только завоевывают рынок. Среди новых технологий безусловным и самым известным лидером является монолит. Монолитные дома все больше популярны в последнее время, особенно у тех компаний, которые строят для людей небогатых. У монолита есть преимущества перед панельным домом: первые теплее, поскольку между бетонным блоком и кирпичной обкладкой есть утеплитель — чаще всего это так называемое минеральное волокно; кроме того, кирпичный фасад и смотрится лучше, чем серые панели. Стоимость монолитного дома находится где-то посередине между зданием панельным и кирпичным. Это позволяет монолиту стать весьма перспективным, особенно если учесть, что, с одной стороны, самый большой спрос сейчас на дешевое жилье, а с другой, требования к нему у покупателей все выше.

По оценкам экспертов, доля крупнопанельного жилья выросла до 30%. Особенно много таких домов строится в больших городах, где строительная промышленность уже вышла на новый уровень.

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

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

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

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

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

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

По словам специалистов МНИИТЭПа, самый дорогой из монолитных собратьев — дом, полностью отлитый из бетона. Чтобы улучшить экологические характеристики по сути бетонной коробки, проектировщики в таких зданиях предусматривают кирпичные перегородки. Часто внутренние стены также выполняются из кирпича. Прослужить такое капитальное строение может не одному поколению жильцов (известно, что дома, возводимые компанией «Квартал 32-33» на Ленинском проспекте, имеют гарантию 300 лет). Более дешевая технология, когда из бетона отливаются внутренние стены, а внешние выкладываются из кирпича. На первый взгляд создается впечатление, что это кирпичный дом, но на самом деле конструкция уступает первому дому, по экологии в том числе. По словам знатоков, кирпича там гораздо меньше, чем в первом (внешне монолитном) доме. Самые дешевые, а значит, и самые доступные монолитные дома, где внешние стены формируются из бетонных панелей. Иногда, чтобы сэкономить и предложить покупателям более доступное жилье, для формирования внутренних стен используется гипсокартон. Но жить в помещении с практически абсолютной акустикой мало кого прельщает, поэтому покупатели вынуждены самостоятельно возводить кирпичные стены.

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

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

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

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

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

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

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

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

— Возведение монолитного дома менее хлопотно?

— При строительстве дома с применением монолитного бетонирования прямо на строительной площадке устанавливается растворно-бетонный узел. Бетон производится на месте, подается в бетононасос и укладывается в предварительно установленную опалубку. Скорость возведения такого дома немногим уступает сборке панельного. Максимальная скорость возведения одного этажа односекционного дома может занимать до двух суток. Скорость отливки монолита — 4-5 дней. По ряду показателей панельные дома проигрывают в сравнении с монолитными. В них, например, невозможна планировка квартир с любым набором необходимых городу квартир, приходится время от времени герметизировать внешние швы.

— Монолитные здания считаются еще и долговечнее панельных.

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

— Отчего это происходит? Одна из причин — попадание влаги и воздуха через стыки наружных стеновых панелей. Закладные детали, на которых держатся навесные панели, начинают ржаветь, а панели — отваливаться. А вот у монолитного дома срок жизни — более 150 лет. Именно в течение этого времени железобетон не теряет своих прочностных свойств.

— Известно, какое значение в монолитном домостроении имеет качественная опалубка. Но где ее взять?

— Сегодня опалубка для «монолита» закупается в основном в Италии, Германии и Финляндии. Она включает в себя определенное количество металлоконструкций, специальную фанеру и рассчитана, примерно, на 100-кратную оборачиваемость. В принципе, совсем несложно наладить производство качественной опалубки и у нас. Достаточно создать совместное предприятие или выкупить «ноу-хау». Все затраты окупятся.

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

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

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

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

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

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

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

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

Первоначально себестоимость монолитного строительства была гораздо выше, чем панельного. Это и создало монолитным домам ореол жилья для богатых. Однако за прошедшие годы себестоимость «монолита» существенно снизилась, сейчас она лишь на 20-40% выше, чем «панели». В результате дома оказались доступными гораздо более широкому кругу покупателей, ведь оставшаяся разница в цене с лихвой компенсируется качеством такого жилья. Снизились и сроки возведения монолитных домов.

Добиться права на строительство с каждым годом все труднее, хотя бы потому, что количество свободных площадок в городе сокращается. И застройщики хотят использовать полученное место с максимальной отдачей.В этих условиях особенно важно выбрать правильного поставщика технологий материалов, который, как это делают лидеры это рынка (ПромСтройКонтракт, СеверТрансМонолит, ЗАО Опалубочные системы, Экостройпроект, ПромСтройУрал, Агрисовгаз, МСК) гарантировал бы отсутствие брака на уровне монолитного конструктива. Прежде всего на уровне — опалубки. 

Материал опубликован в разделе: Статьи и интервью.

3. Технология возведения монолитных зданий

Фото 3 Пяти этажный жилой дом по ул Парина «Деревня универсиады»

Большую часть объема монолитного бетона и железобетона применяют для возведения конструкций нулевого цикла и толь­ко 20…25% расходуют на надземные части зданий и сооруже­ний. Наибольшая эффективность монолитных конструкций проявляется при реконструкции промышленных зданий и соо­ружений, а также при возведении объектов жилищно-коммунального строительства. Применение монолитного бетона позволяет уменьшить расход стали на 7…20%, бетона до 12%. Но при этом возрастают энергозатраты, особенно в зимнее время, и повышаются трудозатраты на строительной площадке. Так, затраты труда на строительной площадке при возведении зда­ний из монолитного железобетона в 1,65 раза выше, чем при строительстве крупнопанельных зданий. Ясно, что основной объем работ при строительстве зданий из монолитного бетона приходится на строительную площадку. Но возрастание расхода бетона на 17… 19% по сравнению с крупнопанельным домостро­ением объясняется недостаточным использованием легких бето­нов, современных плитных утеплителей, и применением более низких марок цемента. Возведение зданий из монолитного железобетона позволяет оптимизировать их конструктивные решения, перейти к нераз­резным пространственным системам, учесть совместную рабо­ту элементов и тем самым снизить их сечение. В монолитных конструкциях проще решается проблема стыков, повышаются их теплотехнические и изоляционные свойства, снижаются эк­сплуатационные затраты.

Комплексный процесс возведения монолитных конструк­ций включает:

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

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

Материалом опалубки служат сталь, алюминиевые сплавы, влагостойкие фанера и древесные плиты, стеклопластик, по­липропилен с наполнителями повышенной плотности. Под­держивающие элементы опалубки обычно выполняют из стали и алюминиевых сплавов, что позволяет достичь их высокой оборачиваемости. Комбинированные конструкции опалубки являются наибо­лее эффективными. Они позволяют в наибольшей степени использовать специфические характеристики материалов. При использовании фанеры и пластика оборачиваемость опалубки достигает 50 раз и более, при этом существенно возрастает качество покрытия за счет низкой адгезии материала с бето­ном. В стальной опалубке используют листы толщиной 2…6 мм, что делает такую опалубку достаточно тяжелой. Опа­лубку из деревянных материалов защищают синтетическими покрытиями. Пленки на палубу наносят методом горячего прессования с использованием для пропитки древесины баке­литовых жидких смол, эпоксидно-феноловых лаков, использу­ют стеклоткань, пропитанную фенолформальдегидом. В нас­тоящее время наиболее широкое распространение получила влагостойкая фанера, выпускаемая толщиной 18…22 мм. Для покровного слоя используют стеклопластики, слоистые плас­тики,  винипласты.

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

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

Опалубочные работы

Опалубки классифицируют по функциональному назначению в зависимости от типа бетонируемых конструкций;

— для вертикальных поверхностей, в том числе стен;

— для горизонтальных и наклонных поверхностей, в том числе перекрытий;

— для бетонирования комнат и отдельных квартир.

На объекте (фото. 3) применялась разборно-переставная мелкощитовая опалубка, которая состоит из набора элементов небольшого размера площадью до 3 м2 и массой до 50 кг, что позволяет устанавливать и разбирать их вручную (фото. 4). В качестве щитов используется ламинированная фанера, толщиной 21 мм.

Фото 4.

Опалубка перекрытий выполнена при использовании телескопических стоек (максимальная высота которых 4,1 м), унивилок, треног, а так же деревянная брусьев (сечением 100х100 мм) (фото 5.).

Фото 5.

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

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

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

Фото 6.

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

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

Так же на объекте Административное здание УФК была применена крупнощитовая опалубка, которая состоит из крупноразмерных щитов и элементов соединения. Данную опалубку применяют для бетонирования протяженных стен, перекрытий.

Крупнощитовая опалубка наиболее универсальна и мобильна в использовании и позволяет существенно улучшить качество конструкций за счет снижения числа сопряжений (фото 6), при этом высоту щита принимают равной высоте яруса бетонирования.

Опалубка предназначена для возведения крупноразмерных монолитных конструкций самых разнообразных сооружений, установка и снятие опалубки осуществляется только кранами. Щиты опалубки являются самонесущими и включают палубу, элементы жесткости щита и несущие конструкции. Такие щиты оборудуют подмостями, подкосами для установки и первоначальной выверки, регулировочными домкратами (фото 7,8).

Фото 7

Фото 8.

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

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

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

Фото 9.

Бетонную смесь в опалубку укладывают сверху с закрепленных на ней консольных подмостей, располагаемых с наружной стороны щита. Бетонирование стен ведут участками, границами служат обычно дверные проемы. Разгрузку бункера с бетонной смесью осуществляют всегда в нескольких точках, при этом смесь в опалубку укладывают слоями толщиной 30…40см с уплотнением глубинными вибраторами зразу при укладке. Для восприятия давления бетонной смеси при установке опалубки используют специальные инвентарные втулки, а иногда и дополнительные вкладыши. Щиты опалубки для стен и перекрытий часто выполняют на размер бетонируемой площади; эта площадь не должна превышать 70м².

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

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

Арматурные работы

На объекте для производства сварочных работ изготовления арматурных сеток и каркасов был предусмотрен навес для защиты от атмосферных осадков (фото 9). Под навесом располагался столы для сварки сеток, станок для нарезки арматуры, а также вблизи навеса располагалась площадка, где складировалась арматура и готовые арматурные каркасы.

На данном объекте сварочные работы выполнялись квалифицированными рабочими, имеющими удостоверения сварщиков с присвоенными разряда и допусками к производству работ.

Монтаж арматурных каркасов производился с помощью крана РДК, арматурные каркасы подаются в зону производства работ в проектном положении (фото 11). Толщина защитного слоя обеспечивается с помощью фигурных пластмассовых фиксаторов.

Фото 10.

Арматура доставляется с завода изготовителя на строительную площадку в виде отдельных стержней длинной по 11,5 м, и нарезается по размерам, указаны в проекте, уже на строительной площадке.

Сборка пространственного каркаса перекрытия производится прямо в опалубке (фото 12).

Фото 11.

Фото 12.

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

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

Арматурные работы выполняют параллельно с устройством опалубки и последовательно по захваткам. Армирование выполняется в полном соответствии с проектом (раздел КЖ).

Состав комплексного процесса.

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

— установка опалубки и лесов;

— монтаж арматуры;

— монтаж закладных деталей;

— укладка и уплотнение бетонной смеси;

— ухода за бетоном летом и интенсификация его твердения зимой;

— распалубливания.

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

Разбивка на захватки – горизонтальная разрезка, которая предполагает:

— равновеликость по трудоемкости каждого трудового процесса;

— минимальный размер захватки – работа звена на протяжении одной смены;

— размер захватки, увязанный с величиной блока, бетонируемого без перерыва или с устройством рабочих швов;

— число захваток но объекте, равное или кратное числу потоков.

Для четкой организации выполнения комплексного процесса бетонных работ поточным способом необходимо:

Определить трудоемкость каждого процесса;

Разделить объект на ярусы и захватки, близкие по трудоемкости для каждого процесса;

Установить ритм потока и общий оптимальный срок работ;

Определить и подобрать оптимальное оборудование для подачи на рабочее место опалубки, арматуры и бетонной смеси;

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

Составить календарный график комплексного процесса.

На объекте работали два крана: РДК (фото 13) и башенный кран POTAIN S1 10 TG8 (R54/16) (фото 14).

Фото 13.

Фото 14.

Объект 4-х секционный: на 2-ой секции работала бригада из 15 человек, на 3-ей секции – бригада из 17 человек, 1-ую и 4-ую ведет одна бригада численностью 26 человек.

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

Механизация бетонных процессов

Бетонную смесь изготавливают на заводах товарного бетона. Бетонная смесь доставляется до потребителя , т.е. в зону бетонных работ, автобетоновозами или автобетоносмесителями.

На данном объекте доставка бетонной смеси осуществлялась автобетоносмесителями, которые представляют собой бетонный смеситель объемом 5 — 8 м³, устанавливаемых на автомобилях типа МАЗ, КамАЗ.

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

Первые два способа используются для бетонирования до 50 м3 бетона в смену, третий – при любых объемах, но целесообразно ее использовать при укладке не менее 45 м³ в смену. По лотку бетонная смесь подается при возможности установки автобетоносмесителя выше уровня бетонируемой конструкции, например, при заливке фундаментной плиты и возможности заезда автомобиля на дно котлована. Способ бетонирования по лотку использовался при нулевом цикле производства работ, т.е при устройстве монолитного железобетонного ростверка.

Для подачи бетонной смеси в бадьях или бункерах используют имеющиеся грузозахватные механизмы. Бадьи имеют объем 0,3..1м3 и для удобства подачи бетонной смеси выполнены в виде «рюмки», на которую для полного ее опорожнения устанавливают вибратор (фото 15).

Фото 15.

Фото 16.

На объекте бетонную смесь при бетонировании плиты перекрытия подавали с помощью бетононасоса, при бетонировании стен и колонн бетонную смесь к месту укладки подавали в бадье с помощью грузозахватных механизмов (фото 16,17).

Наибольшее распространение при укладке имеют бетононасосы. При объеме укладки до 80 м3 бетона в смену используют отечественные или импортные автобетононасосы на базе автомобилей КамАз, МАЗ, «Мерседес».

Фото 17.

Автобетононасосы оснащены загрузочным бункером, насосом и раздаточной стрелой. Бетонную смесь подают в вертикальном (до 80 м) и горизонтальном (до 360 м) направлениях. При строительстве объектов с потребностью бетона более 60 м3 в смену, а также зданий повышенной этажности (более 20 этажей) применяют стационарные бетононасосы в комплекте с раздаточными бетоноукладчиками. Бетоноукладчики, имеющие вылет стрелы до 60 м, устанавливают на смонтированные конструкции здания или вспомогательные опоры. Бункер бетононасоса соединяется с бетоноукладчиком с помощью вертикального трубопровода, по которому и поступает смесь.

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

Необходимость усовершенствования технологии сборно-монолитного домостроения

Библиографическое описание:

Лисникова, Е. А. Необходимость усовершенствования технологии сборно-монолитного домостроения / Е. А. Лисникова. — Текст : непосредственный // Молодой ученый. — 2019. — № 22 (260). — С. 167-169. — URL: https://moluch.ru/archive/260/60027/ (дата обращения: 26.12.2020).



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

Ключевые слова: сборно-монолитный каркас, сборно-монолитное домостроение, технология КУБ.

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

Альтернативой этим двум методам является метод сборно-монолитного домостроения, который сочетает в себе преимущества крупнопанельного и монолитного строительства. Конструктивные элементы зданий, построенных по данной технологии, могут быть как монолитными и производиться на стройке, так и сборными, произведенными на заводе (например, наружные стены здания и перекрытия сделаны из сборных элементов, а внутренние стены — монолитные).

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

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

Технология КУБ

Для различных условий изготовления и нагрузок в разное время было разработано несколько вариантов систем по технологии КУБ: КУБ-1, КУБ-2, КУБ-2,5, КУБ-2М, КУБ-2К, КБК, КУБ-3, КУБ-3V. Наибольшее применение нашли системы КУБ-2,5 и КУБ-3V. Унифицированная система сборно-монолитного безригельного каркаса главной своей особенностью являет отказ от ригелей, их роль выполняют плиты перекрытия, и использование многоярусных или одноярусных колонн без выступающих частей, на которые передаются вертикальные нагрузки перекрытий, а также горизонтальные при отсутствии связей.

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

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

Технология АРКОС

При данной технологии каркас здания состоит из многоярусных сборных колонн (чаще всего двух- или трехэтажных) и сборно-монолитных многопустотных перекрытий, которые состоят из монолитных балочных ригелей и многопустотных или ребристых плит перекрытия. В колоннах оставляют незамоноличенные отверстия, через которые пропускают канатную арматуру, которая впоследствии после набора прочности натягивается на диск перекрытия, а дальше уже отверстия и зазоры заливают бетоном. Чтобы увеличить несущую способность очень часто делают дополнительную набетонку по верху ригелей, это позволяет достигнуть увеличения на 10–15 %.

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

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

Технология Филигран

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

Технология РЕКОН

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

Система «Сочи»

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

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

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

Литература:

1. Мордич, А. И. Эффективные конструктивные системы многоэтажных жилых домов и общественных зданий (12… 25) этажей для условий строительства в Москве и городах Московской области, наиболее полно удовлетворяющие современным маркетинговым требованиям. Отчет о научно-исследовательской работе / А. И. Мордич, В. Н. Белевич и др. — Минск: Институт БелНИИС, 2002. — 117 с.
2. Фомин Н. И., Исаев А. П., Зотеева Е. Э. Новые технологические и конструктивные решения для реализации инновационного потенциала сборно-монолитных систем гражданских зданий / Е. Э. Зотеева, Н. И. Фомин // Стройкомплекс Среднего Урала. — 2017. № 6(209). С. 31–32.
3. Шембаков, В. А. Сборно-монолитное каркасное домостроение. Руководство к принятию решений / В. А. Шембаков. — Чебоксары, 2005. — 120 с.

Основные термины (генерируются автоматически): сборно-монолитное домостроение, сборно-монолитный каркас, технология КУБ, колонна, многопустотная плита перекрытий, монолитное строительство, недостаток, несущая способность, поперечная арматура, строительная площадка.

микросервисов против монолитной архитектуры | MuleSoft

Микросервисы — важная тенденция в области программного обеспечения, которая может иметь серьезные последствия не только для ИТ-функции предприятия, но и для цифровой трансформации всего бизнеса. Микросервисы и монолитная архитектура представляют собой фундаментальный сдвиг в подходе ИТ к разработке программного обеспечения, который был успешно принят такими организациями, как Netflix, Google, Amazon и другими. Но каковы преимущества микросервисов перед монолитной архитектурой?

Архитектура микросервисов и монолитная архитектура

Во-первых, давайте сравним микросервисы и монолитную архитектуру.Монолитное приложение строится как единое целое. Корпоративные приложения состоят из трех частей: базы данных (состоящей из множества таблиц, обычно в системе управления реляционными базами данных), клиентского пользовательского интерфейса (состоящего из HTML-страниц и / или JavaScript, выполняемых в браузере) и серверной части. применение. Это серверное приложение будет обрабатывать HTTP-запросы, выполнять определенную логику, зависящую от домена, извлекать и обновлять данные из базы данных, а также заполнять представления HTML для отправки в браузер.Это монолит — единый логический исполняемый файл. Чтобы внести какие-либо изменения в систему, разработчик должен создать и развернуть обновленную версию серверного приложения.

Напротив, возможности микросервисов формально выражаются в бизнес-ориентированных API. Они заключают в себе основные бизнес-возможности и являются ценными активами для бизнеса. Реализация услуги, которая может включать интеграцию с системами записи, полностью скрыта, так как интерфейс определяется исключительно с точки зрения бизнеса.Позиционирование услуг как ценных активов для бизнеса неявно продвигает их как пригодные для использования в различных контекстах. Одна и та же услуга может быть повторно использована в нескольких бизнес-процессах или в разных бизнес-каналах или цифровых точках взаимодействия, в зависимости от необходимости. Зависимости между сервисами и их потребителем сводятся к минимуму за счет применения принципа слабой связи. Благодаря стандартизации контрактов, выражаемых через бизнес-ориентированные API, потребители не подвержены влиянию изменений в реализации услуги.Это позволяет владельцам сервисов изменять реализацию и модифицировать системы записи или составы сервисов, которые могут лежать за интерфейсом, и заменять их без какого-либо воздействия на нисходящий поток.

Процессы разработки программного обеспечения с использованием микросервисов и монолитная архитектура

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

• Монолитные приложения могут превратиться в «большой шар грязи»; ситуация, когда ни один разработчик (или группа разработчиков) не понимает целостности приложения.
• Ограниченное повторное использование реализовано в монолитных приложениях.
• Масштабирование монолитных приложений часто может быть проблемой.
• Трудно добиться оперативной гибкости при многократном развертывании артефактов монолитных приложений.
• По определению монолитные приложения реализуются с использованием единого стека разработки (например, JEE или .NET), что может ограничивать доступность «подходящего инструмента для работы».

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

• Рекомендуется, чтобы службы были небольшими, в идеале создаваемыми горсткой разработчиков.
• Если интерфейсы микросервисов предоставляются с помощью стандартного протокола, такого как REST-ful API, они могут использоваться и повторно использоваться другими службами и приложениями без прямого связывания через языковые привязки или разделяемые библиотеки.
• Службы существуют как независимые артефакты развертывания и могут масштабироваться независимо от других служб.
• Дискретная разработка сервисов позволяет разработчикам использовать соответствующую среду разработки для решения поставленной задачи.Компромисс между архитектурой микросервисов и монолитной архитектурой

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

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

Важно обеспечить тщательное управление предоставлением микросервисов и максимально автоматизацию SDLC. Отсутствие координации и автоматизации команды в стиле DevOps будет означать, что ваша инициатива в области микросервисов принесет больше боли, чем пользы.

Преимущества микросервисов по сравнению с монолитной архитектурой

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

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

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

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

Сокращение технического долга — важное преимущество микросервисов; однако измеримая экономия не ограничивается только техническим долгом. Микросервисы предлагают бизнесу другие преимущества, которые могут снизить затраты и повлиять на чистую прибыль. Эти преимущества включают:

• Гибкость. Разбивая функциональные возможности на самый базовый уровень, а затем абстрагируя связанные службы, DevOps может сосредоточиться только на обновлении соответствующих частей приложения.Это устраняет болезненный процесс интеграции, обычно связанный с монолитными приложениями. Микросервисы ускоряют разработку, превращая ее в процесс, который можно выполнить за недели, а не месяцы.
• Эффективность: использование архитектуры на основе микросервисов может привести к гораздо более эффективному использованию кода и базовой инфраструктуры. Нередко наблюдается значительная экономия средств на 50% за счет уменьшения объема инфраструктуры, необходимой для запуска данного приложения.
• Отказоустойчивость. Распределение функциональных возможностей по нескольким службам устраняет уязвимость приложений к единой точке отказа. Результатом являются приложения, которые могут работать лучше, сокращать время простоя и масштабироваться по запросу.
• Выручка: более быстрые итерации и сокращение времени простоя могут увеличить доход (либо за счет повышения эффективности, созданного с помощью идеологии возвратных платежей, либо за счет повышения вовлеченности пользователей). Удержание и вовлеченность пользователей увеличивается благодаря постоянным улучшениям, предлагаемым микросервисами.

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

Ознакомьтесь с дополнительными ресурсами по передовым методам внедрения микросервисов в вашей организации.

Какая архитектура подходит для вашего программного обеспечения?

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

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

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

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

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

Понимание этих различных подходов — один из ключей к эффективному созданию и поддержке качественных программных продуктов.

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

Монолитная архитектура

Что такое монолитная архитектура?

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

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

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

Многие современные веб-сайты и приложения начинались с монолитных архитектур. Amazon.com, например, был монолитом еще в 2001 году. Хотя сайт был построен с двухуровневой архитектурой, он был чрезвычайно тесно связан и вел себя как один большой монолит.

Стена из шести монолитов в Ольянтайтамбо, Перу — изображение любезно предоставлено Wikimedia Commons

Как монолитные архитектуры повышают производительность

Основным преимуществом монолитного приложения является простота его инфраструктуры, которая ускоряет развертывание и масштабирование.

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

Монолиты

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

Как монолитные архитектуры снижают производительность

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

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

«Развивающаяся система увеличивает свою сложность, если не ведется работа по ее снижению». — Меир Леман

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

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

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

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

Итоги монолитных архитектур

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

Монолиты

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

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

Микросервисные архитектуры

Что такое архитектура микросервисов?

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

Монолит против микросервисов — изображение любезно предоставлено Devbridge

Существует множество способов построения архитектуры микросервисов, но большинство из них имеют некоторые общие характеристики:

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

Netflix — яркий пример приложения, использующего микросервисы.

Оригинальный продукт

Netflix — веб-сайт, который позволял вам выбирать DVD-диски для доставки в ваш почтовый ящик — начинался как монолитное приложение, которое создавалось и управлялось с помощью традиционной модели разработки единой командой из более чем 100 инженеров.

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

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

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

Как микросервисы помогают продуктивности

Микросервисы

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

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

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

Облачные платформы

, такие как Amazon Web Services, также упрощают обслуживание, повторное использование и масштабирование микросервисов. Бессерверные предложения, такие как AWS Lambda, помогают разработчикам масштабировать свои микросервисы по горизонтали, что может быть сложно для приложения, которое не было предназначено для этого.

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

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

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

Как микросервисы снижают производительность

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

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

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

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

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

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

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

Итоги микросервисов

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

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

Делать выбор

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

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

Микросервисы

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

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

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

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

Понравился пост? Ты ему тоже нравишься.🙂 Пожалуйста, поделитесь им, используя кнопки «Поделиться» слева. Тогда присоединяйтесь к нашему списку рассылки ниже, подписывайтесь на нас в Twitter @thorntech и присоединяйтесь к нашей странице в Facebook для будущих обновлений.

Что такое монолит (монолиты против микросервисов)?

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

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

монолит можно считать архитектурным стилем или шаблоном разработки программного обеспечения (или анти-шаблоном, если вы относитесь к нему негативно). стили и шаблоны обычно соответствуют разным типам представлений (тип представления — это набор или категория представлений, которые можно легко согласовать друг с другом [clements et al., 2010]) и некоторые основные типы представлений, которые мы можем обсудить:

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

монолит может относиться к Любые основных типов просмотра выше.

модуль монолит

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

монолит распределения

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

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

монолит времени выполнения

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

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

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

заключение

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

Монолитная архитектура против микросервисной архитектуры: плюсы, минусы, практическое использование

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

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

Что такое монолитная архитектура?

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

Определение монолитной архитектуры

Схема монолитной архитектуры

Монолитная архитектура — это модель структуры программного обеспечения, которая создается как единое целое, где все инструменты Rails (ActionMailer, ActiveJob, ActionCable и т. Д.) Могут быть собраны вместе с кодом, который эти инструменты применяют. Инструменты не связаны друг с другом, но и не автономны.

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

Давайте вспомним, что такое Ruby on Rails «из коробки» в целом, что он может предложить, его преимущества и недостатки.

Rails — это фреймворк, который охватывает практически все варианты использования и потребности разработки. Что особенно хорошо, так это то, что с ним легко работать.

Как только вы напишете rails new вы сразу получите новое приложение. Сразу после этого вы можете создать любой REST API, какой захотите, и использовать помощники и генераторы Rails, что делает разработку еще проще.

Вам нужно отправлять электронные письма в приложении Rails? Используйте Rails ActionMailer. Или, может быть, вам нужно проделать жесткую обработку? ActiveJob может вам в этом помочь. С Rails 5 вы также сможете использовать веб-сокеты из коробки. Создавать чаты или делать приложение более интерактивным будет легко.

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

Разработка

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

Монолитная архитектура против микросервисной архитектуры: преимущества монолитных приложений

Преимущества и недостатки рельсов из коробки

Начнем с положительных сторон любого монолитного приложения. Выгоды:

• Легко разрабатывать благодаря большому разнообразию доступных инструментов, готовых к интеграции в приложения.Простота развертывания, поскольку все действия выполняются одновременно с одним каталогом.
• Быстрая разработка, потому что все эти инструменты Rails требуют минимальных усилий для применения. Монолитная архитектура означает, что вам не нужно думать, как все работает в таких инструментах, как ActiveJob, ActionMailer или ActionCable.

Монолитная архитектура имеет одно главное преимущество — простоту. Благодаря своей простой структуре нет необходимости выполнять множество сложных операций и дополнительных действий, которые требуются для сложных систем.

Монолитная архитектура против микросервисной архитектуры: недостатки монолитных приложений

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

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

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

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

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

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

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

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

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

Микросервисы против монолита: схема для монолитов

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

Плюсы и минусы монолитной архитектуры

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

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

Что такое архитектура микросервисов?

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

Определение микросервисов

[Схема архитектуры микросервисов

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

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

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

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

Монолитная архитектура против микросервисной архитектуры: преимущества микросервисов

Преимущества и недостатки микросервисов

В вопросе монолитного vs.Архитектура микросервисов, последняя имеет множество преимуществ, которые могут легко перевесить преимущества монолитов.

Преимущества микросервисов следующие:

• Мы не просто рассматриваем варианты использования, когда применяем микросервисный подход. Отделив микросервис от основного приложения и делегируя задачу отдельной службе, мы избавляем наше приложение от потенциально большего и тяжелого. В качестве бонуса вместо одного тяжелого процесса у нас будет несколько процессов с правильным распределением нагрузки на сервер.
• Если часть вашей экосистемы микросервисов становится узким местом, вы можете масштабировать ее по горизонтали независимо от других компонентов приложения. Все, что вам нужно сделать, это организовать правильную связь между этими сервисами. Если вам больше не нужен микросервис, вы можете легко отключить его, не рискуя что-то сломать в основном приложении (в зависимости от вашего типа связи).
• Все микросервисы требуют работы по принципу черного ящика. Тем не менее, вы всегда можете изменить что-то, если это необходимо, чтобы избежать накладных расходов.
Архитектурный стиль
• Microservices способствует повторному использованию. Если мы позаботимся о независимости микросервисов от проекта, мы получим автономные микросервисы, которые можно будет использовать в других проектах для аналогичных задач.
• Все микросервисы могут быть полностью автономными. Таким образом, падение одного из них не повлияет на работу основного приложения. Конечно, этот обвал дестабилизирует микросервис, за который он отвечает, но все остальное останется стабильным. Когда микросервисы разделены, тестирование становится проще.Вам не нужно загружать всю систему для запуска модульных тестов микросервиса.

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

Монолитная архитектура против микросервисной архитектуры: недостатки микросервисов

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

Недостатки микросервисов следующие:

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

Микросервисы против монолита: схема для микросервисов

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

Сравнение соотношения цена / возможности микросервисов и Rails Out Of The Box

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

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

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

Пример микросервисов: практическое использование

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

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

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

Ноу-хау

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

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

Например:

• правильный путь: Главное приложение → микросервис → Сторонний API
• неверный путь: основное приложение ⇄ микросервис ⇄ сторонний API

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

Это уместно, если в нашей архитектуре более одного микросервиса, и они не требуют последовательной обработки. Более того, если вы используете прямую связь между основным приложением и микросервисом, микросервис будет доступен через какой-то порт. Вам нужно будет предвидеть его недоступность для внешнего мира (сегодня 2108, и у нас есть Kubernetes, Docker и другие, которые помогут нам в этом, но мы все равно должны быть осторожны).

Если вы выбираете связь через pub / sub (шину сообщений), вам следует вызвать микросервис как процесс-демон, и проблема, упомянутая выше, будет решена сама собой.

Представьте, что у нас есть основное приложение, которое выполняет требуемую функцию, отправляет данные в шину сообщений, и все его слушатели немедленно получают их. Микросервис Websockets, микросервис Mailer, микросервис SMS и другие предполагаемые микросервисы получают эти данные одновременно и обрабатывают их одновременно. Кажется, это более эффективное решение, чем прямое общение между ними, не так ли?

Поток данных в архитектуре микросервисов

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

3. Разложите на микросервис функциональность, которая не требует никакого взаимодействия с основным приложением (например, отправитель электронных писем, SMS, push-уведомления или другие запросы к стороннему API). Если вы учли все три пункта, вы должны были получить архитектуру, которая не позволит всему приложению дать сбой, даже если ваш микросервис станет неактивным.

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

Ноу-хау: создание микросервисов

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

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

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

Следующие правила могут сильно помочь вам с микросервисами:

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

То есть, находясь в папке микросервиса и выполнив команду ruby ​​server.rb (файл для запуска микросервиса), мы должны заставить микросервис сделать следующее:

• Загрузить использованные драгоценные камни, библиотеки поставщиков (если используются) и наши собственные библиотеки
• Использовать конфигурацию (зависит от среды) для адаптеров или классов клиентских подключений
• Установите клиентские соединения (здесь имеются в виду постоянные соединения).Поскольку ваш микросервис должен быть готов к любым отключениям, вам следует позаботиться о закрытии этих клиентских подключений в такие моменты. EventMachine и его механизм обратного вызова очень помогает в этом.
• После этого ваш микросервис должен быть загружен и готов к работе.

2. Инкапсулируйте связь со службами в адаптеры с абстрактными именами. Мы называем эти адаптеры в зависимости от их роли (PubSub, SMSMessenger, Mailer и т. Д.). Таким образом, мы всегда можем изменить внутреннюю реализацию этих адаптеров, заменив службу, если имена наших классов не зависят от службы.

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

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

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

4. Разработайте свои адаптеры для загрузки конфигураций из среды (согласно [12factor] (https://12factor.net/config)). Если вы предпочитаете использовать файлы yml для переменных env, вы можете более четко разложить свои обязанности в соответствии с именем yml.Взгляните на пример yml для настройки адаптера для доставки SMS-сообщений (Twilio в нашем случае):

.