Создание микросервисов

Еще одной проблемой является порядок интеграции с инструментальным средством. Как уже говорилось, важно весьма тщательно продумать порядок интеграции между сервисами, а в идеале желательно вывести стандарты в отношении весьма небольшого количества типов интеграции. Но если для одного продукта решено использовать собственный двоичный протокол, для другого предпочтение отдано SOAP, а для третьего выбрана технология XML-RPC, то что делать? Еще хуже те инструменты, которые позволяют вам добираться до их базовых хранилищ данных, что вызывает те же проблемы связанности, о которых уже говорилось.

На наших собственных условиях

Продукты COTS и SaaS занимают свое место по праву, и невозможно, да и неразумно большинству из нас создавать все с нуля. Так как же все-таки решить все эти проблемы? Суть заключается в том, чтобы делать все на своих условиях.

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

Пример: CMS в качестве сервиса

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

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

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

Так как же быть? Поставить впереди CMS собственный сервис, представляющий сайт внешнему миру (рис. 4.11). Считайте CMS сервисом, чья роль состоит в том, чтобы позволить ему создавать контекст и возвращать его. В собственном сервисе вы пишете код и интегрируете его с сервисами по своему усмотрению. У вас есть контроль над масштабированием сайта (чтобы справиться с нагрузкой, многие коммерческие CMS предоставляют собственные дополнительные компоненты), и вы можете выбрать систему создания шаблонов, имеющую для вас определенный смысл.

Рис. 4.11. Скрытие CMS с помощью своего собственного сервиса

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

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

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

Пример: многоцелевая CRM-система

CRM, или Customer Relationship Management, то есть система управления взаимосвязями с клиентами, — это часто встречающийся инструмент, считающийся неким чудовищем, способным вселить страх в душу даже самого отважного архитектора. Этот сектор, судя по характеристикам таких поставщиков, как Salesforce или SAP, изобилует примерами инструментов, пытающихся все делать за вас. Это может привести к тому, что сам инструмент может стать и единственной точкой сбоя, и запутанным узлом зависимостей. Многие реализации CRM-инструментов, попадавшиеся мне на глаза, являли собой массу наилучших примеров связанных (в отличие от сцепленных) сервисов.