没事就多聚聚，反正也是不归路
我总算体会到了, 以前那本我只愿意抬一眼看看封面那宛如动物世界一般的图片的<<人月神化>>. 从现在体会开来软件开发就是如此, 一个焦油坑. 没有银弹, 就看有人否让我们不越陷越深而已. 别期望写出令自己可以满意的代码, 除非你有充足的时间可以去每天涂涂改改. 面对前辈留下的心血, 我们接过他们的枪(冠冕堂皇点是, 说穿就是烂滩子), 理解多个人的思想, 最后才发觉每个人思想不统一, 他们之间的思想又可以排列组合出不同的思想. 最后发觉自己在那焦油坑里又陷下去一点. 接着把能骂的能发泄的话都说出来,吃着instant food做完最大的补救, 然后同样的结局和场景会发生在接过你的烂摊子的那个人身上.
microservice
对于一个新事物的诞生，本能地套用已有的知识。特别是一个并不简单的东西，这算是一种高效的入门方法。微服务架构其实相当复杂，我是分成好几个阶段理解。
- 第一阶段，微服务架构就是去掉了ESB的SOA架构，只不过是通信的方式和结构变了。对于初级的使用者而言，这样理解没有太大问题。
- 第二阶段，没有了ESB，原本很多由ESB组件做的事儿，转到服务的提供者和调用者这里了。他们需要考虑服务的拆分粒。大体仍然算是SOA架构。
- 第三阶段，随着服务的数量大幅增加，服务的管理越来越困难，此时DevOps出现了。这个阶段的微服务架构，已经是跟SOA架构完全不同的东西了。
从传统架构，转向微服务架构。
- 建设好基础设施，RPC、服务治理、日志、监控、持续集成、持续部署、运维自动化是基本的，其它包括服务编排、分布式追踪等。
- 要逐步演进和迭代，不要过于激进，更不要拆分过细，拆分的粒度，要与团队的架构相互匹配。（康威定律）
- 微服务与数据库方面，是个很大的难点，可以深入了解下领域驱动设计，做好领域建模，特别是数据库要随着服务一起拆分。