用通俗的语言探索底层的逻辑！
朋友们好，我是bobo。
好久不见，十分想念！
今天和朋友们一起来聊一聊【架构】的那些事，尝试用大白话唠唠嗑！
第一部分：没有架构行不行？
开始今天的讨论之前，咱们先来看一个故事：
大型系统的本质问题是复杂性问题。
互联网软件，是典型的大型系统。
数百个甚至更多的微服务相互调用/依赖，组成一个组件数量大、行为复杂、时刻在变动当中的动态的、复杂的系统。
因此，软件工程师们常常自嘲，“when things work, nobody knows why”。
如果我们只是写一段独立代码，不和其他系统交互，往往设计上要求不会很高，代码是否易于使用、易于理解、易于测试和维护，根本不是问题。
而一旦遇到大型的软件系统，如互联网分布式应用或者企业级软件，我们常常陷入复杂度陷阱。
怎么解决复杂度的问题？
是的，答案就是架构！
想起一个笑话：
复杂系统的维护是一种玄学。
当一个大型软件系统出现bug的时候，最好的解决办法是什么？
是啥也不要做，赶紧去烧香拜佛，也许它自己就好了。要是动了啥，还不知道会造成什么更加毁灭性的后果。
啥意思，意思是压根就不知道问题出在哪！
解决问题的第一步是找到问题。
要想找到问题，最起码得要有点脉络可寻——这时候，架构就是那个脉络。
就像我们看高德地图。如果给你一堆全国各个县的地图，你怎么找？一团乱麻。
如果是按照“全国-省-市-县”这个的结构，就很清晰了，很容易就定位到您想要的地方。
这个结构就是架构。
如果是一个简单的软件，一个小企业，没有架构，也没啥问题。
但是，如果软件越来越复杂，企业的业务越来越复杂，没有架构可能就是一场灾难了。
因为，复杂度这个事是呈指数趋势而不是线性趋势增长的。
越是大型系统，越需要简单性。
架构就是解构复杂度，简化问题的抓手。
第二部分：怎么做一个完美的架构？
bobo的答案是：没有完美的架构。
怎么来理解？先问一个问题：
软件是建造出来的，还是“生长”出来的？
BUILT vs GROWN，that is the problem.
软件的动态“生长”，更像是上图所画的那样，是从一个简单的“结构”生长到复杂的“结构”的过程。
伴随着项目本身的发展、研发团队的壮大，系统是个逐渐生长的过程。
或者换一个主体，把“软件”换成“业务”，也是同样的道理。
业务也不是一开始就能设计出来的，还是逐步“生长”出来的。
所以，架构也不可能完美。因为架构本身只是现实的“投影”，业务在“生长”，架构也需要“生长”。
总而言之，bobo觉得对待架构这个事要有【辩证的思维】。
一方面，架构不可能生而完美，一开始可以做的简单点，关键是要做起来。
另一方面，架构需要不断完善，不要指望一劳永逸，不断迭代、不断生长才是正道。
