Лично для меня сервис — это поток, занимающийся одним видом деятельности, по относительно однотипным запросам на эту деятельность, приходящим к нему откуда-то со стороны.
Такое ощущение, что мы скатываемся в спор о терминах. Как по мне, микросервис — это не поток. Это именно что сервис со своим внешним интерфейсом. У него внутри может быть как один поток исполнения, так и несколько.
Возможно, это мое личное заблуждение, но как по мне, разговор о микросервисах имеет смысл только когда у микросервиса есть доступный снаружи интерфейс (и соответствующий публичный контракт для его использования). Тогда можно строить сеть взаимодействующих микросервисов. Если же что-то скрыто от внешнего мира, тогда это уже не микросервис.
Возможно, я заблуждаюсь. Т.к. варюсь в мире C++, там микросервисы не такое распространенное увлечение.
Не понятно почему. Микросервис — это то, что видно внешнему миру (т.е. другим микросервисам). Между тем, далеко не каждый актор может быть виден снаружи. Т.е. запросто может быть микросервис из кооперации трех акторов, в которой один актор известен внешнему миру, а два других актора видны только этому актору.
В общем-то да, на акторах строить микросервисы достаточно просто. Но, имхо, актор все-таки более мелкая единица, чем «микросервис». Так, «микросервис» может быть реализован посредством нескольких кооперативно взаимодействующих акторов.
Есть рекомендация Карпова, которую сложно назвать удовлетворительной, т.к. она не решает исходной проблемы. И которая сама чревата другими возможными проблемами. Например:
const CSSValue* CSSTransformValue::ToCSSValue(....) const {
unique_ptr<CSSValueList> transform_css_value(
CSSValueList::CreateSpaceSeparated());
for (size_t i = 0; i < transform_components_.size(); i++) {
const CSSValue* component =
transform_components_[i]->ToCSSValue(secure_context_mode);
if (!component)
return nullptr;
transform_css_value->Append(*component);
}
return transform_css_value.get();
}
И есть другая рекомендация, которая решает и исходную проблему, и препятствует возникновению других ошибок.
И вот вы, весь из себя такой опытный в социльных проблемах разработки, приходите и говорите: «а ведь вашу рекомендацию можно неправильно понять, тогда как...» При этом вы сами не знаете, есть ли возможность поменять сигнатуры нескольких методов или нет.
Ну, OK. Если вы работаете в условиях, когда вам выдали таск пофиксить утечку памяти в ToCSSValue и ничего больше вы не можете (да и не хотите) сделать, то удовлетворяйтесь дальше своим знанием социальных проблем.
Только это не отменяет неудовлетворительности первоначальной рекомендации господина Карпова.
Вы уж определитесь, вы хотите поговорить о технических проблемах или социальных? Проблемы с менеджерами и конфликтами в git-е — это социальные проблемы организации процесса разработки. К которым можно еще и приплести, например, хз какой code style, в котором разрешено возвращать голые владеющие указатели. Или, скажем, отсутствие должного code review. Или неиспользование статических анализаторов.
А вот наличие API, которое чревато утечками памяти из-за того, что возвращаются голые владеющие указатели — это техническая проблема. И хорошее ее решение было указано.
Так вот, если вы хотите обсуждать социальные проблемы — то это не ко мне.
Начать нужно с того, что unique_ptr — это всего лишь доведенный до ума старый auto_ptr. Говнокод, который не использовал auto_ptr раньше и не использует unique_ptr сейчас, нужно переписывать. Есть на это время или нет — это уже вопрос приоритетов: хотят ли разработчики иметь нормальный код без утечек или их устраивают потенциальные дыры в их коде.
можно переводить на умные указатели слой за слоем, метод за методом
Можно сперва поменять сигнатуру CreateSpaceSeparated. Это уже устранит кучу проблем везде, где используется CreateSpaceSeparated. А не только внутри ToCSSValue. Затем можно поменять и сигнатуру ToCSSValue. Вот вы и получите постепенный перевод, только с меньшим количеством проблем.
Единственный разумный довод в пользу рекомендации Андрея Карпова может заключаться в том, что изменение сигнатур может поломать ABI. Но это не имеет отношения к «постепенному переводу». И не исправляет исходную проблему — возврат голых владеющих указателей.
За рекомендацию №1, вообще-то, нужно бить по рукам. Поскольку это лечение симптомов, а не болезни. Нормальная рекомендация должна включать в себя изменение сигнатур методов CreateSpaceSeparated и ToCSSValue. На вот такие:
Тогда сама сигнатура метода явно указывала бы пользователю, что возвращается владеющий указатель и что вызывающая сторона несет ответственность за его удаление.
То, что предлагаете вы — это заткнуть дырку в одном месте, но оставить ее во всех других местах, где могут вызываться CreateSpaceSeparated и ToCSSValue.
У нас CMake не основная система сборки, так что косяки в поддержке CMake возможны.
Видимо, поддержку поиска RESTinio через CMake мы добавим когда будем опакечивать RESTinio для vcpkg и conan-а.
А не дешевле было написать Node.JS плагин и потом обвязку на JavaScript?
AFAIK, это выгодно делать в случае, когда на C++ пишется какой-то «тяжелый» вычислительный код, необходимый Web-приложению. Но даже и в таких ситуациях не всем нравится сопрягать Node.JS и C++.
Т.е. хочется знать, почему решили именно в плюсовом коде работать с сетью?
Чаще всего это были задачи, когда уже есть работающий C++ компонент, к которому нужно присобачить HTTP-вход для того, чтобы этот компонент научился работать с внешним миром по какому-нибудь REST-у или XML-RPC. Тут (в наших условиях) было бы проще встроить http-вход прямо в C++ный компонент, нежели приделывать сбоку что-то вроде Node.JS.
proxygen, AFAIK, это фреймворк с полноценной реализацией встраиваемого http-сервера.
Сервер от Микрософта — это, скорее всего, C++ REST SDK. Опять же, это полноценный встраиваемый http-сервер. Но с никакой (на данный момент) производительностью под Unix-ами (это вроде как даже сами разработчики в обсуждениях на reddit-е подтверждали).
Да, акторы хранят указатели на mbox-ы. А mbox-ы хранят указатели на акторов, которые на mbox подписаны. Но со списками указателей на акторов в mbox-ах все достаточно просто: когда актор уничтожается, он отменяет все свои подписки. Соответственно, указатель на этого актора удаляется из всех mbox-ах, в которых этот указатель присутствовал. Поэтому если актор A отсылал сообщения актору B через mbox X, то после исчезновения B, mbox Х продолжит существовать, но указателя на B в нем уже не будет.
что Вы объясняете, почему ваш подход лучше, чем сырые указатели
Нет, такой цели не было. Была цель обрисовать условия, находясь в которых мы, в итоге, пришли к идее mbox-ов.
В то время как было бы интересно почитать, чем ваша реализация отличается weak_ptr и почему.
Так мы в конце-концов вообще ушли от того, чтобы акторы хранили ссылки друг на друга (тогда как другие фреймворки в этом плане следуют классической Модели Акторов). Вместо этого мы ввели дополнительный слой абстракции: почтовые ящики. У нас получается, что акторы для общения друг с другом должны использовать дополнительную сущность — mbox. Нет mbox-а — значит нет возможности общаться.
Это другой подход к организации взаимодействия между акторами. В чем-то он, наверное, хуже классической модели. В наших же сценариях он показался удобнее. Тем более, что со временем выяснилось, что под специфические задачи могут создаваться специфические mbox-ы со своей логикой.
Поинт в том, что микросервис может быть актором. Тогда вы правы. Но так же микросервис может быть представлен группой акторов.
Сервис для меня — это специфицированный и доступный снаружи интерфейс.
Возможно, я заблуждаюсь. Т.к. варюсь в мире C++, там микросервисы не такое распространенное увлечение.
Есть рекомендация Карпова, которую сложно назвать удовлетворительной, т.к. она не решает исходной проблемы. И которая сама чревата другими возможными проблемами. Например:
И есть другая рекомендация, которая решает и исходную проблему, и препятствует возникновению других ошибок.
И вот вы, весь из себя такой опытный в социльных проблемах разработки, приходите и говорите: «а ведь вашу рекомендацию можно неправильно понять, тогда как...» При этом вы сами не знаете, есть ли возможность поменять сигнатуры нескольких методов или нет.
Ну, OK. Если вы работаете в условиях, когда вам выдали таск пофиксить утечку памяти в ToCSSValue и ничего больше вы не можете (да и не хотите) сделать, то удовлетворяйтесь дальше своим знанием социальных проблем.
Только это не отменяет неудовлетворительности первоначальной рекомендации господина Карпова.
А вот наличие API, которое чревато утечками памяти из-за того, что возвращаются голые владеющие указатели — это техническая проблема. И хорошее ее решение было указано.
Так вот, если вы хотите обсуждать социальные проблемы — то это не ко мне.
Можно сперва поменять сигнатуру CreateSpaceSeparated. Это уже устранит кучу проблем везде, где используется CreateSpaceSeparated. А не только внутри ToCSSValue. Затем можно поменять и сигнатуру ToCSSValue. Вот вы и получите постепенный перевод, только с меньшим количеством проблем.
Единственный разумный довод в пользу рекомендации Андрея Карпова может заключаться в том, что изменение сигнатур может поломать ABI. Но это не имеет отношения к «постепенному переводу». И не исправляет исходную проблему — возврат голых владеющих указателей.
Тогда сама сигнатура метода явно указывала бы пользователю, что возвращается владеющий указатель и что вызывающая сторона несет ответственность за его удаление.
То, что предлагаете вы — это заткнуть дырку в одном месте, но оставить ее во всех других местах, где могут вызываться CreateSpaceSeparated и ToCSSValue.
А вообще было бы хорошо, если бы вы развернули свою мысль, а то осталось непонятно, что вы сказать хотели.
Видимо, поддержку поиска RESTinio через CMake мы добавим когда будем опакечивать RESTinio для vcpkg и conan-а.
Чаще всего это были задачи, когда уже есть работающий C++ компонент, к которому нужно присобачить HTTP-вход для того, чтобы этот компонент научился работать с внешним миром по какому-нибудь REST-у или XML-RPC. Тут (в наших условиях) было бы проще встроить http-вход прямо в C++ный компонент, нежели приделывать сбоку что-то вроде Node.JS.
Сервер от Микрософта — это, скорее всего, C++ REST SDK. Опять же, это полноценный встраиваемый http-сервер. Но с никакой (на данный момент) производительностью под Unix-ами (это вроде как даже сами разработчики в обсуждениях на reddit-е подтверждали).
Так мы в конце-концов вообще ушли от того, чтобы акторы хранили ссылки друг на друга (тогда как другие фреймворки в этом плане следуют классической Модели Акторов). Вместо этого мы ввели дополнительный слой абстракции: почтовые ящики. У нас получается, что акторы для общения друг с другом должны использовать дополнительную сущность — mbox. Нет mbox-а — значит нет возможности общаться.
Это другой подход к организации взаимодействия между акторами. В чем-то он, наверное, хуже классической модели. В наших же сценариях он показался удобнее. Тем более, что со временем выяснилось, что под специфические задачи могут создаваться специфические mbox-ы со своей логикой.