@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 解耦合以及填谷消峰。

假如你把阿里所有业务写到一个项目里，项目大小 300G，项目占用内存 300G，加载字节码时间 1 小时。。。你感觉吓人不。
还有随着项目规模增大，人员投入和项目效率会呈现反比，划分微服务有利于扩容、维护、和推迟这种情况到到来。当然这是建立在你项目复杂，并且开发人员很多的情况，要是外包或者很少开发人员，就是应该写在一个项目里。

直接问多少钱呀，先付 30%-40%，然后做到一定程度付 40%，最后交接源码付 20%。如果说免费帮忙，那对方也应该直说，你有空交情好帮帮忙也可以的。下次你有重要的事情找他帮忙，他就不应该拒绝，这叫人情世故。

问题这玩意做出来后，一批人已经受益了，后续继续维护对 KPI 没什么帮助

incase 很好用

Confluence 好用，正版很贵。要不搭建一个 Gitlab 当文档也不错

别贷款租房，跑路你完蛋、你想转租也难、可能影响征信、还有那个免押金，蛋壳不是一直都是贷款可以免么。。。我记得之前我看的也是，建议半年租这样的。跟朋友或父母借点也就 1 万块钱

目前深圳最好，上海其次，杭州最低。深圳未来的定位和发展比前两个要高太多了。。

反正卖的时候建议硬盘要用专门工具进行文件粉碎，什么清空、删除、格式化都可以用软件恢复，有隐私要注意~

别去中兴，中船重工吧，还是事业单位~~

你这个是半路出家，学了会 python，还没学通，又转 golang，在编程方面还是个新手，还有很多可以进步的空间。我大学学了 4 年才算入门的事情，你 2 年就搞定，这太打击人了。加油~~

肯定会呀，有些债早晚要还。你高考考得不好，毕业后工作人家 985，你普通本科，能力差不多就是会优先选 985。你选了非计算机，别人计算机读了 4 年，哪怕学的很烂。也比从没学的好，能力差不多肯定选计算机专业。避免这种尴尬最好的方式是优秀的作品、背景、面试时的表现。

94 年，跳二家公司了。
第一家干到小组 leader C 轮 智慧城市.
第二家中台 A+轮 新零售. 现在在摸鱼+写网关服务。。。

分母，来降低中奖率

我待过的的公司基本都有测试 /质量管理部分，要是干外包其实可以不用，但是要做产品，稍微大一点，上线进度紧张的，没测试基本都会发生 GG 的