单体框架、分布式框架、微服务框架
1.单体框架
1.概念
将业务功能集中在一个项目中开发，打包部署。(意思就是说，所有的功能在一个项目中进行实现，不用管复杂的架构设计，只需要创建一个项目，有功能就往这个项目里面加代码就ok了)
2.优点
1、框架简单，不需要搞复杂的框架设计
2、部署成本低：把写好的项目打成包，在tomcat服务器上面部署一下，用户就可以访问了，如果用户访问多了，那就在加两个服务器，形成负载均衡的集群。
3.缺点 1、耦合度高：在大型项目的开发中，像拼多多，淘宝这些，一个大型项目里面有很多的功能模块，代码量十几万行甚至于几十万行代码，如果使用单体架构，有以下几个缺点： 一：打包部署就需要很久，效率低 二：项目中的功能模块的代码你中有我，我中有你，假设其中一个模块中出现问题，其他模块也会受到影响，代码的边缘化也越来越模糊。所以在大型项目中基本上都是采用分布式架构。
2.分布式框架
1.概念 根据业务功能对于系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务
2.优点
1、降低耦合度：每个功能模块，都成为了单独的项目，大家各写各的项目，没有过多的牵扯耦合度就会大大的降低，两外像打包速度，代码量都会减少。
2、有利于服务升级和拓展：像以后功能模块项目/服务进行升级维护也影响不了别的功能模块项目的正常进行。
3.缺点
1、服务调用关系错综复杂：一个大型的项目被拆分许多的服务，各个服务的功能模块该如何调用？许多的服务部署起来也是比较麻烦。
出现的问题： 分布式虽然降低了服务耦合度，但是服务拆分时也有很多问题需要思考：
1、服务拆分的粒度如何界定？（就是说一个大型项目被拆分为许多的服务，该如何拆分哪几个服务作为单独的模块，那些业务不需要拆分，这个拆分的粒度需要把握）
2、服务集群地址如何维护？（就像下面一个支付功能的服务，就部署了两台机器，如果是个大型项目需要部署上百台的，这些服务集群的地址该如何的维护和调用，总不能把地址写死吧！如果部署上线地址变了怎么办，维护起来很麻烦）
3、服务之间如何实现远程调用（各个服务之间该如何进行远程调用呢？）？
4、服务健康状态如何感知？（加入用户功能这个服务调用商品功能这个服务，刚好这个商品服务出问题了挂了，这边一调用也导致用户功能服务也出问题了，这样就造成了级联失败） 为了解决这些问题，人们需要制定一套行之有效的标准来约束分布式架构。出现了各种各样的技术（如下图）去解决这些问题：但是近几年运用最广泛的最火的莫过于微服务了
3.微服务
1.概念
微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征（微服务它还是一种分布式架构，只不过人们在设计分布式过程中踩坑，不断的总结经验，得到了良好的分布式架构实践方案）： 1、单一职责：微服务拆分粒度更小，每个服务都对应唯一的业务能力，做到单一职责(什么是单一职责我举个例子加入一个商城项目里面有用户模块，用户里面又有会员模块，积分模块什么的，把每个模块都拆分为一个服务，这就是拆分的力度更小，一个服务就对应一个一个业务功能，一对一的效果)
2、面向服务：服务提供统一标准的接口，与语言和技术无关(这个服务该如何调用，肯定不能像单体架构中直接调用，这就需要这个服务提供这个功能的接口，这样别的服务就可以远程调用你这个服务中的接口从而实现想要实现的功能)
3、自治： 1，团队独立（就是交给你们五个人或者八个人做这个服务，你们分工有前端，运维，后端，测试，什么的，非常高效的把该服务开发出来，以后技术升级或者服务升级直接找到你们这个团体着手去做，很高效方便） 2，技术独立（因为服务与服务之间互不影响，你们这个团队的服务可以自己选择自己想用的技术或者适合本次业务的技术，术业有专攻嘛） 3，数据独立（每个服务有单独的数据库），独立部署（用户可以根据自己的需求去访问自己想要的服务）和交付
4.隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题（这个就是服务调用过程中做了隔离，调用你这个服务发现你挂了，但是我不能挂做出一定的容错性，避免出现级联问题） 微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。 因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。
4.总结
总结 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝 微服务：一种良好的分布式架构方案 ①优点：拆分粒度更小、服务更独立、耦合度更低 ②缺点：架构非常复杂，运维、监控、部署难度提高 SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件 ````