| hello云胜

微服务架构浅显分享

概念

微服务

Martin Fowler

特别擅长抽象归纳和制造概念

Microservices (martinfowler.com)

微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通讯。同时，服务会使用最小规模的集中管理（例如Docker）技术，服务可以用不同的编程语言与数据库等。

单体应用

如果你不知道单体应用的痛，那也不会深刻理解微服务的价值。

早期的应用技术栈大致可分为LAMP（Linux + Apache + MySQL + PHP）和MVC（Spring + iBatis/Hibernate + Tomcat）两大流派。

无论是LAMP还是MVC，都是为单体应用架构设计的。

然而随着业务规模的不断扩大，代码和开发人员的增加，很快出现了一下几个问题：

部署效率低下
代码管理，代码冲突
系统高可用性差
线上发布慢

为了解决这些问题，服务化几乎就是自然而然产生的。

SOA

面向服务的体系结构 SOA (Service-Oriented Architecture) 听起来和微服务很像，但 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间，最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

RPC

Remote Procedure Call，远程过程调用。

解决微服务的跨节点调用问题。

和restful调用的区别：

协议不同
调用方式不同。rpc的实现上经常使用本地代理，就像调用一个本地方法。

其实这两者并不是一个维度的概念，总得来说RPC涉及的维度更广。RPC可以基于HTTP协议实现，也可以直接在TCP协议上实现。

微服务框架

微服务架构下，服务调用主要依赖以下基本组件：

服务描述

常用的服务描述方式包括RESTful API、XML配置以及IDL文件三种。

restful的如springcloud，xml的如dubbo的xml文件，IDL文件方式通常用作Thrift和gRPC这类跨语言服务调用框架
注册中心

服务框架
服务监控
服务追踪
服务治理

Dubbo

阿里，最早只支持java。目前多语言支持。

默认通信协议是Dubbo Protocol，也支持其他的。

Tars

腾讯，最早只支持C++，目前支持C++,Java,PHP,Nodejs,Go语言。

通信协议是Tars protocol

Motan

新浪微博，java

gRPC

Google，跨语言。

gRPC 本身没有提供注册中心，但为开发者提供了实现注册中心的接口

thrift

Facebook，跨语言。

总结：

rpc框架并不神秘，简单来看就是解决如何调用远程服务的问题。所以通过注册中心进行服务的注册和发现。解决服务的负载均衡问题和状态监控。以及对象的序列化传输。但是要做一个高性能的，功能完善的rpc框架就难了。

RPC和微服务的关系

如上所述，远程过程调用。解决微服务的跨节点调用问题。

微服务框架一般都包含了RPC的实现和一系列「服务治理」能力，是一套软件开发框架。我们可以基于这个框架之上实现自己的微服务，方便的利用微服务框架提供的「服务治理」能力和RPC能力，所以微服务框架也被有些人称作RPC框架。

SpringCloud微服务框架

Spring Cloud全家桶，而Dubbo基本上只提供了最基础的RPC框架的功能，其他微服务组件都需要自己去实现。

注册中心

nacos

zookeeper，etcd，Eureka，Consul

负载均衡

客户端服务均衡

Ribbon –> Feign

全链路监控

skywalking，zipkin，pinpoint，jaeger, springcloud sleuth

Google Dapper：Dapper，大规模分布式系统的跟踪系统 by bigbully

监控

分布式事务

阿里开源的 seata

配置中心

Apollo

nacos

springcloud-config

服务网关

springcloud-gateway

服务限流、熔断、降级

推荐使用阿里开源的Sentinel

限流

应对突增流量，对超出自身处理能力的用户请求则予以拒绝，牺牲一部分用户体验，保证系统的稳定运行。

降级

降级就是通过停止系统中的某些非核心的功能，来保证系统高优先级服务的可用性。

熔断

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

熔段解决如下几个问题：

当所依赖的对象不稳定时，能够起到快速失败的目的；
快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复

断路器。Hystrix

熔断就是把客户端的每一次服务调用用断路器封装起来，通过断路器来监控每一次服务调用。如果某一段时间内，服务调用失败的次数达到一定阈值，那么断路器就会被触发，后续的服务调用就直接返回，也就不会再向服务提供者发起请求了。

Closed状态：正常情况下，断路器是处于关闭状态的，偶发的调用失败也不影响。
Open状态：当服务调用失败次数达到一定阈值时，断路器就会处于开启状态，后续的服务调用就直接返回，不会向服务提供者发起请求。
Half Open状态：当断路器开启后，每隔一段时间，会进入半打开状态，这时候会向服务提供者发起探测调用，以确定服务提供者是否恢复正常。如果调用成功了，断路器就关闭；如果没有成功，断路器就继续保持开启状态，并等待下一个周期重新进入半打开状态。

滑动窗口算法

Hystrix通过滑动窗口来对数据进行统计，默认情况下，滑动窗口包含10个桶，每个桶时间宽度为1秒，每个桶内记录了这1秒内所有服务调用中成功的、失败的、超时的以及被线程拒绝的次数。当新的1秒到来时，滑动窗口就会往前滑动，丢弃掉最旧的1个桶，把最新1个桶包含进来。

任意时刻，Hystrix都会取滑动窗口内所有服务调用的失败率作为断路器开关状态的判断依据，这10个桶内记录的所有失败的、超时的、被线程拒绝的调用次数之和除以总的调用次数就是滑动窗口内所有服务的调用的失败率。

微服务的容器化

我们现在在做的事

下一代微服务架构

传统的微服务框架的问题

服务消费者这边除了自身的业务逻辑实现外，还需要集成部分服务框架的逻辑，比如服务发现、负载均衡、熔断降级、封装调用等，而服务提供者这边除了实现服务的业务逻辑外，也要集成部分服务框架的逻辑，比如限流降级、服务注册等。

有人把kubernetes,service mesh和serveLess称为云原生架构的三驾马车

Service Mesh–服务网格

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

和传统的微服务架构的本质区别