相信不少公司总有那么个人，拿着很高的titile，很好的背景，见证过大公司的架构，来了公司干的第一件事就是给公司架构升级，画一个架构图，比如
这样的
这样的
这样的
图片来源于网络，无意冒犯，仅仅举例
可以看到网上的架构图一大堆，也很容易画，然后各种人就都觉得自己能胜任架构师一职，画完架构图就开始指挥手下人干活，去优化，去拆分，开干。
但是上面的架构图能说明什么问题吗？能落地吗？并不能
因为实际的架构决策在上面的图中并不能反映出来，也不是一个实际的落地方案，完全落不了的，只能说是一个想法，仅此而已。最简单的我们来个提一些落地的技术问题
- 如何拆分服务(业务边界如何确定)?
- 如何组织服务与服务之间的层次关系？
- 如何设计接口？
- 本地缓存和分布式缓存如何选型?
- 数据库如何分库分表?
- 数据库如何拆分？
- 分布式事务如何解决？
- RPC调用选型用什么？
- 需要部署多少个节点(or Tomcat)？
- 数据库容量用多大的？
- 项目分包是用传统的MVC还是DDD？
- 技术框架的选型？版本？
- 具体如何拆分？是一步一步拆分还是全量拆分上线？
- ......
可以看到就此上面的一张架构图，随便一提一些问题，就没办法落地了，而那些所谓的“架构师”所画的架构图无非是复制了以前公司的一个架构，觉得这个架构好，我们以前是大公司就是这么干的，但是似乎很多人不明白什么时候需要微服务，什么时候需要分库分表，没有根据自身公司的一个业务量和一个业务背景去想。
再大的公司，自身的架构也是慢慢演变过来的，从单应用单库，到单应用分库分表，到微服务，到中台,拿最简单的淘宝的架构演进来说就是如此(感兴趣的可以去看看)。
都是慢慢演变过来，都是现有架构已无法支持目前或者未来的业务才需要做的技术升级，也是被业务所逼迫，而不是任职一来就画一张空洞的架构图，还不是根据公司的实际业务设计的。
架构本身就是一个大而广的概念，希望所有想做架构和要做架构的架构师都怀着一颗严谨的心，去设计架构，而不是空谈，否则在团队中是很难有技术领导力，很难服众的
