История изменений
Исправление micronekodesu, (текущая версия) :
Ведь у нас ко-во портов ограничено и если с каждым пользователем делать по коннекту, то быстро закончится.
Коннект по TCP это "адрес клиента + порт клиента + адрес сервера + порт сервера". Разные адреса клиентов позволяют серверу принимать неограниченное* число коннектов (с TCP-ограничением в 65535 на клиента), или в роли клиента поднимать до 65535 коннектов до апстрима (проксируя запросы). В случае когда сервер принимает подключения никаких проблем нет. Когда он проксирует запросы - ну просто "добавляем ему айпишников", каждый из которых дает нам еще 65535 коннектов до апстрима.
* ну с учетом того что серверу хватает памяти и прочих ресурсов чтоб все это обслужить.
А не много для одного человека получается? И архитектуру продумать и код написать и инфраструктуру настроить...человек-оркестр.
Так один из немаловажных аспектов этой идеи это то что вы разрабатываете не монолиты, а маленькие сервисы. Конечно когда у вас проект на миллиарды KLOC то не то что один человек не осилит, с этим целые команды годами пытаются справиться. А когда у вас проект уровня хэлловорлда то вы сами можете и в архитектуру, и в кодинг, и в тесты, и в деплой и эксплуатацию.
Конечно есть те кто продумывает архитектуру всего проекта (как все эти куски в кучу соберутся) и инфраструктуру (что и как будет разворачиваться), но мне кажется на этапе знакомства с этой практикой и без опыта "простого" применения всего этого такими вопросами голову забивать рано.
Исправление micronekodesu, :
Ведь у нас ко-во портов ограничено и если с каждым пользователем делать по коннекту, то быстро закончится.
Коннект по TCP это "адрес клиента + порт клиента + адрес сервера + порт сервера". Разные адреса клиентов позволяют серверу принимать неограниченное* число коннектов (с TCP-ограничением в 65535 на клиента), или в роли сервера поднимать до 65535 коннектов до апстрима. В случае когда сервер принимает подключения никаких проблем нет. Когда он проксирует запросы - ну просто "добавляем ему айпишников", каждый из которых дает нам еще 65535 коннектов до апстрима.
* ну с учетом того что серверу хватает памяти и прочих ресурсов чтоб все это обслужить.
А не много для одного человека получается? И архитектуру продумать и код написать и инфраструктуру настроить...человек-оркестр.
Так один из немаловажных аспектов этой идеи это то что вы разрабатываете не монолиты, а маленькие сервисы. Конечно когда у вас проект на миллиарды KLOC то не то что один человек не осилит, с этим целые команды годами пытаются справиться. А когда у вас проект уровня хэлловорлда то вы сами можете и в архитектуру, и в кодинг, и в тесты, и в деплой и эксплуатацию.
Конечно есть те кто продумывает архитектуру всего проекта (как все эти куски в кучу соберутся) и инфраструктуру (что и как будет разворачиваться), но мне кажется на этапе знакомства с этой практикой и без опыта "простого" применения всего этого такими вопросами голову забивать рано.
Исходная версия micronekodesu, :
Ведь у нас ко-во портов ограничено и если с каждым пользователем делать по коннекту, то быстро закончится.
Коннект по TCP это (адрес клиента, порт клиента, адрес сервера, порт сервера). Разные адреса клиентов позволяют серверу принимать неограниченное* число коннектов (с TCP-ограничением в 65535 на клиента), или в роли сервера поднимать до 65535 коннектов до апстрима. В случае когда сервер принимает подключения никаких проблем нет. Когда он проксирует запросы - ну просто "добавляем ему айпишников", каждый из которых дает нам еще 65535 коннектов до апстрима.
* ну с учетом того что серверу хватает памяти и прочих ресурсов чтоб все это обслужить.
А не много для одного человека получается? И архитектуру продумать и код написать и инфраструктуру настроить...человек-оркестр.
Так один из немаловажных аспектов этой идеи это то что вы разрабатываете не монолиты, а маленькие сервисы. Конечно когда у вас проект на миллиарды KLOC то не то что один человек не осилит, с этим целые команды годами пытаются справиться. А когда у вас проект уровня хэлловорлда то вы сами можете и в архитектуру, и в кодинг, и в тесты, и в деплой и эксплуатацию.
Конечно есть те кто продумывает архитектуру всего проекта (как все эти куски в кучу соберутся) и инфраструктуру (что и как будет разворачиваться), но мне кажется на этапе знакомства с этой практикой и без опыта "простого" применения всего этого такими вопросами голову забивать рано.