@
suikatw 以前一般用服务总线，其实就是现在微服务的雏形。你说 BAT 大项目，在洪荒时代，也不是一个项目跑的。。。他们也会划分项目的，那时候一般比较粗糙，没有注册中心、调用链监控、RPC 模块、协议一般也都是 HTTP，关于重试和降级策略一般都是自己写在项目里，把这些抽离出来就是 RPC 框架。有些说的也对，最最开始的确一个项目，京东以前还是
Asp.net 。。。然后前面挂负载均衡，报错有时候你还能看到
Asp.net 把异常堆栈抛到前端。。。
至于你说分目录，优点不说了，说缺点：
(1)随人员变动、项目扩大，你很难维持现有的结构。git 冲突 版本管理也是很难解决的问题。比如我写完了这个模块要上，但是别人需要依赖前一个版本，你需要等。你用 Dubbo 可以通过 group version 解决，可以同时支持多版本开发。
(2)只要有修改别人代码的可能，就一定会发生。所以专注自己系统，不会给多余的权限
(3)一个简单 BUG 的修改都将导致服务重新发布，并且编译和发布时间成本巨大，在发布时，容易造成故障，压力激增
(4)这种结构容易造成雪崩，一般的，比如物流系统故障，订单已经下达，可以通过 MQ 重试机制保障物流恢复后系统自动恢复。而单点一旦崩溃，将导致整个系统不可用，数据无法进入，也不可能恢复。
(5)项目实践会告诉你，随人的增加沟通成本会越来越大，最后新增加的人的效率将不足以弥补沟通成本。解决方式就是系统拆分，专注自己的系统。
(6)至于机器占有资源问题，那是因为你预估有问题，没有计算你需要的 QPS 和机器资源。估计都是差不多直接上去。另一方面，当系统使用人数增加后，比如看东西的人很多，但是买的很少，那我可以扩容商品模块，而不需要对订单系统进行扩容，系统大了资源消耗反而降低。
(7)维护成本增加是必然的，但可以通过技术去解决 HSF、Dubbo、SpringCloud，以及之后的服务网格都是在解决成本问题
(8)服务不是无限拆分的，一般系统确定时，系统设计这个阶段要占用 50%时间，划分领域。要注意事务尽量属于自己所属领域，避免跨服务的分布式事务以及跨库事务。
没有最完美的架构，具体问题具体分析，要不然要这么贵的开发和架构干嘛：
(1)你要是外包项目或者中小项目，或者人数少，那就一个项目跑呀。
(2)如果你项目开始就定位比较大，比如目标是全中国用户，那开始架构时就应该考虑到微服务的形式
也可以渐进式演化，BAT 京东 这些最初都是一个项目跑的，有钱时再慢慢变成了领域模型内切分，各个服务高内聚，低耦合，用 MQ 解耦合以及填谷消峰。