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