这个星期的两天休息时间，全在外到处跑！所以，今天这篇文章发的非常的晚！于是就有网友给我私信了，涛哥，今天怎么没更新文章呢？
我很感谢他，这说明他多少从我这里学到了一些知识，催着我更新也是一种幸福！
今天，我们讨论一个比较抽象的话题，架构到底是设计出来的还是演化（研发）出来的？
昨天还有人给我私信说微服务，说服务多小才算微服务？一看就是理解错了！微服务并不是说把大应用切割成小应用就是微服务了。这一块可以参考马丁福勒的原文，里面对微服务的描述可以总结为以下几点：
拥有一组小的服务
拥有独立的进程
轻量级通信
独立部署
自治的管理
- 去中心化的数据管理去中心化的数据管理去中心化的数据管理去中心化的数据管理
这个问题搞明白了之后，我们再来看另外一个问题。“Dubbo 是组装机，SpringCloud 是品牌机”。
这其实也是严重的一种错误的理解。首先，不说现在 Dubbo 的全家桶已经更新了多少个新框架出来了。单说，Dubbo 的负责人，每次阐述，Dubbo 的愿景都提到了，Dubbo 是作为 SpringCloud 一部分，Dubbo 不是取代 SpringCloud，而是 SpringCloud 生态的一部分。当然 Dubbo 脱离 SpringCloud 也是有生态的。
最后，我们再来说说，架构是设计出来的还是演化出来的这个问题。这一点也有人议论个半天，其实还是没认清软件开发和盖房子的本质区别。
主观上，架构是设计出来的。客观上，架构是演化出来的。架构师从一开始，就要有设计出一个好的架构的主观愿望。这个主观愿望会驱使架构师去深入地了解业务诉求（问题域）。这个主观愿望会驱使架构师在单体应用阶段就进行良好的模块划分设计，努力实现各个模块的高内聚、模块间的松耦合。为将来的微服务化打好基础。
但是，业务是不断变化的，技术团队对业务的理解也是不断深入和全面的。因此，初始阶段设计出来的架构大概率是不符合真正的业务模型的。所以，再好的架构都不会一尘不变，都是不断演化出来的。
所谓演化，是指某个服务会在某个阶段从单体中脱离出来。随着业务的发展，会有越来越多的服务从原来的单体或其他服务中脱离出来。一些服务之间或许还会合并成新的服务。
架构师不能因为架构是演化出来的而不在一开始就精心设计。架构师也不能觉得架构是设计出来的，而期望在一开始就设计出完美架构。在业务发展的各个阶段，架构师应该综合考虑团队能力、技术复杂度、投入产出比，让架构设计永远保持合理。
好的技术架构是合理的、而非完美的。
最后，关于开发，我在说一点。20 人的团队，和 200 人的团队效率是不一样的。并不是公司越大，团队人越多，公司人越多效率就越高。而是，随着业务，架构等的发展，会到一个瓶颈点，效率会下降。那些总是说，拷贝拷贝就可以完成开发的人绝对不是一个懂架构，懂软件开发的人！
这两天跑的太累了，就先简单的阐述到这里。有问题的可以留言评论，或微信私我！