微服务架构详解 _架构

一、微服务架构的由来
在微服务架构出现之前，最常用的架构就是单体架构，俗称"一个jar(war)包打天下" 。在一个jar包工程中，采用MVC架构，分为表现层，业务层，数据访问层，所有的业务模块，都放在这个工程中集成，如下图所示:

文章插图

随着软件行业规模的增长，这种单体架构的弊端也越来越多，包括:

耦合性高，某个地方出问题，很可能影响其他业务模块的使用
代码管理成本高，项目沉重，并会随着需求的增加越来越重
随着访问量的增多，这种架构的工程并发力不够

为了解决单体结构带来的问题，就出现了微服务架构。
微服务架构就是将单一程序拆分成一个一个的微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL
API 。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
二、微服务架构优势与劣势
优势：
复杂的业务拆分成多个业务，每个业务是一个独立的微服务，彻底地去耦合，利于分工，当需要增加业务的时候，可以方便创建新的微服务扩展业务，而不用担心有没有别的地方耦合
每个微服务都是独立部署的，如果其中一个宕机了，不会影响整个系统；也方便功能变更时，服务的部署；当流量增大后，可以将服务集群化部署，增强抗击高并发的能力
每个微服务之间可以使用不同的编程语言和不同的数据库
劣势:
在复杂程度上来说，微服务比单体建构要更为复杂些
部署比单体项目复杂
服务之间是用HTTP协议通信的，通信成本比单体项目高
数据一致性问题。
三、适用场景
通过上面的描述可以看出，微服务在解决了单体架构带来的问题的同时，也出现了部署复杂，需要增加中间件联络各服务的问题。所以，不是所有的场景都推荐使用微服务架构，具体如下:
适用场景:
①:大型复杂的项目…(来自单体架构200W行代码的恐惧)
②:快速迭代的项目…(来自一天一版的恐惧)
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)
不适场景:
①：业务稳定，就是修修bug ，改改数据
②：迭代周期长发版频率一二个月一次.
四、微服务与SpringCloud的关系
SpringCloud简单来说是上述微服务架构技术落地实现的集合体，是微服务架构下的一站式解决方案。
SpringCloud是一个技术的集合体，将上述的微服务架构进行落地。下面看一下这个集合体里包含哪些组件：
注册中心Eureka:
拆分成多个服务之后，总得有个管理多个服务的模块吧，这就是注册中心的作用。起到服务注册和服务发现的作用。
网关Zuul:
拆分成多个服务之后，涉及到服务之间的调用吧，一个服务调用了三个服务的模块，那在这个服务里，配置三个调用地址，看起来是不是很麻烦呀，所以就出现了网关，所有的服务调用都调用到网关，然后在网关里配置路由，进行服务的转发，类似于代理的作用。当然网关需要配合注册中心进行使用，去发现转发到哪个服务上去。
负载均衡Ribbon:
网关找到请求发送到哪个服务后，如果这个服务做了集群，有多个实例，那该发送到哪个实例上呢，于是就出现了Ribbon组件，进行负载均衡。
远程调用方式Feign:
服务之间相互调用的时候，可以使用RestTemplate进行调用，SpringCloud也提供了Feign客户端访问，即提供了一种远程调用方式。
断路器Hystrix:
SpringCloud提供了一个监控组件，用于监控服务接口的状态和断路情况。Hystrix Dashboard是个监控面板，提供了可视化界面查看服务调用的耗时等等。
上述就是微服务的五大组件。微服务架构就是对服务进行拆分，多个小的项目，组成一个大型项目。那么，拆分后的服务，肯定需要增加中间件，来统一维护这些服务，于是就有了注册中心。拆分成小型服务后，涉及到服务之间接口的调用，于是产生了Feign技术。为了实现高可用，每个小型服务都需要集群，那么集群如何选举呢？就出现了负载均衡技术Ribbon 。最后通过网关统一管理请求路径的配置，进行请求的转发。SpringCloud还为我们提供了断路器，用于监控服务的各种指标信息。