前言
之前已经介绍过我们微服务开发的落地和迁移过程和各种经验教训，这次来聊一聊更加主观的东西。
微服务有没有简化开发
微服务通过将原本单个应用拆解为独立的子系统，降低了单个应用的复杂度，但整个系统的复杂度并没有因此下降，而且额外带来了单体应用没有的数据一致性，网络中断等问题，即单体复杂度< <各个微服务复杂度+微服务间复杂度+基础设施复杂度
由于整个服务被分为几个独立的微服务，那么服务的切分与API设计是设计的重中之重，这对于架构师的能力要求极高，什么你们团队没有架构师，那希望你们团队都是架构师。
通过高度自动化的基础设施，能够大幅降低微服务所带来额外复杂度，但整体复杂度仍比单体应用要高。
这个问题我觉得是没有简化开发，但微服务让开发超大型复杂项目的难度有效下降，简单项目上什么微服务。
微服务是否能提高复用度
看应用领域和设计，在良好的微服务拆分和设计的情况下，在相对固定领域下，微服务能够大幅提高系统的复用度。
同理如果你的业务是一堆不同领域的小型项目，那不好意思，单体应用显然更加适合你。因为在跨领域的情况下，就算是复用了部分模块，那也需要不少的改动。
微服务的导入能否提高研发效能
- 由于康威定律，要想充分发挥微服务的威力，你的开发团队一定是由纵向小组组成，一般4~9个人，小组中包括开发和测试人员，最好也能参与系统的运维
- 微服务的技术体系有利于大型组织开发超大型复杂系统，提高组织间的协作效率
- 微服务需要高度自动化的基础设施，基本意味着需要一个专职的工程效率团队，来进行基础研发平台的维护，工具链的开发等等。
所以这个答案是这取决于你的团队规模和基本素质情况，对于超大型团队绝对是能有效提升研发效能，对于中型团队则是看情况，对于小型团队个人认为是否定的。
结论
- 如果你还没有接触过微服务那么你确实是需要了解一下的
- 如果你们团队要导入微服务，而且规模小于20人，那还是悠着点，多问几遍自己真的要这样做么？
- 如果你们已经落地了微服务开发，就想问问你的头发还好么？
