一个端口上的所有服务，还是每个服务都在其自己的端口上？
需要制作一堆（20+）服务（通常是单一目的服务 - 例如用户管理 - 使用多种方法）。
每个服务在 Visual Studio 中位于自己的端口/自己的项目中更好，还是在单个项目的单个端口上一次完成所有服务更好？
从扩展点来看，什么是最好的看法？另外，如果它们都部署在一台机器上，那么两种方法之间在性能方面是否有区别？
不知何故，将它们分开是有意义的，因此，例如，如果其中一项服务的使用率显着提高，它可以在多台计算机上单独扩展，您同意吗？
need to make a bunch (20+) of services (usually single purpose services - such as user management - with multiple methods).
is it better for each service to be on its own port / in its own project in visual studio OR do them all at once on a single port in a single project?
what is the best from scaling point of view? also if they are all deployed on a single machine, performance wise is there a difference between the two approaches?
somehow it makes sense to have them separate, so if for example, one of the services sees significantly higher use it can be scaled alone on multiple machines, do you agree?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 Web 服务，物理 TCP/IP 端口实际上并不重要，您应该使用标准 HTTP 端口 (80)，并确保 Web 服务器上有足够的负载平衡来满足预期的用户负载。
当资源（内存或处理能力）需求很高时，服务器的性能会下降，在不同端口上提供服务不会改变这种情况，如果您的用户负载超出了一台服务器上的可用资源，您将需要考虑创建一个服务器场或部署在可以根据您的需求进行扩展的云服务（例如 Amazon EC2 或 Microsoft Azure）。
项目细分取决于功能，具有相似功能且与相关后端资源交互的服务可以在同一项目上分组在一起，以实现扩展目的，但对于如何在项目上细分服务没有硬性规则，这是常识，并且尝试将相似的功能分组。
When it comes to web services the physical TCP/IP port is really not important, you should shoot for the standard HTTP port (80) and make sure you have adequate load balancing on the web server for the expected user load.
Performance on a server gets degraded when resources (memory or processing power) are on high demand, having your services on different ports won't change this situation, if your user load exceeds the resources available on just one server, you'll need to look into creating a server farm or deploying on a cloud service that can scale to you needs (Like Amazon EC2 or Microsoft Azure).
The project segmentation depends on functionality, services with similar functionality and that interact with related backend resources could be grouped together on the same projects, for scaling purposes, but there's no hard rule on how to segment your services on projects, is all common sense and trying to group similar functionalities.