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