写在前面

  • 嗯，学习云原生相关，整理课堂笔记记忆
  • 学习的原因：
    • 虽然考了CKA,了解了一些K8s相关的知识
    • 但是对云原生整个体系一直都很模糊
    • 作为Java开发来讲，微服务是大多数行业都要涉及的开源技术栈
  • 博文主要内容涉及：
    • 企业应用架构的演进:单体地狱、SOA，微服务架构,当然微服务并不是“银弹"
    • 典型的微服务框架介绍Springclound之类
  • 食用方式：
    • 博文全是理论，适合对微服务的技术体系初学或者理论温习
    • 如果希望系统学习，这里推荐《微服务架构设计模式》一书，看了一点，个人感觉不错
  • 理解不足小伙伴帮忙指正

傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。——–王小波

企业应用架构演进

应用向CloudNative(云原生)演进，微服务是CloudNative的事实标准。

  • 第一代是单体架构，当然它有很多例如紧耦合、封闭架构等各种各样的问题。
  • 第二代是SOA架构，可能大型企业级的应用里面会比较多，提供了很多种支持，实际上我们看到SOA架构的时候，它已经强调松耦合了。但是没有彻底解耦，存在服务总线
  • 第三代微服务架构，它实际上是变得更加灵活了。在业务变化非常快速的背景之下，微服务架构是一个非常好的解决方案，微服务的核心一敏捷、灵活、精准弹性。 微服务架构出现的最大的意义是不断地提高交付效率，缩短交付周期。

什么是微服务架构

从架构师的角度：微服务架构就是把一个大系统按业务功能分解成多个职责相对单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。

在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

从技术专家的角度：微服务架构就是把相同业务领域或因相同原因而变化的功能聚合到一起，而把不同业务领域或因不同原因而变化的功能分离开并利用轻量化机制（通常为HTTP RESTful APl）实现通信。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。

微服务的定义

2014年，Martin Fowler与James Lewis共同提出了微服务的概念（实际上2009年Netflix就已经开始实践微服务了，但是当时没有微服务一词），定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理（例如Docker）能力，服务可以用不同的编程语言与数据库等组件实现。

  • 微服务架构是一种架构模式，将单体应用划分成一组小的服务，通过服务之间互相协作，共同实现系统功能·
  • 每个服务运行在其独立的进程中，服务间采用轻是级的通信机制协作（通常是基于Restful Apl）。
  • 每个服务都围绕着具体业务进行构建，由独立的小团队负责设计、开发、测试，并可以独立部署到生产环境·

微服务的特征

微服务最主要的就是：小、独、轻、松。就是说: 微服务要小，模块边界要更清晰， 支持独立部署独立演进，每个微服务都应该可以独立部署，独立演进，独立升级的。

另外允许技术多样性，就是在微服务构成的一个整体的应用系统里面，每一块的业务要用你最适合的技术去实现，而不是都统一用一种语言去实现，这也是微服务非常重要的一个特点。

单体架构

MVC架构 ：MVC是模型（Model）、视图（View）、控制器（Controller）的简写，是一种软件设计规范，用一种捋业务逻辑、数据、显示分离的方法组织代码。在J2EE领域，最经典的MVC架构之一就是Spring+Struts(SpringMVC)+ORM（Hibernate/MyBatis）。

经典MVC模式中，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是捋M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。其中，View的定义比较清晰，就是用户界面。

MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是捋M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

单体架构的优缺点

从单体架构演进到SOA服务化架构

SOA是指Service Oriented Architecture

SOA服务化架构

面向服务架构（SOA）是一个组件模型，它捋应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA 有哪些不足

总线ESB的弊端： 我们俩的小区是隔壁，但是要开车去你家，还要到高速上兜一圈。

微服务架构

微服务架构是一项在云中部署应用和服务的新技术。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。

微服务架构与单体架构

微服务与单体架构区别：

  • 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
  • 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
  • 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务架构于SOA架构

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。总结一下，太重了。侵入性强

相比传统SOA的服务实现方式，微服务更具有灵活性、可实施性以及可扩展性，其强调的是一种独立测试、独立部署、独立运行的软件架构模式。

微服务架构诞生于SOA，提倡将单一的应用程序按功能划分为更小的服务单元，服务之间采用通用轻量化机制进行通信，能够将服务单独部署到生产环境。

互联网行业的高速发展，需求变化快，用户群体大，要求系统架构上能灵活构建，易于扩展，还要考虑可伸缩性，高可用性等等。这些需求催生出微服务架构。

微服务不是银弹(不能解决所有的问题)，同样前面说的单体应用和SOA架构也没有过时，需要结合自己的业务场景来选择合适的架构。

微服务的优势和挑战

在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

典型微服务框架介绍

常见的微服务框架

  • Spring Cloud是一系列框架的有序集合，具有丰富的生态。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，主要功能包括服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。

  • ServiceComb作为功能完善的微服务框架，包括应用框架代码生成、服务注册发现、服务配置管理、服务监控、服务调用追踪等功能，为开发者提供端到端的应用DevOps体验。

  • Apache Dubbo是一款高性能、轻量级的开源服务框架，提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

微服务架构模式

微服务架构模式涉及：

  • 微服务之间的RPC通信。
  • 分布式微服务实例和服务发现。
  • 配置外置，动态、集中的配置管理。
  • 提供熔断、隔离、限流、负载均衡等微服务治理能力。
  • 分布式事务管理能力。
  • 调用链、集中日志采集和检索。

下面问问详细来看下：

微服务之间的RPC通信（Remote Procedure Call，远程过程调用） 。微服务架构模式要求微服务之间通过RPC进行通信，不采用其他传统的通信方式，比如共享内存、管道等。常见的RPC通信协议包括REST、gRPC、Web Service等。使用RPC通信，能够降低微服务之间的耦合，提升系统的开放性，减少技术选型的限制。一般建议采用业界标准协议，比如REST。对于性`能要求非常高的场景，也可以考虑私有协议。

分布式微服务实例和服务发现。 微服务架构特别强调 架构的弹性，业务架构需要支持微服务多实例部署来满足业务流量的动态变化。微服务设计一般会遵循无状态设计原则，符合该原则的微服务扩充实例，能够带来处理性能的线性提升。

配置外置及动态、集中的配置管理 。配置管理中间件给所有微服务提供统一的配置管理视图，有效降低配置管理的复杂性。搭配治理控制台，可以在微服务运行态对微服务的行为进行调整。

提供熔断、隔离、限流、负载均衡等微服务治理能力 。微服务架构存在一些常见的故障模式，通过这些治理能力，容灾措施，能够减少故障对于整体业务的影响，避免雪崩效应。

分布式事务管理能力 。常见的分布式事务处理模式包括Saga、TCC、无侵入式等。分布式事务管理可以降低处理分布式事务一致性问题的难度。

调用链、集中日志采集和检索。查看日志仍然是分析系统故障最常用的手段，调用链信息可以帮助界定故障和分析性能瓶颈。

为什么需要Spring Cloud？

  • Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证。
  • Spirng Cloud天然支持Spring Boot，更加便于业务落地。
  • Spring Cloud发展非常的快。
  • Spring Cloud是Java领域最适合做微服务的框架。
  • 相比于其它框架，Spring Cloud对微服务周边环境的支持力度最大。
  • 对于中小企业来讲，使用门槛较低。开源

Spring Cloud的优势分析

优点：

  • 产出于Spring大家族，社区生态完善
  • 有Spring Boot这个独立干将可以省很多事,内嵌的web服务器，起不依赖，自动化配置，各种微服务组件兼容性好。
  • Spring Cloud 活跃度很高，教程很丰富，遇到问题很容易找到解决方案。
  • 提供了注解的方式来自动化配置，轻轻松松几行代码就完成了熔断、均衡负责、服务中心的各种平台功能。

缺点

  • Spring Cloud也有一个缺点，只能使用Java开发，SDK侵入性强，sdk版本差距较大时需要对代码进行修改，对于废弃的api寻找一些新的替代，不适合小型独立的项目。

整理来讲，Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

Spring Cloud 框架

从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。

  • 其中Eureka负责服务的注册与发现，很好地将各服务连接起来,不过现在已经不维护了
  • Hystrix负责监控服务之间的调用情况，连续多次失败进行熔断保护。
  • Hystrix dashboard，Turbine 负责监控Hystrix的熔断情况，并给予图形化的展示。
  • Spring Cloud Config提供了统一的配置中心服务。当配置文件发生变化的时候，Spring Cloud Bus负责通知各服务去获取最新的配置信息。
  • 所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用。
  • 最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析。

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。

Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

核心概念

服务注册

服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。

服务发现

服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

Spring Cloud Netflix是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。

负载均衡

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

Ribbon主要为客户一侧提供软件负载均衡算法，客户端组件包括连接超时、重试、重试算法等等，并带有可插拔/定制的负载均衡组件策略，并集成一些功能，比如使用Archaius完成运行时配置。

需要注意的是这里的负载均衡是客户端LB，和我们用Ng或者Haproxy做的LB是有本质区别的，可以理解为细粒度的LB。

API网关

微服务网关，介于客户端与服务器之间的中间层，所有的外部请求都会先经过微服务网关。客户端只需要与网关交互，只知道一个网关地址即可。

  • 将所有API调用统一接入到API网关层，由网关层统一接入和输出。
  • 一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。
  • 有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

配置中心

配置中心就是把项目中各种配置、各种参数、各种开关，全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。

当各个服务需要获取配置的时候，就来配置中心的接口拉取。当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

Spring Cloud Config将配置信息中央化保存, 配置Spring Cloud Bus可以实现动态修改配置文件，整体基于观察订阅的设计模式，当然，也可以使用zookeep来实现

熔断

熔断：这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。一般熔断的时候，会提供对应的熔断策略。

spring-cloud-netflix-hystrix 对 Hystrix 进行封装和适配，使 Hystrix 能够更好地运行于 Spring Cloud 环境中，为微服务间的调用提供强有力的容错机制。

雪崩

客户端访问A服务，而A服务需要调用B服务，B服务需要调用C服务，由于网络原因或者自身的原因，如果B服务或者C服务不能及时响应，A服务将处于阻塞状态，直到B服务和C服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。

服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

断路器将远程方法调用包装到一个断路器对象中，用于监控方法调用过程的失败。 一旦该方法调用发生的失败次数在一段时间内达到一定的阀值，那么这个断路器将会跳闸

在接下来时间里再次调用该方法将会被断路器直接返回异常，而不再发生该方法的真实调 用。 这样就避免了服务调用者在服务提供者不可用时发送请求，从而减少线程池中资源的 消耗，保护了服务调用者。

虽然断路器在打开的时候避免了被保护方法的无效调用，但是当情况恢复正常时，需要外部干预来重置断路器，使得方法调用可以重新发生。 所以合理的断路器应该具备一定的开关转化逻辑，它需要一个机制来控制它的重新闭合

链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。

Spring Cloud Sleuth主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了zipkin。

Spring Cloud的技术实现

Spring Cloud的子项目，大致可分成两类.

一类是对现有成熟框架”Spring Boot化”的封装和抽象，也是数量最多的项目；

二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka，ActiveMQ这样的角色。对于我们想快速实践微服务的开发者来说，第一类子项目就已经足够使用。

  • Spring Cloud Netflix是对Netflix 开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。
  • Spring Cloud Config将配置信息中央化保存，配置Spring Cloud Bus可以实现动态修改配置文件
  • Spring Cloud Stream分布式消息队列，是对Kafka，MQ的封装
  • Spring Cloud Security对Spring Security的封装，并能配合Netflix使用Spring Cloud Zookeeper对Zookeeper的封装，使之能配置其它Spring Cloud的子项目使用
  • Spring Cloud Eureka是Spring Cloud Netftix微服务套件中的一部分，它基于Netflix Eureka 做了二次封装，主要负责完成微服务架构中的服务治理功能。

Spring Cloud微服务典型部署

  • 不同的应用可以通过gateway进行交互。
  • 也可以通过gateway为前端提供接口。

微服务引擎 CSE

  • 微服务引擎（Cloud ServiceEngine，CSE），是用于微服务应用的云中间件，为用户提供注册发现、服务治理、配置管理等高性能和高韧性的企业级云服务能力。
  • CSE可无缝兼容Spring Cloud、ServiceComb等开源生态。
  • 用户也可结合其他云服务，快速构建云原生微服务体系，实现微服务应用的快速开发和高可用运维。
  • CSE一般和数据库、缓存和消息中间件同时使用，完成业务功能的开发。
  • AOM、APM、LTS等工具，则为业务提供运维能力，帮助检测业务故障、分析故障原
    因。

CSE功能介绍

CSE可以支持多种语言。

CSE功能组件与Spring Cloud框架的关系

Spring Cloud Huawei的位置和作用

Spring Cloud Huawei是构建在Spring Cloud应用之上，基于Spring Cloud现有能力构建的，Spring Cloud huawei提供的一系列新的组件。目的是让开发者以比较低的成本迁移到华为云微服务引擎CSE。

  • Spring cloud huawei作为依赖被引用。
  • 开发使用spring cloud框架。
  • 接入到CSE中。
  • CSE中包含服务注册发现、配置、治理功能。

Spring Cloud Huawei功能介绍

微服务代码框架

Spring Cloud huawei接入流程

  • 引入依赖包，引入Spring Cloud Huawei依赖。

  • 接入服务注册发现中心。

  • 接入配置中心。