这是我参与「第五届青训营」伴学笔记创作活动的第 8 天。
今天，我主要学习了架构的相关知识。
一、架构的引入
当我们作为一名程序员，开始为实际问题设计代码时，我们就开始不自主的“设计”架构了。
假设我们毕业后，由于互联网寒冬找不到工作，考不上研，回老家开一个小卖部，那么我们作为“老板”，就需要自己进口各种货物，摆在货架上，还要当“销售”吸引他人来购买，若干若干。
等到小卖部的规模扩大后， 我们可能需要雇佣几位员工来协助工作，例如帮忙搬运货物、计算账单等，而作为老板的我们就得从具体事务中脱身，反过来组织和协调员工的工作。
再后来，我们成为了一个连锁集团的CEO，旗下拥有若干个超市，那么我们需要对所有超市进行统一调度，为他们分配货物，提供统一的培训和指导等，这就更加考验整体架构的水准了。
二、Web架构发展
那么，设计程序也是同样的道理（以Web服务为例）。
在初始状态下，我们的Web服务只有一个简陋的前端和后端，而且还没有分离，十分“朴素”。逐渐的，我们开始将Web服务进行拆分，使得前端和后端分属两个不同的服务器，称为“前后端分离”。
随后，我们发现后端实际上由两部分组成：处理程序和存储程序（数据库）。我们再尝试将其拆分成两个服务器，这样就构成了经典的MVC架构（Model-View-Controller 三驾马车）。
随着数据量的增大，我们的单台数据库已经逐渐无法承受负载了。比起更换一台更大的服务器，我们更应该尝试组建一个分布式的集群，将数据均匀分布，构成一套分布式的存储系统，此时我们需要考虑资源分配、存储冗余等一系列事项。
对于处理程序，我们同样会购买大批的运算服务器来处理运算服务，而在进行运算前，我们还需要设立若干个资源调度系统，将各式各样的请求分布到各台服务器上，称之为“负载均衡”。
而前端就不一样了，考虑到他们都是静态的，我们可能会购买若干个CDN进行加速，优化网络性能，但开发人员也需要研究如何让各个CDN的数据保持一致。。。。。。
随着系统规模的不断扩大，我们往往需要对整个框架不断进行修改，因此相比于后面不断推倒重来，不如一开始就建立一个尽善尽美的优秀架构。
