微服务专题系列 - 微服务生态简介

一、前言

本次专题笔者主要是介绍微服务相关的技术及其实现原理和部分核心源码解析，并且介绍相关技术之间的关系，以及真正运用到生产环境时应当如何做技术选型。

说明：本专题的demo采用的是Spring Boot 2.1.5.RELEASE，当然也会去穿插说明一些笔者从1.5.x系列升级到2.x系列版本所踩到的坑。另外笔者该专题的所有博文都将会围绕着【是什么】，【为什么】，【怎么用】，【底层实现原理】，【核心代码解析】这几个点来阐述。

 

二、微服务简介

1.什么是微服务

微服务最早的概念源于 Martin Fowler 于 2014 年 3 月 25 日写的一篇文章 Microservices（中文版翻译点击查看）（具体细节读者有兴趣可以自己去看）。其实说的通俗一点就是只要能对外提供接口服务就是微服务。例如，你用spring boot写了一个controller，访问返回一个hello字符串，其实这就是一个微服务（源码），如下图所示：

 

2.为什么要用微服务架构

笔者刚刚2011年参加工作那会，基本上绝大多数的系统都是所有功能集成在一起的。那这样的架构有什么优缺点呢？相比下微服务又有什么优劣好坏呢

 

集中型服务架构优点：

a.编码调试简单，因为所有的代码全集中在一个项目之中，团队协作时可以直接debug调试程序，出了问题能很快定位到问题所在。

b.系统复杂度可控，数据存储时也不会出现分布式事务，不用考虑数据一致性的问题。

c.并发和负载不高的时候，性能较好（毕竟是服务内部调用，少了网络传输序列化和反序列化这个环节）。

 

集中型服务的缺点：

a.可用性差，一旦遇到宕机就无法再对外提供服务；

b.可伸缩性较差，水平扩容和迁移困难，例如电商平台搞类似双十一促销活动时，流量可能是平时的好几倍甚至是好几十倍，遇到这种临时扩容难度高，虽然能够通过lvs+nginx解决横向扩容的问题，但是大型系统一般对系统配置要求较高，都是采用的实体机，搭建环境，调试以及后续的迁移都需要付出较大的代价，另外数据库也是重要的性能瓶颈；

c.代码高度耦合度，维护成本高，团队协作时，如果小伙伴代码有问题，很可能导致整个系统跑不起来；

d.性能瓶颈难以突破，虽然通过强行堆机器配置能缓解部分压力，但是毕竟单机网络，磁盘IO，内存等资源也是有限的，尤其是堆的越高服务器成本也会成对数增长。笔者曾经遇到过某个服务器（128G内存+42核+10T SSD）的磁盘IO长期保持98%，一遇到并发就崩。

 

也正是由于上述的这些问题，后面技术专家们就开始琢磨如何将一个大型的系统拆解成多个独立的小系统。中间就出webservice这类技术，其实本质上这也是微服务，只不过性能和灵活性较差而已，例如webservice一旦服务提供者的ip和端口改了会影响上游调用者，需修改配置重启后方能恢复正常。针对这类问题，引入服务治理的概念，我们除了需要做到提供远程调用之外，还需要提供服务注册，负载均衡，服务降级，限流，日志埋点，网关路由，监控等功能保证服务高性能，高可用，容灾等特性

 

3.微服务的技术栈有哪些

在介绍各个组件之前，笔者先阐述一下微服务，Spring cloud，Dubbo，RPC之间的关系，现在网上的说法也是五花八门，笔者起初在学习微服务系列技术之前也是很疑惑，面试的过程之中也是常见的考题。

• 微服务只是一个概念和申明，正如笔者开头所说，只要能对其他系统提供接口的服务都能称之为微服务，现在网上的说法基本上已经把Spring Cloud和微服务划了等号，这其实是不对的，只不过是Spring Cloud解决的比较全面而已，具体的如下图所示：

 

• Spring Cloud是一整套微服务的技术解决方案，目前也有两套方案，一套是Spring Cloud Netflix，另一套是Spring Cloud Alibaba，含服务注册发现组件（Euraka，Nacos），负载均衡组件（Robbin，loadbalance），配置中心组件（Config+Git，Nacos，Apollo），熔断（Hystrix，Sentinel），链路监控（Pinpoint，Skywaying）等。这里笔者温馨提示，目前Netflix已经不再维护了，所以建议大家也可以多了解一下Spring Cloud Alibaba，两套的技术可以混着用。另外本质上Spring Cloud是一个maven项目，集成了各个组件（Spring Cloud Netflix源码，Spring Cloud Alibaba源码），如下图所示：

 

• RPC是一种规范而已，其实就类似咱们Java里面的interface，定义了某个方法已经传什么参数，返回什么参数，具体的实现则由相关的框架去实现。主要含三大块，通信协议，序列化技术，以及框架，前面介绍微服务的图里面已有说明。

 

• Dubbo是一种非常流行的RPC的框架。

 

三、主流微服务解决方案

服务注册中心对比

Feature	Consul	Zookeeper	Nacos	Euerka
服务健康检查	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳	可配支持
多数据中心	支持	—	—	—
kv存储服务	支持	支持	支持	—
一致性	raft	paxos	raft	—
cap	ca	cp	cp/ap	ap
使用接口(多语言能力)	支持http和dns	客户端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持 long polling/大部分增量
自身监控	metrics	—	metrics	metrics
安全	acl /https	acl	https支持（弱）	—
spring cloud集成	已支持	已支持	已支持	已支持

 

说明：从笔者自己的使用情况看4个其实差别不是特别大，但是界面的友好度来说，Consul和Nacos会好很多，另外Nacos相对来说会灵活一些，同时支持CP和AP两种模式。但是从社区的活跃度和稳定性来说，肯定是Consul要强的多，另外Consul是Go语言研发的，所以性能天然就有优势，所以综合来看目前Consul是最佳选择。ZK和Eureka本身都有自身的短板，尤其是Eureka已经停止维护了。

 

配置中心对比

Feature	Spring Cloud Config	Apollo	Nacos
开源时间	2014.9	2016.5	2018.6
配置实时推送	支持（Spring Cloud Bus）	支持（HTTP长轮询1S内）	支持（HTTP长轮询1S内）
版本管理	支持（Git）	支持	支持
灰度发布	支持	支持	待支持
权限管理	支持	支持	待支持
多集群	支持	支持	支持
多环境	支持	支持	支持
多环境	支持	支持	支持
多语音	只支持Java	Go，C++，Python，PHP，Java，.Net，OpenAPI	Go，C++，Python，PHP，Java，.Net，OpenAPI
单机部署	Config-Server+Git+Spring Cloud Bus（支持配置实时推送）	Apollo-quickstart-MySQL	Nacos单节点
分布式部署	Config-Server(2)+Git+MQ（部署复杂）	Config(2)+Admin(2)+Portal(2)+MySQL（部署复杂）	Nacos(3)+MySQL（部署简单）
配置格式校验	不支持	支持	支持
通信协议	HTTP和AMQP	HTTP	HTTP
数据一致性	Git保证数据一致性，Config-Server从Git读取数据	数据库模拟消息队列，Apollo定时读消息	HTTP异步通知
单机读	7（限流所致）	9000	15000
单机写	5（限流所致）	1100	1800
3节点读	21（限流所致）	27000	45000
3节点写	5（限流所致）	3300	5600

说明：从笔者的使用情况看，Apollo会成熟稳定不少，但是确实是过于重了，对于初学者来说可能Nacos更容易上手，另外关于灰度发布这一块，笔者认为这应该是网关的职责范畴，倒是权限这一块Nacos确实是做的比较差（后续会维护）。Config没什么好说的，使用上不太友好，也和Git是强耦合。

 

 

网关对比

组件	RPS(request per second)
Spring Cloud Gateway	Requests/sec: 32213.38
Zuul	Requests/sec: 20800.13
Linkerd	Requests/sec: 28050.76

详细信息请参考：https://blog.csdn.net/j3t9z7h/article/details/79295104

 

熔断器对比

	Sentinel	Hystrix
隔离策略	基于并发数	线程池隔离/信号量隔离
熔断降级策略	基于响应时间或失败比率	基于失败比率
实时指标实现	滑动窗口	滑动窗口（基于 RxJava）
规则配置	支持多种数据源	支持多种数据源
扩展性	多个扩展点	插件的形式
基于注解的支持	即将发布	支持
调用链路信息	支持同步调用	不支持
限流	基于 QPS / 并发数，支持基于调用关系的限流	不支持
流量整形	支持慢启动、匀速器模式	不支持
系统负载保护	支持	不支持
实时监控 API	各式各样	较为简单
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix

说明：Hystrix相对Sentinel来说还是做的比较简单，由于目前Sentinel对Webflux支持的不是太好，笔者也是一直没有采用Sentinel，但客观的讲Sentinel还是比较强大，界面也相当的友好。