最近订阅了一些架构方面的资料，阅读后获益匪浅，想着整理一些自己的体会与思考，形成架构方面的读书笔记，一来与大家交流，二来通过文字的形式检查自己到底收获多少！
“我们系统是MVC架构的”
“淘宝的架构好屌”
“最近在学习MySQL的架构”
“这个系统开发我们要用MVC框架来进行开发”
我们常常听到上面关于架构的各种描述，那么架构到底是指什么？系统、框架、架构三者之间是一个什么样的关系？下面让我们结合实际的例子一起来探究下。
架构的含义
小石最近加入了一家生鲜电商公司。公司现在的首要任务是把电商系统给做出来，让用户能够通过PC、App购买公司的生鲜产品。
关键词：系统，所谓系统可以简单理解为我们平时所说的应用，当然系统可以包含多个小系统，这里为了简单起见，我们就先假设只开发这样一个单体应用，包含了用户下单购买的基本功能。
小石通过分析其他电商系统，知道至少需要 用户注册登录模块、用户信息模块、商品模块、订单模块 系统才能够进行运转。
系统的功能确定了，该选择用什么样的语言进行开发呢？选择什么样的方式进行开发呢？与大家一起讨论后，大家认为现在阶段的首要目标是快速做出系统来，因此大家决定采用PHP来开发，并决定使用 Yii2 框架，数据库方面使用 MySQL，WebService使用Nginx。
关键词：框架，为了快速完成系统的开发，我们会采用一些已被业内实践确认的规范来进行，比如这里采用 YII2 框架，也就是采用了业内的 MVC 规范。所以可以认为所谓的框架就是确定了一些业内规范，从某种程度上对大家形成约束或者形成都能理解的规定。
从开始到现在，还没有写一行代码，一直在进行设计与讨论，讨论需要哪些功能，设计采用什么 结构，而这里的结构主要包括了两方面：逻辑的结构与物理的结构。所谓逻辑结构就是指系统是按照什么样的流程来运转，需要哪些功能来支持。所谓物理，就是当编码完成所有的逻辑后，系统采用什么形式来部署运行。
那么到底什么是架构呢？我理解的架构：在系统诞生之初，对系统进行的逻辑设计与物理设计。他是系统的草图，可以类比为建筑领域的设计图。这张图需要确定：
- 业务需要的功能模块划分（建筑设计需要划分区域功能）
- 技术选型，用什么框架、什么存储、什么缓存（建筑领域也要确认框架结构还是框剪结构）
架构是进化的
一个架构的0.1版本绝对不会是完美的，世界上也不存在完美的架构。像上面的小故事，我们采用最简单的架构，如下图（物理角度）：
我们把所有的功能写在一份代码里，所有的数据存在一个库里，所有的代码部署在同一个Nginx上，甚至还可能我们的Nginx、MySQL都部署在同一台机器上。
公司业务得以发展，人员得以增加，系统变得更加复杂。这个时候原来的架构，一无法满足业务快速发展，二无法让多人开发变得愉快。因为几十个人在同一份代码里进行编码，想一下都是头大。文件冲突、功能依赖、bug排查、测试功能，这些都无法愉快的解决。这时就得根据新的情况重新设计架构。
我们将代码功能进行拆分，将以前的模块拆分成独立的系统，将MySQL进行主从设计，利用Nginx做负载等等。
那么为什么不一上来就进行拆分呢？因为一开始人手不足，拆分过细，开发周期慢，业务也不需要如此细致的划分。
总结
架构是一个系统的草图（逻辑 物理角度），它是有生命的，随着业务的变化会不断演进。没有完美的架构只有合适的架构。
