遗憾的是管理者、乃至技术架构师都不能真正地接受演进式设计（ Evolutionary Design ），尤其不能接受一个具有良好设计的系统，应该是能够被报废的，潜意识中总会希望系统建设能够一步到位，至少是“少走几步能到位”。
摘自 [凤凰架构]

针对你说的这几点，做一个个人浅显的回答：
1. 转发，比如说你一个微服务架构，支持一个 app 需要用到好几十个系统，你不可能给 app 开发人员几十个域名吧，这不得被骂死。app 统一通过一个域名（流量入口），在网关层，进行请求的转发，然后再返回给 app 端，是不是就友好很多了；
2. 流量控制，不说灰度什么的，就说个蓝绿发布。你上线的时候，总不可能不做控制吧，刚起来的应用，立马就收到大量流量了，或者还在请求你已经 [杀死] 的服务，但注册中心还没下线的服务，这不得大量异常；
3. 鉴权，api 网关的鉴权指的是请求用户对请求资源时候有访问权限，而不是业务上的 key，sign 验证。鉴权统一放在网关做，到了业务系统的流量，都认为是有访问权限的，这样业务系统只关注业务。而且有什么升级改造，都可以在网关统一进行。
以上个人愚见，希望能有所帮助。

我们 commit message 有需求的一般需要贴上 jira 链接，然后大致写下实现了什么。如果是修改 bug，要说下改动点，影响范围什么的

四川人，自己手工做面食基本和我无缘，蒸个馒头都能把狗打死的那种水平

@NibborQ 开车或者公交。公交 131 或者 838

我们现在一般是自增主键做 id，业务上设置个唯一键

同航空港到高新，猿粪啊

最近也在提升自己的代码能力，刚好新公司也会很尽职 review 代码，给一些意见。尽量做到领域内聚合，不做太多分支。遇到能快速返回的地方尽量快速返回。以下是我觉得对不同逻辑处理比较好的一种方式，这样的话，看代码的人不用在你的 if else 里面转晕了头

private final Map<Order.Type, BiConsumer<Order, SubmitParam>> EXTRA_PARAM_RESOLVER =
ImmutableMap.<Order.Type, BiConsumer<Order, SubmitParam>>builder()
.put(Order.Type.A, this::resolveForA)
.put(Order.Type.B, this::resolveForB)
.put(Order.Type.C, this::resolveForC)
.build();

我们用的 nacos，然后 gateway 自研的，感觉还行，蓝绿，灰度这种流量控制做得比较好

我个人的理解是把运维工作外包，用户只用关心业务就好了

要了再加字段，加表，前期业务都不确定的情况下，不要做得太开放，开出去容易，收回来难

我还以为是所有用户都有的呢

我只知道有很多地方性质的，成都地区有个猫狗找家，或者爱之家

别了啊，大学生暑假好好做点自己感兴趣的事情不好么