【云原生】10分钟带你了解微服务架构--Dubbo与Spring Cloud

前言

云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。Cloud Native是一种应用程序开发风格，可鼓励在持续交付和价值驱动型开发领域轻松采用最佳实践。一个相关的学科是构建12要素应用程序，其中开发实践与交付和运营目标保持一致，例如，通过使用声明性编程，管理和监视。

云元素的四要素：

1.微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。

2.容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。

3.DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

4.持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

---

一、什么是微服务?

        作为云元素之首的微服务，它的架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。其中，Dubbo和Spring Cloud是两种比较主流的微服务架构。下面就来简单介绍下Dubbo和Spring Cloud。

---

二、Dubbo是什么?

-        Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。Dubbo是一种分布式服务框架（RPC框架）。

---

1.Ddubbo使用RPC实现服务输入输出

        在去选择技术框架时，技术框架最基本要解决上面现存问题，同时我们也要确认出我们的期望，要达到的目标是什么：

1.支持当前业务需求，这是最最基本的条件；
2.服务避免单点问题，去中心化；
3.服务高可用、高并发，解耦服务依赖；
4.服务通用化，支持异构系统调用服务；
5.服务依赖关系自维护，可视化；
6.服务性能监控自统计，可视化；
7.服务需自带注册、发现、健康检查、负载均衡等特性；
8.开发人员关注度高，上手快，简单轻量，低侵入；

        还有最重要一点，这也是往往很多技术人员进入的误区，“对于技术，不要为了使用而使用，用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构。所以Dubbo选择了RPC。

---

2.RPC是什么 ?

        分布式服务架构当垂直应用(Web框架 MVC)越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
可以实现RemoteProcedureCall 远程过程调用 。

---

3.Dubbo工作原理(RPC框架)

Dubbo的工作原理可分为5个组件及6个步骤：

5个组件：Container 服务容器（有时会忽视）、Provider 提供者 、Registry 注册中心 、Consumer 消费者和Monitor 监控中心。

6个步骤：Start 开始（发布）、Register 注册、Subscribe 订阅、Notify 推送、Invoke 调用缓存、统计 Count。

（1）Container 服务容器

（2）Provider 提供者

（3）Registry 注册中心 zookeeper

（4）Consumer 消费者

（5）Monitor 监控中心

0.服务容器Container 负责启动加载运行服务提供者Provider。（第一步start，就是将服务装载容器中，然后准备注册服务。和Spring中启动过程类似，spring启动时，将bean装载进容器中的时候，首先要解析bean。所以dubbo也是先读配置文件解析服务。）

0.服务容器Container 负责启动加载运行服务提供者Provider。

根据Provider配置的文件根据协议发布服务 , 完成服务的初始化.

1.Provider在启动时，根据配置中的Registry地址连接Registry，

将Provider的服务信息发布到Registry，在Registry注册自己提供的服务。

2.Consumer在启动时，根据消费者XML配置文件中的服务引用信

息，连接到Registry，向Registry订阅自己所需的服务。

3.Registry根据服务订阅关系，返回Provider地址列表Consumer，

如果有变更，Registry会推送最新的服务地址信息给Consumer。

4.Consumer调用远程服务时，会根据路由策略，先从缓存Provider

地址列表中选择一台进行，跨进程调用服务，假如调用失败，再重新选另一台调用。

5.服务Provider和Consumer，会在内存中记录调用次数和调用时

间，每分钟发送一次统计数据到Monitor（异步请求）。

---

三、Spring Cloud是什么？

Spring Cloud通过多种特定方式促进了云原生发展方式。起点是一组功能，分布式系统中的所有组件都需要轻松访问这些功能。Spring Cloud建立在Spring Boot上，涵盖了许多这些功能。Spring Cloud作为两个库提供了更多功能：Spring Cloud上下文和Spring Cloud Commons。Spring Cloud上下文为Spring Cloud应用程序的ApplicationContext提供了实用程序和特殊服务（引导上下文，加密，刷新作用域和环境端点）。Spring Cloud Commons是在不同的Spring Cloud实现中使用的一组抽象和通用类（例如Spring Cloud Netflix和Spring Cloud Consul）。

---

1.Spring Cloud包含什么？

Spring Cloud包含配置管理工具、核心组件、消息总线、集群、消息驱动等…其中核心组件是Spring Cloud的关键。

---

2.Spring Cloud的五大核心组件

2.1 Eureka

Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。每个服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。

—

2.2Ribbon

简单说，Ribbon主要提供客户侧的软件负载均衡算法。和其他构成NIWS 内部进程通信栈的组件一起，该算法在 Netflix 经历了严峻考验。一般与 Eureka 一起使用，Eureka 主要用来平衡到中间层服务的请求。

服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台。

---

2.3Feign

Feign是声明性的web服务客户端。它使编写web服务客户端更加容易。要使用Feign，请创建一个接口并对其进行注释。它具有可插入的注释支持，包括Feign注释和JAX-RS注释。Feign还支持可插拔编码器和解码器。Spring Cloud添加了对Spring MVC注释的支持，并支持使用Spring Web中默认使用的同一HttpMessageConverters。Spring Cloud集成了Ribbon和Eureka以在使用Feign时提供负载平衡的http客户端。

基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求。

---

2.4Hystrix

Hystrix有三个作用：
1.隔离:其他服务不会受到影响。
2.熔断:不会调用宕机的服务。
3.降级:在“脏”数据库修改数据。

        对于隔离来说，Netflix创建了一个名为Hystrix的库，该库实现了断路器模式。在微服务架构中，通常有多个服务调用层，较低级别的服务中的服务故障可能会导致级联故障，则电路断开并且无法进行呼叫。在错误和断路的情况下，开发人员可以提供备用功能。所以 Hystrix后备可防止级联故障，保障其他服务不受影响。

        对于熔断和降级来说，如果一个服务宕机，当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
        因此，Hystrix三个作用基本上是同时发生的，这极大的解决了服务器宕机问题。

---

2.5Zuul

Zuul，也就是微服务网关。这个组件是负责网络路由的，如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务。

---

总结

微服务两大主流架构Spring Cloud 和Dubbo到此就讲完了，在云原生火热的今天，我们不得不去学习、巩固、加强自己的支持储备，让自己变得强大，微笑迎接充实的每一天。

---

注：本文章仅用于参考学习，如有错误，请大家指正。