一、概念
1.1系统架构的演变
1.1.1 单体项目
Web应用程序发展的早期,大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

优点:
所有的功能集成在一个项目工程中
项目架构简单,前期开发成本低,周期短,小型项目的首选。
缺点:
全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。
系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。
技术栈受限。
1.1.2垂直拆分
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率
从功能结构来拆,谁访问的多谁加集群
缺点:垂直拆分,独立项目之间不能互相调用,比如要用一些公共的功能,只能每个都写一份。

优点 :
项目架构简单,前期开发成本低,周期短,小型项目的首选。
通过垂直拆分,原来的单体项目不至于无限扩大
不同的项目可采用不同的技术。
缺点 :
对于大型项目不易开发、扩展及维护。
系统间相互独立,重复开发工作(独立项目之间不能互相调用,比如要用一些公共的功能,只能每个都写一份)。
1.1.3 分布式服务
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式调用是关键。
不同独立的项目,之间可以互相调用

优点:
将基础服务进行了抽取,系统间相互调用,提高了代码的复用和开发的效率
缺点:
系统间的耦合度提高,关系复杂,难以维护
1.1.4 分布式SOA架构
SOA 全称为 Service-Oriented Architecture ,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。
Dubbo
阿里框架,后来停止更新,当当网继续更新DubboX
后来阿里又继续维护了,把它挂到阿帕奇官网了
优点 :
抽取公共的功能为服务,提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO减少系统耦合
缺点 :
抽取服务的粒度较大
服务提供方与调用方接口耦合度较高
tips:现在springboot也支持整合Dubbo了
1.1.5 微服务架构
优点 :
通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也将大幅度