通过这篇文章我们来学习我们项目系统架构的演变过程。没部署过项目的或者没做过项目的小伙伴也可以康康，hhhh..
当我们系统的用户逐渐增多，我们系统就必须具备了高可用、高并发这样的特性。如何解决？
1、单体应用架构这种应用架构就是我们在校园中做项目（例如一个网站、一个小程序等）经常用的架构，说白了，学校也不可能给你几台服务器让你玩分布式，第一是有这种需求也不会交给学生做，第二是学校的系统一般的并发量还没达到这个级别。我个人现在大三，在学校做过大大小小很多系统，到最后说白了就是反复做同一个事，也没啥难的（吹个牛B）。
优点：（1）所有的功能集成在一个项目工程中（2）项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：（1）全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护（2）系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。 （3）技术栈受限（4）容错不好，如果其中一个模块出现问题，可能导致整个项目崩掉。
单体应用架构
2、垂直应用架构当访问量增加，我们就得想一下如何解决问题。将应用拆成互不相干的几个应用，以提升效率
这里将三个模块系统，部署到三台服务器上，这样各自应用不会互相干扰，形成分流。三个系统是毫无关系的，但是这样我们就需要写一些重复的开发代码了，比如后台管理系统要看到电商系统的数据，那么必然调用电商系统的数据内容。这个架构并没有根本上解决高并发的问题。只是将原来的项目，一刀切为3份而已。
优点：（1）项目架构简单，前期开发成本低，周期短，小型项目的首选。（2）通过垂直拆分，原来的单体项目不至于无限扩大（3）不同的项目可采用不同的技术。
缺点：（1）全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。（2）系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
3、分布式SOA架构 SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合。 相信你看的一脸懵比，木事，直接上图！ 我们将这三个系统，拆分成了很多个服务，整个系统分为展示层（消费者）、服务层（提供者）以及esb或者dubbo。这样将一个服务单独部署在一个服务器或者集群，然后通过注册中心，消费者调用提供者，展示层通常就是我们说的controller层，服务层就是service。关于dubbo实现这样一个架构可以参考：https://blog.csdn.net/weixin_44588495/article/details/104855903 还有我自己模拟写了一个rpc：https://blog.csdn.net/weixin_44588495/article/details/105279242 有人可能说这个跟上面的有啥区别，单独的提供者之间不是相互独立的，是可以相互调用的。而且服务是可以多点提供的，可以提供给不同的消费者。 优点：（1） 抽取公共的功能为服务 , 提高开发效率 （2） 对不同的服务进行集群化部署解决系统压力 （3） 基于 ESB/DUBBO 减少系统耦合 缺点：（1）抽取服务的粒度较大（2）服务提供方与调用方接口耦合度较高（3）分布式事务等问题 4、微服务架构 微服务实际上就是将服务再细划分为更小粒度的服务。职责更加明确。而且为前端调用提供接口，供http调用。 优点：（1） 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成 本也将大幅度下（2）微服务遵循单一原则。微服务之间采用 Restful 等轻量协议传输。 缺点：（1） 微服务过多，服务治理成本高，不利于系统维护。 （2） 分布式系统开发的技术成本高（容错、分布式事务等）。 5、soa和微服务的关系
SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服 务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程 中。各个服务之间 通过网络调用。
微服务架构 : 其实和 SOA 架构类似 , 微服务是在 SOA 上做的升华，微服务架构强调的一个重点是 “ 业务需 要彻底的组件化和服务化” ，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。| 功能 | SOA | 微服务 |
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
