理解微服务SpringCloud

 

目录

1、服务架构的发展

1.1、单体SSH架构

1.2、SSI和SSM

1.3、业务的垂直化拆分

1.4、SOA服务化的改造

1.5、微服务 

2、SpringCloud生态

3、SpringCloud的实现

3.1、版本管理

4、分布式工具组件简介

4.1、网关

4.2、服务注册与发现

4.3、负载均衡

4.4、降级限流

4.5、配置中心

4.6、消息通信

5、SeviceMesh

6、小结

前言

    微服务是互联网发展的必经之路，它是安姆达尔定律取代摩尔定律的最佳体现，单靠提高单台服务器的性能已经不能解决问题了，只能依靠并发，集群来解决。

1、服务架构的发展

    一般情况下，一个网站在发布初期不可能立即拥有庞大的用户量和海量数据(但是也有例外，本来流量入口就很大)， 对于一个刚起步的项目，我们会选择最简单快速的方式来实现，快速 原型模型和 演进模型，都是在不停的试错过程中一步一步演变其自身的架构来满足自身的业务的需求。

1.1、单体SSH架构

实现方案：  Spirng + Struts + Hibernate.

例如之前的方案就是把所有的功能模块打包在一个Jar或War包中，并且部署在一个web容器下，比如tomcat／weblogic／jboss中运行，例如使用SSH的架构方案；

1.2、SSI和SSM

实现方案：Spring + Spring MVC + ibaties/Mybaties.

当然，Spring也会对一下市面上做的不好的技术进行 替换，比如Struts，因为Struts的笨重和缺陷，所以Spring MVC很快就代替了Struts, ibaties代替了Hibernate，最后升级ibaties成为现在的Mybaties，成为现在的主流框架。

安姆达尔定律代替摩尔定律

    由于业务的互联网用户的极速膨胀，流量开始增加，服务的性能开始遇到瓶颈，这时候就必须对服务的架构进行调整和优化，这个阶段主要解决的就是 提升系统的并行处理能力，降低单机系统负载，以便支撑更多的用户访问。单靠提高单台服务器的性能已经不能解决问题了，只能依靠并发，这里 集群就是一种很好的处理方式；

    集群可以把多台独立的服务器通过网络连接进行组合，对外形成一个整体提供服务。当一台服务器的处理能力接近或者已经超出其容量的时候，我们不去换一个性能更高的机器，这样的投入产出比太低（摩尔定律已过时），我们根据安姆达尔定律采用集群技术，通过增加新的服务器来分散并发访问流量，只要业务系统能够支持服务器的横向扩容，那么从理论上来说就无惧任何挑战，从而实现可伸缩型和高可用架构。

1.3、业务的垂直化拆分

    虽然通过集群可以提升并行处理能力以及对于高可用的实现，但是同时还需要考虑到业务的复杂度，如果仍然把所有的业务逻辑全部耦合在一起放在一个war包中来管理，那对于代码的维护和扩展来说是十分困难的。而且某个业务功能出现故障，会导致整个系统的不可用，所以这个阶段要做的就是降低业务的耦合度，提升系统的容错性。由于：

• 业务的复杂度；
• 用户量增大；
• 服务接口调用量增加；

    这个时候，我们需要对业务进行 垂直拆分，简单的来说，就是按照系统的业务功能拆分出多个业务模块，比如支付业务，会拆除：用户-订单-营销等子系统，每个子系统由不同的业务团队来负责，每个业务模块独立部署。

1.4、SOA服务化的改造

    随着对业务进行垂直化改造之后，以业务功能拆分出多个子系统，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，使系统不断进化，适合自身的业务发展。而在各个子系统中，会存在比较多的 共享业务，比如用户信息查询，在支付业务和营销服务都会用到，那么势必会造成重复开发产生非常多的冗余代码，那么这个时候就引入了服务化的改造思想， 也就是SOA( Service-Oriented Architecture ) 。

SOA主要解决 的问题：

• 1、信息孤岛；
• 2、互联互通；
• 3、服务重用；

把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务，这些被拆分出来的共享服务相对来说比较独立，并且可重用。比如 用户管理服务。

 

SOA 面向服务架构，从语义上来说，它和面向过程／面向对象／面向组件一样，是一种服务的开发方式，是一种抽象。

所以在SOA中， 服务是最核心的抽象手段，业务被划分为一系列粗粒度的业务服务和业务流程。这样的好处是服务的调用和服务的提供者之间是高度解耦的，从而使得服务有更高的灵活性及隔离型。

1.5、微服务 

实现方案： SpringCloud、 SpringBoot  + Thrift 或者  SpringBoot + Dubbo.

垂直拆分，单体服务越来越多，为了快速的构建我们的服务，避免各种不同的服务脚手架，我们开始寻找一种更加高效的方式来搭建，这时候我们开始选择微服务框架来快速构建服务。 微服务并不是一种新技术，而是一种新的思维模式，例如 编程思维的一路变化：

• 面向过程；
• 面向对象；
• 面向方法 AOP，面向组件，开始关注的服务重用性；
• 面向服务：SOA ,进行领域的划分，关注的是解耦，粒度，重用，服务间信息的共享；

这是一种服务化思想的精炼，当底层的基础服务日渐完善和高效，一步步走来，根据发展和需要进而对系统设计的高层次抽象，使开发者更好的专注于业务而不是技术实现本身。

思考 ：集群、分布式还有微服务的区别与联系

集群：     核心在冗余。追求AP，横向扩展一个系统，增加机器的数量，提高并发处理能力。通过冗余来提高系统的可用性，提升系统的容量；

分布式： 核心在分治。纵向扩展，将 一个系统拆分为多个子系统，通过拆分后的分工合作，可以提高关键节点系统的吞吐量-响应-容错能力，也提高了核心链路可用性；

微服务： 不是新技术，是一种架构方法， 纵向拆分，从controller-service-db都拆出来了，按业务分割，注重业务领域的划分，关注服务粒度和复用性。微服务可以帮助程序员更好的理解业务，更专注于业务的价值；

2、SpringCloud生态

    现在，微服务相关的技术生态及社区已经很成熟了，提到微服务技术体系，大家第一个想到的应该是Spring Cloud。

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems 
(e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus,
 one-time tokens, global locks, leadership election, distributed sessions, cluster state).

官方解释：Spring-Cloud提供了一些可以让开发者快速构建分布式应用的工具。例如：

• 1、配置中心；
• 2、服务的发现与注册；
• 3、网关智能路由；
• 4、负载均衡；
• 5、全局锁；
• 6、master选举和集群状态；
• 7、分布式消息传递等等；

    所以Spring-Cloud提供了一系列解决此类问题的工具，这些功能服务可以很好的工作在任何分布式环境中。另外对于微服务难点不是技术开发本身，而是怎样有效的做服务治理。比如做业务域的划分，大量微服务的治理管理，如何做到一键部署等等。

    SpringCloud的生态是基于SpringBoot 个框架来构建的，我们可以发现Spring Cloud并没有实现服务的注册与发现，熔断，配置中心等功能， 它只是提供了一个标准规范， 在这个标准下基于SpringBoot框架做的一个分布式应用工具的整合，快速搭建一个分布式微服务。

    而SpringBoot也不是一个新的技术，它是基于spring框架下对于“ 约定优于配置（ Convention Over Configuration ）”理念下的产物，如果对spring框架比较熟悉，那么在学习springboot的时候会更加容易，主要是基于spring框架，帮助开发人员更容易更快速的创建独立运行和产品级别的应用。

     所以Spring Cloud的基础还是Spring，它的底层依赖依然是面向对象，AOP-IOC-DI等功能的实现。其实常用的一些组件，像ORM框架，缓存，MVC框架，Spring只是提供了一种兼容和支持，和Spring基本没什么关系，这些组件并不是Spring提供的，但是Spring却很好的兼容了这些性能优秀的第三方中间件，这也是spring的强大之处，很少重复造轮子，而是她们利用别人造好的轮子进行封装，使用户使用起来更加方便，因此称为 “万能胶”。而kafka，rabbitmq，zookeeper，redis等也是一些独立的中间件，处于操作系统之上应用之下，SpringCloud以以一种规范很好的把它们组合起来快速实现服务生产， 可以看出SpringCloud的出现也是互联网一步步发展的结果，并不是一个全 新技术，更不是一个 天马行空的产物。当有了这个规范，我们就可以根据它快速搭建我们的微服务，快速实现产品功能上线。

3、SpringCloud的实现

    有了Spring cloud标准规范，围绕Springboot构建的Spring-cloud生态下，目前有两类实现：

一个是基于 Netflix ：

• Ribbon： 客户端负载均衡，特性有区域亲和、重试机制； 
• Hystrix：客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离；
• Feign：  声明式服务调用，封装了Ribbon，底层是对RestTemplate和httpclient的封装；
• Eureka：服务注册中心，特性有失效剔除、服务保护；
• Dashboard：Hystrix 仪表盘，监控集群模式和单点模式，其中集群模式需要收集器 Turbine 配合；
• Zuul：   API 服务网关，功能有路由分发和过滤；
• Config： 分布式配置中心，支持本地仓库、SVN、Git、Jar 包内配置等模式；

资料参考： https://spring.io/projects/spring-cloud-netflix

一个是Alibaba的实现 ：

• Dubbo ：用于实现高性能 Java RPC 通信及服务治理框架，实现了rpc通信，容错，负载均衡和降级等功能
• Nacos：分布式服务注册发现、配置管理、服务管理；
• Sentinel：基于滑动窗口实现单机或集群流量控制、熔断降级、系统负载保护；
• RocketMQ： 分布式消息系统，提供低延时的、高可靠的消息发布与订阅服务；
• Seata：提供了开源的简单且高性能一站式分布式事务解决方案；

此外，一般还会通过SpringBoot+thrift或者Dubbo来实现微服务。Dubbo并不是单纯的rpc通信框架，它其实是一个高效的服务治理框架。实现的功能包括：服务自动注册与发现，rpc远程通信调用，软负载均衡，监控及服务容错降级等等。

资料参考： https://spring.io/projects/spring-cloud-alibaba

(开源地址： https://github.com/spring-cloud-incubator/spring-cloud-alibaba)

3.1、版本管理

    在这个网址： https://spring.io/projects/spring-cloud可以看到Spring-Cloud的版本支持，它并不像传统意义上的版本命名，而是采用了伦敦地铁站的名称，根据字母表的顺序来对应版本时间顺序，也是挺有意思。

    原因是SpringCloud是由多个独立项目组成的整体项目，而每个独立的项目有不同的发布节奏，各个子项目都维护着自己的发布版本号。SpringCloud通过一个资源清单BOM(Bill of Materials)来管理每个版本的子项目清单。为避免与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式来管理。

4、分布式工具组件简介

    分布式中的每个组件都不是平白无故的产生的，都是为了解决某一特定领域的特定问题而存在。例如zk实现服务的发现与注册，通知和配置等功能，sentinel实现服务的降级和熔断，dubbo和thrift实现高效rpc通信及服务的治理，mq实现消息的通信等等。单独的一个组件不能实现我们的服务上线，但是离开它不能说不能实现，至少服务运行的效率、稳定性会大打折扣，治理也会麻烦很多。既然微服务中提供了一些快速构建微服务应用的工具，那就看看提供的工具及其具体的作用。

4.1、网关

    网关(Zuul/Gateway)主要实现了反向代理，实现服务的发现，请求的转发。也可以简单的理解就是一个拦截器，基于servlet API实现，通过Filter，增加对请求的前置和后置模块的处理 。

    在微服务实施后，各个服务的粒度很小，对于外部客户端请求来说，做一个操作可能会涉及到后端的多个服务组件的调用，那意味着它需要频繁的发起多次访问才能进行数据聚合实现用户的功能，这里就可以进行 聚合服务查询。对于客户端来说它需要完成功能请求操作直接调用网关即可，网关根据请求的功能对后端的多个服务的数据完成聚合请求，从而减少客户端的调用频次；除了网关的聚合请求，我们还可以在网关层对请求进行如下前置处理：

• 安全：请求的过滤及前置处理，进行统一的鉴权和认证；
• url重定向；
• 限流降级；
• 请求日志统一记录；
• 发布流量灰度控制等；

4.2、服务注册与发现

    服务拆分以后就会涉及到服务的管理，服务之间的 通信问题 ，这个也是微服务的关键。在满足基础的通信基础上，当公司业务大规模服务化以后，服务之间的路由、负载均衡、容错和降级变的尤其重要，为了更好的进行服务的治理和协调，让服务之间更加高效稳定的工作，就需要涉及到服务的注册和发现，同意协调管理配置我们的服务地址列表，免去了客户端自己维护且不可动态failover的缺点，这也是rpc出现的原因，远不止是通信，其实是一套服务治理的框架，例如服务发现，负载和容错降级等功能。

• 服务注册Eureka/zk/consul：服务提供方(Provider)需要将服务注册暴露给消费端(Consumer)？
• 服务发现：消费端(Consumer)如何发现服务的提供方(Provider)？

 

4.3、负载均衡

    负载(L oad Balance)，假设服务提供者为了扩大吞吐量，采用了10台机器的集群部署，这个时候客户端从注册中心获得服务ip列表以后，应该访问那台服务器呢？

所以必然有一种负载均衡的机制，来实现客户端的请求的分发，常见的负载均衡的算法实现：

• 随机及 加权随机算法：按照权重设置随机概率；
• 轮询及 加 权轮训算法：如果第二台慢就卡在那里了；这样处理力差的就会处理较少的请求；
• 最小连接 及加权最小连接算法：分配给积压最小的任务数的机器；
• Hash源地址 算法及一致性hash算法：hash(ip)%服务器d
• url散列：保证同一个用户的请求打到同一台服务器上；

4.4、降级限流

    降级Sentinel/hytrix，这是保证服务稳定性的重要手段。在分布式架构中，虽然我们能够通过 全链路压测了解到整个系统的吞吐量和瓶颈值，但实际上的流量总是可能会超过我们预期的值，为了保证各个服务节点满足高可用，对于服务来说：

• 一方面是在有准备的前提下做好后备和充足的扩容；
• 另一方面，为了应对突发意外的流量请求服务需要有熔断，限流和降级的措施能力；

    当一个服务调用另外一个服务，可能因为网络原因， 存在恶意攻击，突发的脉冲式流量或者因为连接池满等问题导致的 异常数量， 错误数量及比例， 同比环比达到设定阈值，就需要有一种熔断机制，来防止因为请求堆积导致整个应用雪崩。当发现整个系统的确负载过高的时候，可以选择降级熔断某些功能，也可以加入一些限流算法令牌机制、滑动窗口等来保障核心功能的可用性。

4.5、配置中心

    配置(Config)，服务拆分以后，服务的数量将会变的庞大，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象几百上千的进程出问题，是很难将它们找出来的，因而需要统一的配置中心，来管理所有的配置，进行统一的配置下发。在微服务中，配置往往分为几类：

• 第一类：几乎是不变的配置，这种配置可以直接打在容器的镜像里面；
• 第二类：启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去；
• 第三类：统一配置，需要通过配置中心进行下发通知；例如降级开关，灵活多变的业务参数设置；

4.6、消息通信

    分布式消息(Stream)，面对可能的高并发请求系统，为了提高系统的吞吐量，服务之间的高内聚低耦合，异步处理或者是排队机制方式随处可见。所以消息通信MQ显的尤其重要，SpringCloud也可以整合例如RabbitMQ，RocketMQ等都是效率比较高的消息中间件。

    MQ类似于生活中的快递公司，电商平台等，承担着商品货物的存储和转发功能，产品的搬运工，让天南地北的任何公司和任何人在任何时刻都能通过它进行点对点的高效通信。众多的人群就类似于我们的微服务，快递公司就是我们的mq服务，生产方只需要保证将产品确认投递到快递公司，就OK了，大大提高了效率。MQ的通信避免信息孤岛，更好的实现了信息共享产生价值，解耦了系统，使系统之间的沟通更加高效和灵活。但是引入了MQ，就多了一个中间环节，基于CAP，则需要保证MQ的可用性和数据一致性中做平衡，例如发送、存储、消费等过程的可靠性保证，通过消息的确认回掉、补偿、幂等、顺序性等手段保证系统的稳定运行。

    消息通信对于异步处理提高系统的吞吐量来说具有十分重要的意义，主要功能：

    （1）异步处理：通过异步处理请求，在适合的场景，减少接口的同步调用，提高接口性能和系统的吞吐量；

    （2）削峰填谷：对脉冲式流量做整形，缓冲系统压力；

    （3）系统解耦：对于附加功能和系统之间的信息的传递解耦，灵活可扩展，将信息丢到MQ大水管，谁用谁接谁知道；

    （4）分布式事务：基于base理论，最大努力通知型，保证数据的最终一致性。

      一般设计思想，基于bas理论，使用 【MQ + 本地数据库 + 补偿 + 线程异步处理 + 结果回调】来提高系统的吞吐量。

5、SeviceMesh

    可以简单的把它翻译成为服务网格。它是一个基础设施层，用于处理服务之间的通信，并且负责请求的可靠传输。只有拥有这些成熟的容器化技术和运维体系才能实施微服务。

技术栈下沉

    到了 微服务时代，如果业务人员在做微服务开发时需要处理一系列比较基础的事情，比如服务注册／服务发现／负载均衡／服务熔断和重试等等问题，这将是比较耗时和重复的工作，这些功能对于一个业务程序员来而言，都必须要了解和掌握，而实际上这些和业务功能并没有太大的关系，开发人员应该关心的是如何保证系统的稳定性何可扩展性、如何设计一个安全的Open API，如果对服务进行拆分、如何保证跨库的数据一致性，以及对于旧系统的改造等等一些问题上来。

    那么对于微服务实施来说，能不能像网络协议的下沉一样，增加一个微服务层来完成这个事情呢?

    因此这些重复且基础性工作慢慢的沉淀为一个基础组件，所以有些公司就开始开发基础组件，典型的 Netflix OSS套件( eureka/hystrix/feign/zuul等)。有了这些组件，开发人员就可以使用很少的代码来实现这些服务治理的功能，而恰恰是这个原因，使得spring cloud的普及非常快，但是运维的工作量在慢慢的增大。

工作机制-重运维

    在每个服务中，会有一个Service Mesh实例， 它就类似是原有的客户端和服务端之间的一个代理 ，客户端发起一个rpc请求，像请求本地一样，首先会把请求发送到本地的Service Mesh实例，Service Mesh实例中会自动完成完整的服务之间的调用流程，比如服务发现、负载均衡、熔断和监控等，最终将请求发送给目标服务。而这个Service Mesh实例，专业名称应该为: S idecar。在多个服务的调用中， 这种通信方式的表现形式就像一个网格，sidecar 之间的链接形成了一 个网络，这个就是Service Mesh的由来。

意义

    Service Mesh为业务开发团队降低了门槛，可以更便捷的使用分布式基础组件搭建微服务，提供了稳定的基础设施，最重要的是，让业务开发团队从微服务实现的具体技术细节中解放出来回归到业务。

 

6、小结

    该篇简单的了解了下微服务的概要蓝图，其实技术的本质没有变，例如数据库连接无论是hibernate，ibaties还是mybaties，最终都的遵循jdbc的连接规范，tcp的三次握手，socket通信等等。都只是在不断的对基础的东西进行封装和优化，伴随的是思维模式和领域抽象在升级以满足业务功能的需求。

    技术使用的越简单，后台做的努力和工作就越多。那有岁月静好，只因有人负重前行。

 

    OK---不识庐山真面目，只缘生在此山中。

 

 

 

水滴石穿，积少成多。学习笔记，内容简单，用于复习，梳理巩固。

 

 

参考资料：

https://spring.io/projects/spring-cloud-netflix

https://spring.io/projects/spring-cloud-netflix#learn

https://spring.io/projects/spring-cloud-alibaba

https://spring.io/projects/spring-cloud-alibaba#learn

http://seata.io/zh-cn/docs/overview/what-is-seata.html