微服务的演变史（单体式、分布式、SOA架构、微服务架构）

单体式架构

从架构层面来考虑:一个应用只部署一个服务,或该应用由多个服务组成的时候,只部署在一台服务器上

把一种系统的所有功能全部耦合在一个应用中的框架方式

这种开发方式简单,但是只适合体量较小的业务,一旦业务体量增加到一定程度的时候,单机的硬件资源将没办法满足我们的需求

 

分布式架构

从架构层面来考虑:一个应用的多个服务分别部署在不同的服务器,这种形式都可以称之为分布式;

将一个完整的系统按照功能点拆分成若干个相互独立的子系统,每一个子系统可以称之为一个节点,每一个节点都可以单独配置多台服务器(集群),各个子系统之间相互进行通信,进行协调合作,共同完成整个系统的业务流程

简单的讲： 大任务划分为小任务。一个或多个人（或机器）完成同一任务中的不同部分。被分解后的小任务互相之间有独立性，节点之间只管接受和传递信息。

由于每个服务都是单点部署,因此可能会出现单点故障问题

 

集群部署

是分布式架构中的一种解决方案,主要用于解决应用单点故障问题,以及提升应用的并发能力;

在分布式中,每个节点都是完成不同的业务,那么如果一个节点跨了,那这个业务就不可以访问了;

我们把每个单机多复制几遍就构成了一个集群,而这个集群中的每台服务器就是集群中的节点,并且该集群的每个节点服务器都有单独处理该业务的能力,靠负载均衡器来判断当前所有节点的负载情况来决定该请求交给哪个节点处理;

如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行该任务需10小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Reduce分布式计算模型）

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，1小时后，10个任务同时完成，这样，整身来看，还是1小时内完成一个任务！

 

SOA架构（面向服务）

特点:主要是为了抽取公共服务,减少代码的重复,提升拓展性以及可用性

在分布式的架构下,当服务越来越多,容量的评估和小服务资源的浪费等问题就会出现,这个时候需要添加一个调度中心(企业消息总线),对集群进行实时管理,但是服务之间会有依赖关系,一旦某个环节出错有可能会造成服务雪崩

 

微服务架构

在某种程度上是面向服务的SOA架构的继续发展的下一步,微服务架构更加强调服务的"彻底拆分"

将一个大型系统的各个不同模块按照需求拆分成一个一个的服务,各自独立运行

单个轻量级服务一般为一个单独微服务,微服务讲究的是专注某个功能的实现,比如登录系统只专注于用户登录方面功能的实现,讲究的职责单一,开箱即用,可以独立运行,微服务架构系统本身是一个分布式的系统,按照业务划分服务单元模块,解决单个系统的不足,满足越来越复杂的业务需求,具体就是使用Springboot开发的一个小模块,处理单一的业务逻辑,一个模块只做一个事情  

微服务架构的优点

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

• 微服务之间采用RESTful等轻量级Http协议相互调用

微服务架构的缺点

分布式系统开发的技术成本高（容错、分布式事务等）

微服务架构的拆分原则

1.基于业务逻辑

将系统中的业务安札奥职责范围进行识别，职责相同的划分为一个单独的服务。

2.基于稳定性

将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块；将不稳定的，经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务就可以归到一起。

3.基于可靠性

同样，将系统中的业务模块按照可靠性进行排序、对可靠性要求比较高的核心模块归在一起、对可靠性要求不高的非核心模块归在一起。

这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端，同时将来要做高可用方案也能很好的节约机器或带宽的成本。

4.基于高性能

同上，将系统中的业务模块按照对性能的要求进行优先级排序，把对性能要求比较高的模块独立成一个服务，对性能要求不高的放在一起，比如全文搜索、商品查询和分类、秒杀这种就属于高性能的核心模块。