微服务：系统架构的演变

通过这篇文章我们来学习我们项目系统架构的演变过程。没部署过项目的或者没做过项目的小伙伴也可以康康，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	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队