此文非常长，请慎读！
不知不觉就写了这么多，其实很多问题还没梳理清楚，大致从我开始学习写代码（05年吧）开始到现在，感受到关于软件开发的变迁发展。很多程序员都不太清楚各种架构、以及辅佐这些架构的框架、思想、风格、设计模式是干什么的，出于什么目的、为什么使用，以及出现这些架构的时代背景，所以，作为梳理写了这篇。可能有些地方理解的不对，水平有限，请勿拍砖（无辜的大眼睛望着你们）
本文的小标题模块都是根据时间线写的，都有先后出现的逻辑关系，请勿跳着阅读断章取义的理解，谢谢！
在我工作之前的学生时代，流行桌面软件客户端C/S结构，刚开始工作时B/S结构中传统MVC已经进入衰退期，前后端分离的接口方式以及微服务开始流行。
系统架构的作用：
一个系统是为具体的业务目标而服务的，随之而来的问题是，选用哪种系统架构才最适合。但在敏捷开发的时代，业务目标可能不明确，追求小步快跑、快速迭代，其架构设计也应具有良好的适应性，绝对定性的采用某套成体系的架构设计方法已经无法满足瞬息万变的业务需求。
先来回顾一下软件应用系统架构的历史：
三层结构
在说总体的架构之前，首先要明确一个概念，也就是软件设计的基础结构，三层结构模型：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。在桌面软件时代，比如我们用的办公软件WORD，它的软件开发结构就是这样三层，表现层负责与用户交互，业务逻辑层负责处理用户编辑文本的各种操作，数据访问层负责将用户编辑的结果数据保存进文件或者对用户保存的文件进行访问和读、写。
MVC
在其中，不得不说MVC（Model模型，View试图，Control控制器）在其中的作用，为了应对图形化操作系统到来，原本在DOS下命令行式的软件需要图形化的展示，但它的业务逻辑层和数据访问层没有太大变革，于是二十世纪八十年代针对表现层的MVC设计模式被提出。
C/S结构
之后，随着软件行业的发展，OA、ERP等软件的需求增长，出现基于桌面客户端与局域网服务器通信的C/S（Client/Server）结构模式，表示层存在于C端Client，而业务逻辑层、数据访问层在Server端。就像是我们现在智能手机的原生App（区别于H5方式的Hybrid App）访问服务器的这种模式。表示层的MVC设计模式在C端上展现，原生App就是基于这样的MVC图形界面展示设计模式产生的web MVC，如iOS的Object－C：视图类：UIView，和控制器类：UIViewController。Android中JAVA的Adapter、Activity等。
B/S结构
后来，C/S结构太重，每一个企业应用软件都需要安装客户端，就像现在手机里好多App，而这些应用的表示层大都差不多（都是一些选择框、输入框、展示列表等），于是出现了基于浏览器的B/S结构，即Browser/Server(浏览器/服务器)结构。使用浏览器作为表示层的统一解析器，展示交互界面，和现在流行的H5方式的Hybrid App、微信的小程序等很相似，注重轻量化，跨平台的特性。
注：MVC 的概念最早出现在二十世纪八十年代的施乐帕克实验室中（发明图形用户界面和鼠标的实验室），当时施乐帕克为 Smalltalk 发明了这种软件设计模式。
SSH，springMVC框架
在ERP类的业务中，采用B/S结构，并在表示层使用MVC的设计模式是早期比较流行的一种方式。其著名的辅佐框架是SSH（Struts，Spring，Hibernate）组合，之后springMVC也比较流行（Struts、springMVC都是对JAVA的Servlet进行的一种封装）。当时的时代背景，各行业都在需求建立自己的业务系统，主要是内部管理资源而使用，从传统的手工作业方式转变为自动化的流程管理，目的是使用IT技术来提高生产力、管理水平。在使用场景中，对服务的响应速度和承载能力、并发等要求不高，系统的主要使用对象为公司内部人员，采用单服务系统应用部署方式和瀑布式的开发模式，能够满足业务需求。
服务器端的代码结构为DAO层、Service层、Controller层、View层
View层：作为展示给用户看的交互界面，一般采用JavaScript＋HTML＋CSS来实现，加上springMVC或Struts对数据的绑定。
Controller层：负责展示层的业务逻辑分发，对model进行数据绑定。
Service层：负责处理具体的业务逻辑。一般再细分为Service接口层和Service实现层。
DAO层：负责对数据库的查询、修改等。
PHP、ASP开发语言
当时的互联网热潮还处在web1.0时代，也就是大家上网看看新闻，逛逛论坛等，以获取信息为主。网络购物等也比较初级，用户也不多，计算机比较贵，上网人数还是有限的。一些网站的主要语言是使用PHP、ASP等将DAO层、Service层、Controller层、View层合在一起，快速开发出小型网站，数据库采用mySQL。很多论坛、购物网站、都是PHP＋mySQL搭建的，素有PHP是最好的语言（在论坛上吼这句话，会有无数程序员开始争吵，楼主要迅速逃离，否则有被“乱棍打死”的危险）
SOA（Service-Oriented Architecture）面向服务的架构设计思想
SOA的场景是多应用系统之间的交互需要应运而生的设计思想。原先单应用系统，一个企业的所有服务都在一个系统上实现，工作流集中在一起，对于早期简单的业务场景可能适用，但随着企业规模扩大、产品的多样化，以及互联网的冲击，这种全部集中在一个系统上的架构显得不合时宜，而将企业工作流或者业务流程分布在各个功能独立化的应用中的做法变得迫切需要，于是面相服务的架构设计SOA被提出。大型企业包括跨国集团、金融机构等。
ESB（Enterprise Service Bus）企业服务总线技术
伴随着多应用系统的出现，应用与应用之间的交互成了问题，几个应用乃至十几个应用之间的复杂交互形成如蜘蛛网一般的交叉连接，通信效率和维护都非常的低下，而ESB将各个应用服务链接在这根总线上进行通信安排和管理来解决上述问题。当SOA设计思想开始广泛应用时，对ESB的依赖越来越多。
架构的转变
随后的IT发展，在互联网化的进程中越发给力。利用互联网的进行各种创新服务，其中传统交易的线上化被广泛使用。随之而来的是使用系统的对象产生了变化，从企业内部人员和少数有钱人，发展成普通大众，且在网上发生的行为越来越多、在线时间越来越长，原本B/S结构的MVC设计模式、单系统服务应用的部署、以及瀑布式的开发模式都无法满足快速增长的业务需求。
于是，将前后端拆分、前端异步加载、后端微服务化，甚至出现云服务，敏捷开发等解决方案成了必然的结果。
RESTful API
为了适应互联网的业务需求，提升用户的浏览体验，前后端拆分部署变成必需。拆分后前端独立加载，不同于MVC的model绑定后台显示数据，三层结构中的表现层独立加载在浏览器之中，使用Ajax等异步加载手段从后台的RESTful 风格的API接口获取数据进行展示。
（代码挪腾开始了，真折腾呀！）
代码结构为 前端H5、后台RESTful API。
前端H5：
JavaScript的各种框架（jQuery，web MVC的AngularJS等）＋HTML5＋CSS，也可以是DDD（领域驱动设计模式）的表现层。
后台RESTful API风格：
JAVA Servlet技术提供的API接口：Action层（负责逻辑分发）、Service层合、DAO层。
DDD（领域驱动设计模式）后三分层：应用层、领域层（Domain）、基础设施层。
Micro-services 微服务
当然，光做前后端拆分还不够，为应对现代互联网的爆炸式增长访问量和敏捷开发的不断快速迭代需要，微服务技术的出现无疑可以很好的解决这个问题。微服务是把传统应用上的多个服务做细微拆分成原子组件，可随时进行多个同样服务的复制和部署，以应对流量压力、业务需要，做到可弹性伸缩。主要包括：服务拆分、服务的注册、服务发现（客户端发现、服务端发现）、进程通信等机制。以及配套的运维体系（Dev-Ops等)、应用容器化（Docker等）、缓存数据库（MongoDB、Memcached、Redis等）。JAVA上的微服务框架有springCloud，其他语言亦有自己的微服务框架。
云计算服务
人云亦云的云计算服务以下简称云服务，将已经成熟的服务开放出去给用户使用、并且每个用户都有其独立的一套环境（虚拟空间），这就是云服务的本质。无论是提供磁盘空间、还是基础环境、甚至是软件应用，主体思想都是每个用户是独立的。云服务的产生原因有很多，基于共享和企业节约成本的目的是主要驱动力，云服务适合初创企业、以及不知是否将要继续的业务。云服务的要点有，基于高度规范化和标准的通用服务，最早的企业网站模版与虚拟空间一体化产品就是现代云服务的早期试验田。
这里微服务和云的关系很微妙，云服务的其中一种实现方式就是开放的微服务化，很多人把云计算服务和微服务划等号，其实云计算服务是商业模式，微服务是技术集合。
架构变迁、顺应时代的需要从而带来开发管理的变化
Agile software development 敏捷开发
敏捷开发相较于传统的瀑布式开发方式，具有快速迭代、最小化可用，丢弃繁琐的各种详设文档，以求最快速度的上线使用，适应现代互联网高速创新的需要。
（但大部分时候开发速度加快，不是敏捷开发带来的，而是没日没夜加班换来的，😓）
敏捷开发可分为两个部分去理解，开放方式的敏捷化以及运维方式的敏捷。
开发方式的敏捷是指，从需求设计、到编写代码的中间流程全部精简，免除企业中整体的复杂流程。
运维方式的敏捷是指，从代码写完到自动集成发布、自动完成测试、到最后的自动部署，自动上线的过程。
用到的工具有，需求管理工具看板：Trello等、版本管理：Git等、自动化集成Jenkins、自动测试脚本等，包依赖管理工具maven等，构建方式Ant、Gradle等。
如何编写语言框架
讲了那么多系统架构的变迁和历史，那么为了适应各种业务需要的架构支持框架是怎么写的呢？
首先要明确你的语言框架是用来干什么的，出于什么目的编写框架。
其次，框架在哪一层，封装些什么内容，封装到何种程度，都是根据你的业务需求来定的。
打个比方：在早期MVC的框架Struts，它的定位就是封装前端与后台的数据交互，封装表示层的复杂实现，所以是基于底层的封装。又如同，利用Struts在其之上做的各种公司内部开发框架等，就是对于某些业务类型特定的开发逻辑进行的封装，这种属于逻辑层的封装。
编写底层框架
底层框架的封装，提供出来可供调用的接口，其整体设计都是基于公共目的，如springCloud处理了微服务技术中各种消息传输、服务注册、发现等的复杂实现，供开发者方便调用，搭建起自己的微服务应用。一般都是底层实现的优化，对于开发者的，算法能力、数据结构、以及编译和模块设计思想要求都较高，常见于非营利性组织，或开源社区的大牛制作发布。这种框架是对业务需求的高度抽象总结后，适应时代发展做出的，会有组织者提出并牵头，有完整的框架自身功能结构的规划。自然也会有众多爱好者为其贡献插件和组建。对于开发者来说，写这一层的框架才是真正锻炼技术和有意义的。
编写逻辑层框架
在逻辑层的封装其应用范围会更加的窄，比如一个集成的开发框架，从生成模版代码到打包都是一体化的，是为某一用途设计的框架封装。JAVA中的框架开发使用其特有的反射机制，在逻辑层封装的比较多，常见于各个公司内部的开发框架，一些大型软件外包公司都有自己的开发框架。因其发展多年，业务条线基本定型，开发模式成熟，故可使用这种方式封装框架供定向开发目的使用，以保证软件开发质量、无论是公司多年的高级工程师、还是刚毕业的新手都能在这种开发框架下写代码不出错。网上有很多这种开发框架不限于JAVA的，还包括JS的封装了jQuery调用和一些业务逻辑的开发框架，由于是在底层上的逻辑层二次封装，其适用面比较窄，业务目的性明确，所以往往被淘汰率很高，特别是现在互联网高速发展的时代，今年的开发框架，明年就不适用了，也没人维护，成了被遗忘的“坑”。
编程语言（需要的技能：编译技术、数据结构的设计、虚拟机或硬件平台的知识）
｜
底层框架（需要的技能：算法功底、功能的实现方式、整体的规划能力）
｜
逻辑层框架（需要的技能：熟练使用底层框架、开发中公共代码的积累）
