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

Question

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

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

Это повлечет за собой очень высокую степень разделения интересов в той степени, в которой это нетолько (скажем) можно заменить нижележащую БД (т. е. из Oracle в MySQL), но можно заменить действительную базу данных типа (от SQL до KV или наоборот).

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

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

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

Так вотМое обсуждение: помимо использования (главным образом) текстовых протоколов есть какая-то главная причина, почему сложная внутренняя архитектура не должна быть реализована так, как я описываю, или есть какое-то веское обоснование, которое я упускаю дляиспользуя протоколы связи, такие как Twisted, AMQP, Thrift и т. д.?

ОБНОВЛЕНИЕ: Следуя комментарию @meagar, я, возможно, должен переформулировать вопрос: есть ли явные преимущества использования очень простого, гибкого и понятногоархитектуры (т. е. всех функциональных возможностей, представленных в виде серии API RESTful), достаточных для компенсации очевидного снижения производительности, возникающего при использовании этой архитектуры в серверном контексте?

Answer 1

[код] фактический тип базы данных может быть заменен (от SQL к KV или наоборот). [/ Code]

И любой, кто написал объединение между двумя таблицами, будет огорчен.Если вы хотите, чтобы «способность» переключалась на KV, вам не следует предоставлять API, более богатый, чем тот, который поддерживает KV.

Ответ на ваш вопрос зависит от того, чего вы пытаетесь достичь.Вы хотите держать каждый модуль в разумных пределах.Используйте надлежащие физические уровни кода, используйте определенные интерфейсы с побочными эффектами, используйте тестовые примеры для каждого успеха и неудачи каждого интерфейса.Таким образом, вы можете зависеть от таких вещей, как «когда пользователь заходит на бла-страницу, генерируется бла-факт пользователя, так что будут вызываться все зарегистрированные прослушиватели фактов».Это позволяет расширять систему, не имея прямых вызовов из точки А в точку В, и в то же время иметь некоторый контроль над сильно различающимися зависимостями.(Я ненавижу основы кода, где вы не можете найти все, чтобы найти все возможные ссылки на символ!)

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