Автор: Kai Waehner

Оригинал: Microservices Apache Kafka Domain Driven Design

Микросервисы тесно связаны с предметно-ориентированным проектированием (Domain-Driven Design, DDD). Это такой подход к проектированию, при котором для программного обеспечения продумывается и постоянно развивается бизнес-модель — независимо от физической инфраструктуры, на которой все это работает. Всё чаще этот подход упоминается в связи с Apache Kafka.

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

В этой статье мы поговорим о том, почему Apache Kafka де-факто стала стандартом и основой архитектуры микросервисов. Kafka не только заменяет другое промежуточное ПО, но и позволяет создавать сами микросервисы с помощью DDD и нативных API Kafka, таких как Kafka Streams, ksqlDB и Kafka Connect.

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

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

Хотя с микросервисами все не так просто, у них много преимуществ, включая разделение на компоненты, при котором мы создаем децентрализованную архитектуру на основе бизнес-процессов. Умные эндпоинты и глупые каналы обеспечивают нам вот что:

Приложения на микросервисах максимально независимы и сфокусированы на одной задаче — у них своя логика предметной области [которая применяется к отдельной части бизнес-задачи], и в этом смысле они похожи скорее на фильтры в классическом Unix-овом понимании: они получают запрос, применяют нужную логику и выдают ответ.
Мартин Фаулер (Martin Fowler)

Apache Kafka — платформа потоковой обработки событий для микросервисов

Какая технология нужна для создания архитектуры микросервисов? Ответ состоит из двух частей:

1. Как микросервисы будут общаться друг с другом?

Если речь о взаимодействии микросервисов, в первую очередь, в голову приходит REST, то есть обмен данными с помощью синхронных вызовов HTTP(S). Этот вариант подходит для большинства сценариев. Но модель «запрос-ответ» подразумевает соединение между точками, то есть отправитель привязан к получателю и наоборот, так что сложно изменить один компонент, не затронув другой.

Поэтому многие архитекторы используют промежуточное ПО как основу для взаимодействия микросервисов, чтобы создавать независимые, масштабируемые и высокодоступные системы. Для этой прослойки можно использовать что угодно — связующий код или фреймворк, брокер сообщений, вроде RabbitMQ, инструмент ETL (Talend), ESB (WSO2) или платформу потоковой обработки событий, например, Apache Kafka.

2. Какое промежуточное ПО мы используем (если используем)?

Популярность Apache Kafka для микросервисов можно объяснить тремя преимуществами платформы:

1. Публикация и подписка на потоки событий, как в очереди сообщений или корпоративной системе обмена сообщениями.

2. Отказоустойчивое хранение потоков событий.

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

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

Чтобы лучше понять, чем Apache Kafka лучше традиционных инструментов, вроде MQ, ETL или ESB, прочитайте Apache Kafka vs. Enterprise Service Bus – Friends, Enemies or Frenemies?

Но где связь между Apache Kafka и предметно-ориентированным проектированием?

DDD для создания и разделения микросервисов

Подход DDD впервые был описан в книге Эрика Эванса (Eric Evans). Он используется для создания систем со сложной предметной областью бизнеса. DDD ориентировано не на инфраструктуру, роутеры, прокси и кэширование, а на бизнес-логику для решения реальных бизнес-задач. Это отличный способ отделить создание бизнес-моделей от кода, который соединяет все вместе. Когда бизнес-логика существует отдельно от соединительного (plumbing) кода, программное обеспечение проще проектировать, моделировать, собирать и развивать.

Принципы DDD:

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

• Используем термины предметной области в коде.

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

Главная концепция DDD в этом смысле — ограниченный контекст (bounded context). В крупных проектах обычно много разных предметных моделей и ограниченных контекстов. Если мы объединим код из разных ограниченных контекстов, получим ненадежный и сложный для понимания продукт с кучей ошибок. Члены команды перестанут понимать друг друга и не будут знать, в каком контексте не следует применять ту или иную модель.

DDD требует явно определять контекст для применения модели. Мы должны установить границы и обозначить, какая команда отвечает за эту модель, как она будет использоваться в конкретных частях приложения, как она будет воплощаться физически, в кодовых базах и схемах баз данных. Когда мы помещаем модель в строго определённые границы, нам проще понять и реализовать каждый компонент, потому что мы работаем с одним ограниченным контекстом. Мы не отвлекаемся на код, который мог просочиться к нам извне. Как удачно сформулировал Дэн Норт (Dan North): Создавайте код, который помещается у вас в голове.

Применительно к платформе потоковой обработки событий эти принципы можно выразить примерно так:

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

Почему сюда так хорошо вписывается Kafka?

Apache Kafka и микросервисы на основе предметных областей

Apache Kafka хранит полученные сообщения, так что продюсеры и консьюмеры существуют совершенно независимо друг от друга:

• Компоненты на стороне сервера (брокер Kafka, ZooKeeper и Confluent Schema Registry) можно отделить от бизнес-приложений.

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

• Продюсеры могут создавать события, даже когда консьюмеры не работают.

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

• Консьюмеры обрабатывают данные в своем темпе (пакетами или в реальном времени).

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

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

Эта схема может относиться не только к бизнес-приложениям, но и к операциям в IT-отделе компании, отвечающем за кластер Kafka, где размещаются решения для использования внутри компании. Кластер Kafka часто развёртывается в инфраструктуре PaaS, например, Kubernetes и Confluent Operator. В облачных развёртываниях, где используются управляемые сервисы, вроде Confluent Cloud, обычно не нужны команды инфраструктуры.

Предметные модели, ограниченные контексты и единый язык

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

Для этого мы используем так называемый антикоррупционный слой (anti-corruption layer), который сопоставляет данные, используемые в одной предметной модели, с данными, передаваемыми между разными микросервисами или ограниченными контекстами. Этот паттерн не зависит от реализации, то есть его можно использовать и с событиями, и с подходом «запрос-ответ». В обоих случаях обычно используется протокол передачи данных (будь то схема для возврата данных из эндпоинта REST или схема, которая описывает событие, например, сообщение Avro в Schema Registry).

Антикоррупционный слой выполняет две задачи:

1. Защищает предметную модель от изменений.

2. Представляет границу между контекстами и описывает их связь в техническом смысле (поле A в сообщении связано с полем B в модели) и в терминах единого языка DDD — контрагент в схеме событий сопоставляется с заказчиком в предметной модели.

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

Соединение предметных областей с помощью Apache Kafka, Kafka Streams, ksqlDB и Kafka Connect

Стоит отметить, что Apache Kafka — это не просто система обмена сообщениями или слой интеграции. Это платформа потоковой обработки событий. Это значит, что она не только предоставляет прослойку для разделения микросервисов, но и позволяет выполнять сложные операции с данными, например, разделение, соединение, фильтрацию и обобщение в клиентском коде. Вот еще одно отличие Apache Kafka от традиционного промежуточного ПО с точки зрения ThoughtWorks:

…мы наблюдаем, как некоторые организации воссоздают антипаттерны ESB с Kafka — централизуют компоненты экосистемы Kafka, например, коннекторы и обработчики потоков вместо того, чтобы оставить их в ведении команд по продукту или сервису. Это похоже на очень нехорошие антипаттерны с ESB, когда всё больше логики, оркестрации и трансформации передаётся в централизованно управляемую ESB, так что возникает сильная зависимость от центральной команды. Пожалуйста, не совершайте таких ошибок.
Recreating ESB Antipatterns with Kafka

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

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

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

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

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

В примере выше показаны разные микросервисы. Одни используют REST (например, для взаимодействия между микросервисами и пользовательским интерфейсом), другие — Kafka Streams или ksqlDB для объединения событий из разных источников. Некоторые используют Kafka Connect, чтобы просто пушить события в базу данных, где они проходят дальнейшую обработку или используются напрямую с помощью паттерна генерации событий (event sourcing). Техническая реализация для каждого микросервиса не зависит от технологий, которые используются в других микросервисах.

Как создать такую систему

Как создать отдельные микросервисы со стримингом событий через REST, gRPC или другой протокол запросов и ответов — и так понятно. Создание системы на основе событий требует совсем другого подхода.  События могут быть использованы для построения систем самыми разными способами. Например, их можно использовать как сообщения без подтверждения (fire-and-forget) или как инструменты для совместной работы. Бен Стопфорд (Ben Stopford) в статье Build Services on a Backbone of Events подробно объясняет эти паттерны.

Также нужно решить, как мы будем управлять состоянием. Можно делать это в базе данных с помощью Kafka Connect или управляемого сервиса с использованием Kafka Streams API. Бен Стопфорд (Ben Stopford) подробно описывает stateful стриминг событий в микросервисах в статье Building a Microservices Ecosystem with Kafka Streams and ksqlDB.

Чтобы узнать больше о том, как Connect, Kafka Streams и микросервисы работают вместе, прочите эту подробную статью от Евы Бызек (Yeva Byzek). Наконец, создание экосистемы микосервисов — это только первый шаг. После создания их нужно мониторить, контролировать и поддерживать. Узнайте, как это делать.

Confluent предлагает функции RBAC для контроля доступа на основе ролей на Confluent Platform. Мы можем детально настроить, какие ресурсы (топик Kafka, Schema Registry или коннектор) будут доступны команде каждой предметной области.

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

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

Apache Kafka + DDD = разделённые микросервисы с потоками событий

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

Многие принципы проектирования DDD можно напрямую применять к системам на основе событий, в том числе не описанным в этой статье. Я обозначил самые распространённые технические трудности: как выделить приложение в ограниченный контекст, почему так важны отдельные контексты, зачем нужны предметные модели и как всё это связано с обменом сообщениями, Apache Kafka и событиями.

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

Пара слов о курсе по Apache Kafka от Слёрм

3 февраля стартует третий поток обучения Apache Kafka.

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

Для тех, кому обучение оплачивает компания: Слёрм — мастер по скоростному заключению договоров, времени мало, но мы всё успеем.

Посмотреть программу и присоединиться: https://slurm.io/kafka

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

Разрешение вороньего глаза – как пространственное, так и временное – весьма высокое. То есть, по разрешению экрана и по FPS врановые играючи уделывают кожаных мешков. Днём. А вот в темноте хуманы имеют серьёзное преимущество: с ночным зрением у вранов всё плохо. Это плата за хорошее цветовосприятие и высокую разрешающую способность.

Но самая главная фича вороньих глаз вовсе не в этом. В силу широкой специализации, вороны обладают уникальным гибридным зрением. Поясняю: в грубом приближении в природе есть два типа зрения: круговое монокулярное и фронтальное бинокулярное. Жертва и хищник (картинка с загнивающей «сова-голубь» прилагается). Круговое свойственно тем, кому надо быть всё время начеку. Идеальный вариант для них – VR-камера с обзором 360°, чтобы сократить до минимума мертвую зону, в которой таится опасность. Голубь, корова, утка, лошадь – прекрасные примеры. Очень часто обладатели такого зрения присматриваясь поворачивают голову правой или левой стороной в интересующему объекту, дабы он оказался напротив глаза. А вот то, что располагается у них перед носом, они видят плохо, самым краем сетчатки.

В противоположность этому, бинокулярное зрение охватывает относительно небольшой сектор впереди, зато позволяет рассмотреть его обоими глазами, а самое главное — за счёт стереоэффекта даёт возможность точно определить дистанцию до объектов в поле зрения. Это очень важно при атаке (а также, например, при прыжке с ветки на ветку). Примеры: орел, собака, кошка, сова (ВНЕЗАПНО, например, обезьяна, ибо ей промер дистанции критичней кругового обзора). Обладатели бинокулярки, присматриваясь, поворачивают нос (клюв, лицо) к предмету интереса.

Вернёмся к нашим бара… воронам. Расположение глаз, а также не вполне характерная для птиц подвижность оных (глаза у птиц большие, башка маленькая, и места для приводных мышц почти не остается) дают вранам уникальный перк: гибридное зрение. Посмотрите снова на пикчу выше. Ворона умеет в оба этих режима. Глаза у вранов могут как разъезжаться в стороны, обеспечивая обзор в почти 360° (на самом деле где-то около 320° по моим наблюдениям, со стороны затылка остаётся узенький сектор «слепой зоны»), так и сводиться буквально на кончик клюва, если им требуется. Таким образом, имея возможность кругового обзора, ворона не лишена и преимуществ бинокулярки; пока курица или утка тычет клювом в корыто наугад с погрешностью в пару сантиметров влево-вправо, ворона без проблем достает соринку из человеческого глаза, ибо несмотря на устрашающий вид, вороний клюв – высокоточный инструмент на стабилизированной платформе, оснащенный камерами высокого разрешения. Вдевали нитку в иголку? А теперь представьте, что руки не дрожат, а глаза (с опцией фокусировки практически в упор) расположены на пальцах. Это даёт вороне существенный бонус к тонким манипуляциям посредством клюва, а возможность мгновенно переключиться на круговой обзор не позволяет застать птицу врасплох. Кроме того, бинокулярное зрение дает заметный бонус к маневренности в полёте, ибо встроенный дальномер здорово облегчает расчёт траектории.

Автор: Даниил Ли

Оригинал

Скорее всего вы читаете эти строки в браузере, созданном Apple или Google. Если у вас в руках смартфон, то почти наверняка одна из этих компаний разработала его операционную систему. Вероятно, вы попали сюда по ссылке, размещенной на сайте Apple News, Google News или в социальной сети Facebook. И когда эта страница загружалась, вы получали данные от одного из вездесущих центров обработки данных Amazon. (Некоторые из приведенных выше тезисов не совсем справедливы для аудитории Хабра — прим. перевод.)

Amazon, Apple, Facebook и Google, известные как «Большая четверка», доминируют во многих сферах нашей жизни. Но они пришли к этому не в одиночку. Десятилетиями они скупали сотни компаний, чтобы наконец стать мировыми техническими гигантами.

Все представители «четверки» действовали по схожей схеме. Сначала они добились превосходства в своей первичной сфере бизнеса, например, в электронной коммерции (Amazon) или поиске (Google). Затем они начали отращивать «щупальца», покупая компании в смежных секторах, чтобы увеличить поток доходов и обойти конкурентов.

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

Возможно, вы знали многие из этих компаний еще до поглощения: например, Zappos, IMDb, Twitch и Goodreads — теперь они принадлежат Amazon. Возможно, вы также слышали и о более крупных сделках, таких как приобретение компанией Google компании Motorola Mobility или покупка Apple компании Beats Electronics. (А основатель Amazon Джефф Безос владеет газетой The Post).

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

На протяжении десятилетий Федеральная торговая комиссия и Министерство юстиции США занимались проверкой слияний и поглощений и оспаривали сделки в суде, если они угрожали здоровью рынка. Теперь, по мере роста могущества технологических гигантов, критики, обвиняющие эти компании в использовании монопольной власти для ослабления конкурентов, призывают к более тщательному контролю, утверждая, что приобретения основаны не на поиске инноваций, а на стремлении к контролю рынка — часть тактики, известной как «копируй, приобретай, убивай», для устранения конкуренции.

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

Amazon

От книжной лавки до главной трафик-артерии интернета.

Когда-то Amazon был скромным книжным интернет-магазином, но со временем превратился в «магазин всего на свете». Затем компания вышла за рамки электронной коммерции — отчасти благодаря своим успешным приобретениям.

Чтобы попасть на рынок бакалейных товаров, компания приобрела Whole Foods Market, ее каналы дистрибуции и розничные точки за 13,7 млрд долларов. Потом Amazon захотелось стать крупным игроком в сфере интернета вещей, и она поглотила несколько компаний, специализирующихся на системах домашней безопасности, а также компанию по производству домашних маршрутизаторов Eero. А с погружением в индустрию автономных транспортных средств Amazon выкупила массу стартапов и в этой сфере.

Теперь Amazon повсюду: в телевизоре с Prime Video, в умной колонке Echo, а также на веб-сайтах и в приложениях, которыми вы пользуетесь каждый день. В 2020 году выручка компании составила 386 миллиардов долларов.

Красивая интерактивная диаграмма — в оригинальной статье

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

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

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

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

«Мы стремимся стать самой клиентоориентированной компанией на Земле», — указано в бумагах.

Apple

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

Apple, основанная немногим позже инаугурации Джимми Картера (президент США, заступил на пост в 1976 году), является старейшей компанией «большой четверки» и имеет крайне длительную историю приобретений, которую можно разделить на два периода: до появления iPhone и после.

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

Apple также использовала свои приобретения для увеличения доходов от новых услуг, которые, по словам акционеров, призваны стимулировать прибыль в условиях стагнации продаж смартфонов. Приобретение компании Beats служит здесь идеальным примером: стриминговый сервис помог Apple войти в бизнес по продаже музыкальных прав и создать конкурента Spotify, который в свое время быстро вытеснил iTunes. В августе 2021 года рыночная стоимость Apple достигла 2 триллионов долларов, и теперь это самая дорогая компания в мире.

Красивая интерактивная диаграмма — в оригинальной статье

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

Компания отстает от конкурентов в области ПО для автоматизации, которое обеспечивает работу популярных голосовых помощников, таких как Amazon Alexa и Google Assistant, и ей необходимо привлекать компании и таланты, чтобы наверстать упущенное. При этом Apple планирует покупки для расширения в новых областях, таких как автономные транспортные средства и здравоохранение.

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

Google

От стартапа поисковой системы до властелина интернета

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

В первое десятилетие своего существования Google использовала поиск для создания мощного рекламного бизнеса, который приносил миллиарды долларов дохода — почти 40% всей интернет-рекламы в США приходится на Google. Затем компания инвестировала эти деньги в совершенствование своего основного бизнеса и в развитие новых направлений.

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

Красивая интерактивная диаграмма — в оригинальной статье

Google не новичок в общении со службой антимонопольного контроля. С 2010 года регуляторы Европейского союза провели три расследования в отношении компании, оштрафовав ее в общей сложности на 10 миллиардов долларов. Но позиции Google в Европе остаются так же сильны, как и прежде. Недавно компания столкнулась с новой волной расследований в США — на сей раз со стороны генеральных прокуроров штатов и федерального правительства.

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

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

Возьмем, к примеру, цифровую картографию. Google занимает около 80% рынка, согласно отчету Royal Bank of Canada, который приводится в антимонопольном отчете Палаты представителей. Она добилась этого не только благодаря созданию собственного инструмента и его популяризации, но и за счет покупки в 2013 году компании Waze — конкурента, который только-только начинал свою деятельность, но уже успел завоевать лояльную аудиторию.

Facebook

От судебных тяжб к доминированию на рынке социальных сетей

Facebook купила не так много компаний, как его коллеги по Big Tech, но именно ей принадлежит самое дорогое поглощение (прим. — на момент написания оригинальной статьи). В 2014 году Facebook приобрела мессенджер WhatsApp за рекордные 19 миллиардов долларов. В то время ценник шокировал аналитиков, поскольку в WhatsApp работало всего 55 сотрудников и приложение почти не приносило прибыли.

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

Двумя годами ранее Facebook купил Instagram за 1 миллиард долларов, и эта сделка сейчас рассматривается как поворотный момент в истории социальных медиа. Компания также пыталась купить Snapchat за 3 миллиарда долларов, но его основатель Эван Шпигель сумел дать отпор Марку Цукербергу.

Красивая интерактивная диаграмма — в оригинальной статье

В электронных письмах, полученных судебным комитетом Палаты представителей, один из руководителей Facebook сказал, что компания планирует тратить от 10 до 15% своей рыночной стоимости каждые пару лет, чтобы «укрепить» позиции на рынке за счет приобретений.

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

Facebook остается одной из наиболее широко используемых онлайн-платформ в США: согласно недавнему исследованию Pew Research, 69% американцев старше 18 лет активно пользуются ею.

Представители Facebook ранее неоднократно отстаивала политику в части поглощений, заявляя, что компания инвестировала миллиарды долларов в развитие и совершенствование WhatsApp и Instagram.

«Мы жестко соперничаем со многими сервисами по всему миру», — пишет в своем блоге Дженнифер Ньюстед, главный юрисконсульт Facebook. «Развитие интернета в последние 25 лет подарило людям сотни новых способов делиться новостями и общаться — и не в последнюю очередь благодаря непрерывной конкурентной борьбе».

Начнем с трёх недавних запусков Falcon 9, которые произошли 7, 13 и 19 января соответственно. В первый и третий полёт отправились 49 спутников Starlink, а во второй, — сборная солянка из разных спутников со всего мира, включая украинский спутник Сiч-2. Первая ступень во всех случаях благополучно приземлилась на морскую платформу, а вторая сгорела в атмосфере. Это были первые старты компании в 2022 году. А мы переходим к Старшипу.

Старшип на закате

Весной-летом прошлого года выдвигались самые разные даты первого орбитального полёта Старшипа (люди в основном ставили на осень-зиму 2021 года (а были люди, которые ставили и на лето)), но ни одна из них не была верна. Федеральное управление гражданской авиации США (FAA) должно провести экологическую экспертизу космодрома в Бока-Чика, дабы удостовериться в соответствии космодрома всем требованиям безопасности. Без данной экспертизы SpaceX не получит лицензии на первый орбитальный полёт Starship. Сроки выдачи этой лицензии неоднократно переносились и на данный момент FAA обязалась выдать её не позднее 28 февраля этого года. Соответственно — после получения лицензии начнется предстартовая подготовка и весной мы, возможно, сможем лицезреть первый орбитальный (точнее суборбитальный — 80 км) полёт прототипа.

Статус прототипов

За всё лето-осень-часть зимы, команда Starbase успела собрать ещё несколько прототипов для грядущих орбитальных полётов, старые были распилены. Также регулярно проводятся тесты с уже имеющимися изделиями, в основном — прожиги. Помимо проверки двигательных систем была задача узнать реакцию термозащитных плиток на столь значимые колебания конструкции. Результат — потери в плитках 1-3 штуки. В целом — некритично. Такого эффекта смогли добиться за счёт более совершенной технологии крепления плиток, где они стыкуются к корпусу за счёт механических защёлок, а не посредством одного лишь клея, как это было на челноках (тем не менее он никуда не делся и также играет значительную роль). Шаттлы за один полёт могли потерять больше 100 (!) термозащитных плиток. Так что надеемся, что Starship будет надежнее Шаттла хотя бы в области теплозащиты, что позволит ему быть куда безопаснее своего многоразового предшественника. Но это мы узнаем по итогам первых орбитальных полётов, так что ждём.

Теплозащита

Помимо прототипов на космодроме возводились новые инфраструктурные объекты (огромный ангар и несколько топливных хранилищ) и дорабатывалась стартовая «ферма». В частности была реализована в металле система захвата первой ступени Super Heavy «Mechazilla». Её суть заключается в «ловле» гигантского бустера во время его посадки, после этого она мягко опускает разгонный блок на стартовый стол. Также Мехазилла стыкует Starship с Super Heavy после завершения предстартовых мероприятий с последним.

Работа Мехазиллы

Она же на тестах

В целом, в Бока-Чика затишье. Ведётся спокойная работа над проектом, никто никуда не торопится. Решаются проблемы с серийным производством двигателей Raptor, получением лицензии на орбитальный полёт у FAA и прочее, и прочее… Так что ждём взрывного всплеска активности на базе уже через 2-3 месяца, когда начнется подготовка к орбитальному полёту Старшипа.

Изменения за год в Бока-Чика

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

Для кого создан данный сервис

• Владельцы магазинов

• Специалисты работающие в сфере аназиза данных

• Маркетологи

• Программисты

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

• Гибкая настройка конфигурации выгрузки данных

• Выгрузка данные в различных форматах

• Возможность создавать программные продукты на основе данного сервиса

• Поддержка со стороны квалифицированных инженеров-программистов.

Поддерживаемые форматы выгрузки

• JSON (современный формат обмена данными)

• XML (проверенный временем формат обмена данными)

• CSV, (csv файлы поддерживаются Microsoft Excel и другими программными продуктами)

• Microsoft Excel, (поддержка данного формата сейчас находится в разработке)

Домашняя страница сервиса

Сервис выгрузки данных доступен на сайте «Rapid API»

https://rapidapi.com/quasarbyte-quasarbyte-default/api/opencart4/

Необходимое расширение для OpenCart расположено на «GitHub»

https://github.com/QuasarByte/opencart-api

Доступные ендпоинты для выгрузки данных

Выгрузка данных на основе заданных конфигураций

• pipeline/selectTables/selectTablesAsJson

• pipeline/selectTables/selectTablesAsXml

• pipeline/selectTables/selectTablesAsCsv

Выгрузка категорий товаров

• categories/findHierarchy

• categories/findAllCategories

• categories/descriptions/findAllCategoryDescriptions

• categories/descriptions/findAllCategoryDescriptionsAsPlainText

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

• https://www.postman.com/

• https://n8n.io/

• https://curl.se/

• Языки программирования, например: PHP, Javascript, Java, итд

Структура запроса

• URL

• Заголовки

• Тело

Составные части тела запроса

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

Описание шаблона

Тело параметризуемого шаблона SQL запроса

• Описание полей набора данных

• Описание условия связи с другими наборами данных

• Описание параметров шаблона

Описание параметров

• Константные параметры

• SQL параметры

• Параметры в формате RSQL

• Параметры сортировки

• Параметры пейджирования

Структура ответа

Пример ответа в JSON формате

{ "products": [ { "product_id": 50, "productDescriptions": [ { "product_id": 50, "language_id": 1 }, { "product_id": 50, "language_id": 2 } ] }, { "product_id": 51, "productDescriptions": [ { "product_id": 51, "language_id": 1 }, { "product_id": 51, "language_id": 2 } ] } ] }

Пример ответа в XML формате

<products>     <productsRow product_id="50">         <productDescriptions>             <productDescriptionsRow language_id="1" product_id="50"/>             <productDescriptionsRow language_id="2" product_id="50"/>         </productDescriptions>     </productsRow>     <productsRow product_id="51">         <productDescriptions>             <productDescriptionsRow language_id="1" product_id="51"/>             <productDescriptionsRow language_id="2" product_id="51"/>         </productDescriptions>     </productsRow> </products>

Пример ответа в CSV формате

product_id
28

parentRowNumber,product_id,language_id
1,28,1

Контакты для обсуждения и ответов на вопросы

• Группа в Telegram: https://t.me/OpenCart_API_Russian_Language

• https://rapidapi.com/quasarbyte-quasarbyte-default/api/opencart4/discussions

• Email: hello@quasarbyte.com

С Уважением,

Роман Талуев

https://www.linkedin.com/in/taluyev/