项目背景:
读大于写,大概是4:1的比例吧,用户量百万以上,并发4000左右(可高可低,高可到10K,低为1K)
几台服务器的性能都差不多,并且负载均衡基本都可以平均分给每台服务器
我是让他们通过负载均衡直接一对一面对用户呢(即ABCD都可以被直接访问)。
还是让他们各司其职呢(假设A,B为内存服务器,C为数据库,D为图片处理服务器),让他们一层一层接受用户访问。
给个建议吧
项目背景:
读大于写,大概是4:1的比例吧,用户量百万以上,并发4000左右(可高可低,高可到10K,低为1K)
几台服务器的性能都差不多,并且负载均衡基本都可以平均分给每台服务器
我是让他们通过负载均衡直接一对一面对用户呢(即ABCD都可以被直接访问)。
还是让他们各司其职呢(假设A,B为内存服务器,C为数据库,D为图片处理服务器),让他们一层一层接受用户访问。
给个建议吧
还是分开好一些。
如果不分开的话,看似能充分利用机器的资源,其实不然。不同类型的服务部署在一起,增加了服务器环境的复杂性,容易产生问题且不容易定位,同样不利于性能优化。
不同类型的服务对资源的诉求不同,内存服务器更注重内存,图片服务器则注重磁盘,部署在一起,如果因为内存瓶颈,会同样对图片服务器造成影响,导致磁盘资源的浪费。
所以分开部署,每种服务所在环境单纯,资源可以按需分配。
各司其职,分布式的集群概念就包括了一个系统中的不同部分。第一种方案,仅仅只做到了负载均衡,而且按照字面的意思,似乎是每台机器都会安装对应的应用以及数据库服务,这样的话数据的同步以及文件的同步问题能让你焦头烂额,所以采取经典的功能性硬件分包架构(即你说的第二种)是比较合适的方法。
接入层:负责接纳分发用户需求,安装负载均衡服务,服务器配置为 网络、内存、CPU 优先。
应用缓存层:按照业务和使用频率进行应用数据的缓存,这一层大多是页面缓存。网络、IO 优先。
应用层:负责接受接入层的分发,处理需求,安装具体项目应用,服务器配置为内存、CPU、IO 优先。(服务化系统的话可能还会再细分为逻辑层、服务层、持久层等,具体项目具体分析吧)。
数据缓存层:按照你的项目背景,在这层可以放置数据库索引,也可以按照业务需求以及具体硬件配置放置一些数据字典表。硬盘、IO 优先。
数据层:安装数据库服务以及文件存储服务,数据库服务基于你的描述可以进行读写分离配置。如果数据量比较大,还需要考虑数据库的分库设置。配置为硬盘、IO 优先。
在上述所有服务器之上,每层的服务器都应该按照主备原则进行容灾处理。
当然所有在硬件范围以外的架构都是空谈,不知道你们是怎么样的服务器,但是看样子似乎是一些差不多配置的,尽量试图进行改装一下,按照各层的需求进行适当的改装,机器不够可以考虑割虚拟机,但是虚拟机会消耗一部分服务器资源,具体怎么配置能达到性能最大化,这还得靠压测和之后的调优。
建议采取第二种方案。
我是感觉分开不好,你都分开,随便一个服务器崩了你程序就崩了,程序首先要保证的是稳定性,至于一个服务器跑多个程序增加服务器复杂性,是看你怎么部署的问题,单项服务在服务器上其实不相关的,排错什么做好日志就可以了,你四台做分布式+均衡,你的服务扩展和转移都是比较容易的,你都做成单台的,就不具备分布式系统的扩张性,性能碰到瓶颈了,你必须架构大改,改成分布式。总体来说,我认为第一种方案比第二种灵活很多
对于题主反馈的服务量级,应该往分离的方式做.
主要有两个考虑:
不同类型服务对于机器各项资源的要求和消耗不同,可以按需定制机器。这点楼上有其他同学说过了;
进一步的,不同服务放在一起特别是可能会有潜在影响的服务部署在一起,会提高系统的维护成本和不稳定性;举个极端的例子,你会考虑把测试环境和生产环境部署在一起吗,调整测试环境参数影响生产环境真是最不应该发生的事情。
进一步的,有人提到,部署在多处,实际上要应付多点出问题的情景。这个我觉得正好说反了
首先,业务层总是不能假设服务层安全稳定,需要对服务层失效有容忍甚至熔断机制
其次,所有服务放在一台机器上,如果单机挂了(例如磁盘满内存满cpu爆等情况)那就所有服务全挂。分散的话只是个别服务损伤。
还有个运维成本的考虑,早期可能web server和后端服务都放在一起的。后期流量和压力上来之后,肯定还是分工和专业化的方向去做了。
以上主要是个人理解,请参考~
有必要。服务器当然要各司其职了。服务器要分布式部署。面对流量压力横向扩展。甚至还需要灾备服务器。 一台服务器挂了,还有其他服务器补上。
这个问题本质在于水平扩展性,如果你通过负载均衡才可以访问ABCD那么就放弃了扩展性
所以我建议分开ABCD都为独立服务
然后具体还得分析哪一块是系统的瓶颈,然后单独再做负载均衡,扩展机器、分布式等等
最好分开
你这个应用是不断成长的
现在已经到了这个阶段了
即使你现在不分开
将来也会分开。