springboot01_微服务架构的现状及未来【上】

4.1.1.微服务架构的现状及未来【上】

时长：54min

内容概述：

1.什么是微服务

2.微服务与soa

3.springcloud是什么

4.springCloud生态

5.service Mesh

1.1.什么是微服务

1.1.1.架构演进过程

1.1.1.1.单体架构

　　

早期，任何一个网站，都是从单体架构发展而来的。因为早期，不会有庞大的用户量，及数据体量。也不会有较为复杂的业务结构。

当然，现在，很多创业型公司，可能都是直接使用springCloud进行微服务设计。

 

所谓单体架构，就是整个项目，打一个war包布署到一台tomcat服务器上。当然，数据库会单独安装在一台服务器上。

开发可以使用ssm,或ssh框架。开发人员【可以使用两人组，一前端，一后端】

随着产品上线。可能会遇到很多的问题，如：用户量增加，服务器的性能是否能跟上？系统业务复杂度增加以后，后端系统架构业务的耦合性是否越来越强?

数据量增加以后，数据库是否能够支撑数据的查询，和数据导入。。。

如下图所示：

 

 

 因此，使用考虑服务器集群布署来进行优化。

1.1.1.2.集群布署

 

 

何谓集群布署？

当用户大量增加，必然就会出现同一时刻，多个用户同时访问一个接口。即同一时刻，发送大量请求。

而服务器的作用，就是接收用户请求，处理数据，并返回数据。当请求大量增加以后，就相当于一个人要干活变多了，处理速度就慢了。那怎么办呢？

只好找一个同伴来帮忙，因此，增加一台服务器【甚至是多台服务器】

 

然后，多台服务器进行分工，一起来处理这些用户请求。

那么，大家的工作压力都减轻了，干活的效率就提高了。

 

集群布署，是一种水平伸缩方式。能够提升服务端处理性能，提升并发性能。

　　除了提升并发处理性能之外，还可以保证高可用性【一台服务器挂掉后，可以用另一台顶上】。

但是，随着用户的大量增加，不同的用户需求不同，产品功能就会增加更多。产品业务逻辑就会越加复杂。

       如果所有业务都放在一个容器，必然会带来一个问题，系统的耦合性越来越大。业务的体量也会变大。

耦合性增加，带来的问题是，当进行一个需求变更修改代码时，就会导致相关代码也需要大量修改。

给开发工作带来很大工作量和难度。

　　因此，需要进行业务解耦。即根据业务进行拆分系统。

1.1.1.3.垂直化架构【集群】

 

 所谓垂直架构，就是根据业务进行系统拆分，不同的业务布署在不同服务器上。

 

举例来说，对于一个电商系统，常涉及到订单系统，用户系统，商品系统。

打开淘宝的网站，我们会发现，针对不同的业务系统，会对应一个子域名。

同样，针对不同业务，会布署不同的数据库，以达到业务隔离的效果。

垂直架构，主要作用是降低业务耦合度。

由于业务拆分，不同的业务，对应独立的数据库，带来的问题是，当不同系统之间存在服务调用时，就可能出现很多冗余代码。

如：用户要查询用户的订单信息，用户系统就需要查询订单库。这种跨系统调用，就会导致很多重复代码。

       当底层数据库服务发生变化时，上层依赖它的服务就需要相应修改。如：只是修改了订单库的底层服务，但是用户系统和订单系统，及其它依赖订单库的系统都需要修改。

       所以，这里还是存在紧密的耦合性。基于这个问题，引入了服务化【SOA】的概念。

1.1.1.4.服务化【soa】

所谓服务化架构，也称面向服务编程。

       它是用于解决系统的共享业务问题。即解决不同系统间代码冗余问题，解决方案是在各业务系统与数据库服务之间，引入中间服务层。

       服务层，以一种特定的规范来处理。这里会提供的服务接口，这些接口需要满足某种协议，如：rpc协议。

       引入中间服务层之后，也就有了共享服务。然后不同系统就可以以远程通信的方式，调用共享服务。

       服务化，主要解决业务重用，和数据互联互通。

 

       Soa到微服务，会发生什么变化呢？

       实际上变化并不大，微服务是基于soa,更为细粒化服务的演进。它的核心，是降低业务的耦合性。

1.1.1.5.微服务化

所谓微服务，是在服务化的基础下，对服务更为细粒度的拆分。

如：用户服务，拆分为用户基本服务，用户帐户服务，用户积分服务。。。

 

进行微服务化之后，系统被拆分成很多个的子系统，并且独立布署。

对服务器布署，在原来虚拟化技术的基础下，提出容器化布署。

1.soa与微服务的区别

1.微服务，是对soa一种思想升华，和技术提炼。

2.微服务的主要目的是解耦，而soa的主要目的是服务重用。

3.微服务关注服务粒度，soa关注服务复用。

4.微服务会使用轻量级的通信协议，如：restful,可以很好支持跨语言，会使得服务生态更加完善。

5.微服务，由于服务的大量拆分，更加依赖于服务运维技术。如：docker+k8s容器化技术。

2.微服务架构下的业务需求

微服务架构下存在哪些需求呢？如下图示：

举例说明：

　　比如，用户服务，调用订单服务，查询数据。这是一种跨系统，跨服务器通信，也就是一种远程通信。

　　远程通信有很多协议，如：rpc通信，涉及中间件，如：restful,dubbo,jsf【京东】，hsf【阿里】，蚂蚁金服【Sofa】

　　这里简要说明下远程通信基础。

　

下面引出第一个需求，eureka-server注册中心，服务注册中心是什么呢？

【1】服务注册中心

　　以用户服务，调用订单服务为例。说明远程通信与服务注册中心的关联。

　　服务调用过程，必然涉及rpc远程通信，而服务必然会做集群【防止单点故障，达到高可用】，即会涉及到多个服务。

 

　　假设订单服务，布署3个节点【相当于3台服务器】，一旦涉及到多台服务器，必须需要用到负载均衡器，来分发请求。

需要一个前提是，服务调用者，需要知道服务提供者在什么地方【提供者的地址】

　　因此，需要对地址进行维护，可以考虑在配置文件中写死，http://ip:port/url...,但是，如果服务提供者的地址发生变化，就

需要修改配置。这种方式明显是有缺陷的，主要问题有：

　　》无法做到服务动态感知。

　　所谓动态感知，比如说，订单服务布署3个节点，其中一个节点挂掉之后，服务调用者不知道提供者的节点，是否有挂掉。

在不知道的情况下，服务调用者【消费者】，每次请求发过去，都会失败。

　　》配置文件中硬编码式配置，维护困难。

　　因为微服务中会有大量的服务，每个服务会涉及到多个节点，针对这些服务，把服务地址写在配置文件中，会有很大的工作量，不利于维护。

　　所以，需要思考一种高效管理服务地址的方案。因此，才引入服务注册中心。

　　

　　服务注册中心，需要满足基础的两点：服务动态感知，服务地址高效管理。

有了服务注册中心，就可以把服务注册，到注册中心。服务注册中心，相当于电话通讯录【联系人名单】，服务就相当于联系人，根据名称就很轻松地找到

具体的联系人【具体服务】。

　　服务消费者，如何拿到服务呢?直接从注册中心获取。

 

　　注册中心的实现组件，包括Nacos,consul,eureka,zookeeper,redis

 

注意：微服务与分布式架构

　　微服务是属于分布式架构，微服务强调服务架构的一个特征，分布式是整个架构的一个特点，是架构层面的概念。

【2】负载均衡器

　　配置在客户端，组件，如：ribbon，涉及到负载均衡算法---轮询，随机，平均数。。。

4.1.2.微服务架构的现状及未来【下】

时长：1h10min

【3】配置中心

　　为什么要有一个配置中心呢？主要是为了放置一些公共的配置文件。

　　如：数据库连接，内部常量配置，开关配置，线程池大小。

 

　　单独布署一个配置中心，能够很方便地找到配置数据，也可以直接对配置进行修改。

　　如果在项目中进行配置，修改配置文件，需要进行重新布署，此外，安全性也是个问题。

再有，如果服务布署10个节点，需要对10个节点的配置进行修改，就需要对10个节点，重新布署。

造成运维困难。因此，引入配置中心组件。

 

　　有了配置中心以后，在服务启动之前，会先从配置中心加载配置数据，缓存到本地。一般配置中心，会有

一个统一的维护入口，如：Dashboard,配置人员可以在客户端访问这个配置页面。当然，配置中心，一般会对

访问人员进行权限校验，如果具备相关权限，就可以对配置数据进行crud.

　　当配置中心配置数据，有更新后，会主动推送，告诉相关的服务，这个配置变化了。然后应用就可以基于新的

配置进行处理，从而实现动态地配置管理，而不需要重启服务。

　　动态配置数据，如：阀值配置，开关配置，第三方服务【密钥，key...】

　　配置中心开源组件，apollo【携程】/Nacos/disconf/zookeeper/diamend/spring cloud config

【4】网关

　　客户端，一个请求发起之后，会先经过网关，然后由网关进行路由。

　　为什么需要网关呢？

　　服务调用涉及到一个安全性问题，服务调用中，针对每一个节点，会进行一个授权判断。怎么知道请求用户是

谁？

　　此外，服务每次调用，可能需要做监控，限流处理。当然可以放到服务层去处理，但是，最好是对这些处理进行抽离，放

到网关层，做统一授权，日志记录，权限认证，限流，熔断处理。

　　网关，简单来说，就是请求路由。网关要实现这些功能，就需要对请求进行过滤，拦截。

 

　　同样，为了满足高可用，网关也需要进行集群，布署多个节点，所以， 网关之前也需要nginx做反向代理。

 

　　网关，实现开源组件，spring cloud gateway/spring cloud zuul

　　

　　整个系统，进行分布式设计，微服务拆分，大大降低系统耦合度，提高了性能。但是，还是存在问题:

>可用性【不可能100%可用】

》性能不能所有的用户需求

　　后端系统服务吞吐量是可以测试出来的，通过压测，链路跟踪，系统监控。

压测，一般是针对核心服务。整个系统来说，它的吞吐量是有限的，当用户量非常大的情况下，如何保证系统不会垮掉？

通常会做一些处理：

　　限流：为了保护系统不被大量请求冲击垮掉。限流算法【令牌桶，滑动窗口，漏桶，guava ratelimiter】，sentinel【阿里】,hystrix【spring】

　　　　通常是对流量阀值进行判断。hystrix可以针对方法，服务做降级，做熔断。

　　熔断：

　　降级：保证核心服务可用。

　　　　分为主动降级，被动降级。

　　缓存：

【5】负载均衡器

　　开源组件，keepalived/Nginx/openRestry/Kong/Orange/tyk

【6】spring Cloud Bus异步化总线通信

　　系统涉及到异步化通信时，可以基于spring Cloud Bus通信。引入第三方通信组件，如：Kafka/RocketMQ.

【7】链路监控

　　整个系统，还有一个很重要的部分，就是系统监控。

　　传统的方式，是通过日志监控。如：当出现一个bug时，通常是登录到服务器，查看日志，然后定位问题。

　　然而，在微服务架构下，一个系统存在非常多的节点，一个请求可能经过多个节点。如：我需要定位一个请求，

从发起请求，到返回结果整个过程，耗时10秒，怎么去定位这个耗时，主要是发生在什么地方？

　　spring cloud提供一个链路监控，sleuth + zipkin.监控原理是：

　　每一个请求进来以后，会生成一个tranceId【整个链路唯一】,spanId【每一个节点中每一个请求中是唯一的】

　　链路监控，开源组件有：sleuth +zipkin/pinpoint/skywalking/cat/jaeger.

　　

　　系统监控，还可以通过dashboard大盘展示，让运维人员和开发人员查看。

1.2.spring Cloud生态

springCloud是什么？

       在微服务架构下，存在很多问题。针对这些问题，和相应场景，都需要提供一定的解决方案。

       在没有spring Cloud之前，spring生态可以整合市场上的一些开源组件，来提供解决方案。需要开发人员自己进行整合，整合过程会存在，版本兼容和其他一些问题。

       Spring很会体谅我们开发人员，它为我们提供了一套整合方案，这就是spring cloud生态。它提供了快速构建微服务的多种技术组件。

 

服务注册：eureka

1.2.1.spring Cloud版本命名

 

 为什么要这么为版本命名呢？

　　使用A,B。。。H,这种大版本命名。因为spring cloud生态下各种组件依赖版本各不相同。而在大版本下会有各种组件的小版本整合。

　　spring cloud版本，与springboot版本有很大的关联性。