hantsy

@yidinghe 这个没错，天下没有免费的午餐。马大叔文章也明确建议从单体应用开始，积累领域建模经验，为将来可能的微服务转形准备。

1. 在你不懂领域建模，搞不清自己项目需求的 Bounded Context 的时候，还是老实做好基本的东西，把业务逻辑先清理，这比什么都重要。

2. 微服务不仅是应用程序逻辑上细分，团队组织结构也要随之变化。

3. 微服务实施中 DevOps 是一等公民，如果在 Infrastructure 上不能做到自动化，不写测试，不做 CI、CD，还是算了吧。这个我了解过国内所谓在实施微服务的，基本很少去做，靠人肉运维还是算了吧，你永远不是微服务。

4. 微服务为容器而生，Spring Cloud 最大问题就是把微服务一些运维相关的东西耦合到应用之一，会导致写测试非常不方便。在 Spring Cloud 刚出来的时候，那时只有 Netflix 那一套，一个项目 Dropwizard 迁移过来，做了大量的 POC，最终我们只采用了 Spring Cloud 的日志跟踪，其他全部用容器（ Service Discovery, Load Balance 等）实现。

如果对微服务的一些模式有一定认知，你会发现用什么语言框架去实现都不是问题。当你可以驾驭微服务，完全可以混合使用多种语言，架框去实现。理想情况下，使用微服务可以发挥团队所有人员的天分，开发人员（一个小团队）完全可以用自己的擅长的技术去实现（ micro ） service，把产品做到极致。

你以为用了 Spring Cloud 就是微服务。

类似方案太多，但是个人觉得比较适合做 Admin 界面，不适合最终用户端的个性化。

@sm0king 剧中那个女的程序员，和 Richard 争论 用 Space 和 Tab 那个， 是一个真实的 Facebook 牛逼程序员。没仔细去挖，据说里面有很多硅谷人员客串。

第几季了？

@andylsr 那我再说一句你不爱听的，我非常不喜欢安排工作，也不喜欢别人安排我工作，一个员工什么都等上面安排才开始工作，只能说明你在工作中被动到了极点。一切听上面安排，事不关已，高高挂起的，为什么要招这种人？

软件开发需要高度自律，任务开发，测试过程最终与软件质量挂钩。

@smallSoda 你说的没错，“无 BUG”，这个比较扯蛋。所有的开源软件，只要是越来越流行，BUG/Issues 就会越来越多。

@MiracleGoogle 到了大公司，你会发现，一些 SB 制定的规范都是束缚，回过头想还是创业公司比较自由。

@andylsr 喜欢找借口的人永远都是把借口放在第一位，做事偷懒。