这是我参与8月更文挑战的第18天，活动详情查看： 8月更文挑战
还记得在自己刚开始开发软件的时候，基本上都是一个单体应用，只是在代码模块按照了MVC模式来开发，将分为表现层，业务层，持久层，然后就将数据写入数据库，基本上都是下面的图模式，表现层负责渲染html页面，与前端接口交互，业务层负责处理数据逻辑处理，持久层将数据写入到数据库DB持久化数据，这就是经典的MVC模式，这种模式到今天都还在使用，但是在前几天自己刚刚工作的时候，能够开发出CRUD，然后将打包成WAR放到Tomcat运行就行（哦，不对，我当时实习的时候干的是C#，那时候用的服务器IIS，哎，不得不吐槽一下IIS真的难用，可能是我自己学艺不精吧，每次部署到IIS都是痛苦的经历，后来自己狠下来转做JAVA开发），基本上整体一个网站就是个单体应用，所有的代码都扔在一个工程里面，有时候改动一个小小的功能，都要动全身，看别人的代码那是真痛苦，还记得自己看过一个在线教育的项目代码，也用的是C#写的，打包出来上线的lib都差不多有1个G，跟数据库的交互都用的是存储过程来写的，有些存储过程都有1000多行，表都有400张左右，那才真叫一个痛苦啊，好了不多扯了，继续今天的主体吧，聊聊架构相关的事。
按照上面的MVC模式开发完成后，就扔到线上，资源充足的话，将数据库单独用服务器来部署，资源不充足就把应用和数据库一起部署到一台机器，根本都不考虑数据的访问量问题还有什么高可用，那些都是浮云，只要功能正常就是对的。
接下来我将以大家熟悉的电商网站来展示一下我这几年中对于软件开发架构思想的改变吧，先声明：下面的演变之路仅仅代表自己对于软件开发的架构的变动及看法，不喜勿喷，对于不正确的地方，欢迎评论区指出。电商涉及的模块比较多，就只用用户模块，商品模块，订单模块来作为切入点分析。
在最早的时候，基本上都是单体应用，所有的模块都在一个项目里，结构也比较单一。
想必看了上面的结构，基本上每个人都是从这个阶段走过来的，毕竟实践才是检验真理的唯一标准，跟随者网站用户数不停的多起来，访问量这个时候大起来，所有的东西都在一台服务器上，每天服务器都在高负荷运转，CPU转的飞快，这个时候就需要将数据库拆出去了，单独采用服务器来部署。
将数据库单独部署到另外服务器后，这样又可以撑一下，但是好景不长，突然某一天数据库服务器突然宕机了，交易数据丢了一部分，苦逼的熬了几个通宵终于从日志中将丢失的数据找回来，后来在网上发现MySQL有主从架构，果断安排起来。
对于数据库存储方案其实也是一步步演变过来的，在这里就不细细的详说，后面用专门的文章来聊聊存储方案的演变。随着业务量增加，业务服务器又撑不住了，访问量大，一到高峰期就会出现卡死，响应慢，严重的时候还会发生OOM，网上发现了个好东西，Nginx用来做负载，赶紧将业务服务器扩容，用多台来响应客户端的请求。
安排Nginx之前，整体项目需要该照，最典型的就是Session同步问题，这个Session同步后面的文章专门来讲解。后面随着公司的扩展，招的人员越来越多，对于这种单体项目维护成本越来越高，为了后面的长久发展随着微服务的兴起，还有Dubbo框架的出来，就开始对于单体项目的拆分，将不同的模块拆分到不同的系统间，每个模块的数据库也拆分出来。后来就讲究高可用，基本上每个组件都用高可用来保障。
看上面的图感觉这东西还变少了，其实这只是统称了，基本上每个点都做到了高可用，现在都有很成熟的方案，随着K8s+Docker的兴起，每个点都可以做到根据访问量来动态的扩容，真正的实现高可用，上面的架构图画的不是比较的详细，这里只是回归下自己这六年接触到的项目架构改变，里面非常多的细节都没有画出来。
其实现在看这些方案的改进，都是老一辈人一点点趟坑过来的，我们现在只是站在了巨人的肩膀上。
