微服务架构组件梳理之Netflix停更之后该何去何从

　　自2018年底，Netflix陆续宣布Eureka、Hystrix等框架进入维护状态，不再进行新功能的开发。

　　恰逢最近我打算对公司的办公项目进行微服务架构升级，所以恶补了一番微服务相关知识，在这里进行一个小小的总结梳理。

　　2020年的微服务项目，应该用啥子框架呢？

一、微服务基本概念

　　保持对知识的敬畏，这里还是先复习下，微服务架构的基本概念。

　　引用wiki如下：

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

　　落实到代码上，就是将原来的各个业务包、业务模块，拆分成可以独立部署的一个个业务服务。

　　这样做好处很明显，业务分开之后，我们可以针对各个业务的访问量，细粒度的进行性能优化，扩容，针对性的提高项目的性能。

　　但是也会随之带来一些问题，如微服务之间相互调用性能、分布式事务、服务限流降级熔断、服务配置等。

　　所以，要做好一个微服务项目，就要使用框架来帮助我们解决上述问题，使开发人员更好的面向业务。

二、微服务架构应该考虑的问题

　　那么微服务架构中，如何满足上述所说，让开发人员更好的面向业务，应该考虑哪些问题呢？前辈们早就思考过了，这里梳理一下。

　　1、微服务的注册与发现

　　　　微服务的注册与发现是什么？

　　　　　　我理解，当你有一堆微服务时，一定涉及对每个微服务进行管理。

　　　　　　如何管理呢？首先，应该有个微服务花名册，有多少个微服务，都叫啥名，都住哪，这些基本信息统统记录在案。如果这些都不清楚，何谈管理？

　　　　怎么实现呢？

　　　　　　现微服务的注册和发现，一般都使用注册中心来统一管理。

　　　　　　现在注册中心框架有哪些？都有啥子区别呢？网上一大把资料，参考网络整理如下：

	Nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	CP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Keep Alive
雪崩保护	有	有	无	无
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
SpringCloud集成	支持	支持	支持	支持
Dubbo集成	支持	不支持	不支持	支持
K8S集成	支持	不支持	支持	不支持
自动注销实例	支持	支持	不支持	支持

　　　　　　上述表中有一个一致性协议，涉及到CAP理论，此理论是分布式架构中的重要理论，描述了一致性、可用性、分区容忍性，这里不展开描述了。

　　2、微服务调用

　　　　当把一个个的业务模块拆分成单个服务时，就会出现服务之间的互相调用问题。

　　　　这里要吐槽一下我们原始的项目，微服务之间调用，是通过访问一个单独服务，拿到目标服务的ip+port，然后通过RestTemplate请求。

　　　　这种方式弊端含泪整理如下：　　　　

　　　　　　（1）这种方式会产生大量的重复代码；

　　　　　　（2）单独服务很容易成为性能瓶颈，因为所有的项目在调用其他服务之前，都要先请求这个服务，这个问题线上已经爆发了/(ㄒoㄒ)/~~

　　　　　　（3）若微服务地址发生变化，需要重新登记配置；

　　　　　　（4）已经配置的微服务，不支持扩容，对！没有看错！不支持！

　　　　前人挖坑后人填，吐槽完成之后，言归正传，用什么框架可以解决微服务的调用问题呢？

　　　　　　Ribbon : 一个客户端负载均衡的工具，由Netflix公司开发，很不幸，已经进入了维护状态，不再进行新的功能开发。详情见官方github：https://github.com/Netflix/ribbon

　　　　　　Feign ：内集成了Ribbon，可以通过注解，像本地调用似的跨域调用微服务接口。

　　　　　　OpenFeign ：Spring Cloud在Feign的基础上，支持了SpringMvc的注解。

　　

　　3、服务的限流、降级、熔断

　　　　首先，什么是服务限流、服务降级、服务熔断呢？

　　　　　　服务限流：限流就是限制流量，服务就是微服务，服务限流，即限制微服务的访问流量。流量是个抽象概念，具体到项目接口上，就是请求数或者线程数。

　　　　　　服务降级：

　　　　　　　　把服务分成多个等级，比如我是开饭店的，客人就餐，我提供的三档服务。

　　　　　　　　　　一档：点菜服务、入座服务、上菜服务、喂食服务、加饭服务；

　　　　　　　　　　二档：点菜服务、上菜服务、加饭服务；

　　　　　　　　　   三档：点菜服务、上菜服务。

　　　　　　　　服务降级，就是所有客人默认都是一档服务，但是当我忙不过来的时候，我将服务等级下调至二档或三档，保障我饭店能正常点菜、上菜就行了，其余的非核心服务先不提供。

　　　　　　服务熔断：

　　　　　　　　还是拿餐馆举例子，我的饭店只能容纳100人同时就餐，忽然有一天，一下来了1000人吃饭。

　　　　　　　　为了不把我的餐馆挤爆，我决定，先不对外提供服务，来一个客人，我就赶走一个，等一段时间过后，我尝试着接纳一些人就餐，确认没问题了，我再正常营业。

　　　　概念梳理完毕，我们发现，不管是服务熔断还是降级，对于用户来说，都是非常不好的体验，那我们为啥还要这样做呢？回答这个问题，我们还是以开饭店来举例子：

　　　　先说明，我们现在的项目，是微服务项目，对应到“饭店例子”中，我们开的是连锁饭店，而不是一个小餐馆。

　　　　屁股决定思维，既然我们开的是连锁饭店，就得以大局为重。一个饭店暂停营业了，虽然少了当天的营业额，但是对于我们整个的品牌影响不大。反过来，如果不进行服务熔断等措施，用户强行就餐之后，体验不好，回头上网就是一个差评，这样影响的就不只是一个饭店的营业额，而是整个品牌的价值，后果严重的很。

　　　　从连锁饭店回到微服务项目，一个微服务不好用了，我们进行熔断降级，可减少其对我们整个微服务框架的影响，但是，如果不进行处理，可能由于一个节点失效，到时所有微服务雪崩，到最后整个微服务项目瘫痪，这显然是我们无法承受的，所以，服务熔断、限流、降级，在微服务架构中，很重要，必须做。　　

　　　　话又说回来了，咋做？

　　　　前辈们早就想好，现在人们大多数使用如下两个框架：

　　　　　　Hystrix : 由Netflix公司开发的一个进行服务熔断、降级的框架，但是很不幸，进入维护状态了

　　　　　　sentinel : 阿里开发的开源框架，提供可视化界面，多语言支持的服务熔断降级限流框架

　　4、微服务网关

　　　　微服务项目，首先他得是对外提供服务的，上面几个视角我们多是从微服务之间相互调用这一场景来考虑，这一小节，我们得转变视角，由内部看到外部，当客户端或者是用户，调用微服务的应用接口时，我们需要考虑哪些问题呢？

　　　　（1）首先需要考虑的是寻址，微服务伴随着服务升级，扩容等，其IP、端口一定是在变着的，微服务内部之间调用尚可以通过注册中心+Feign来进行，但是客户端的请求接口调用地址如何处理呢？

　　　　（2）其次是权限认证，微服务如何知道该次请求的客户端是合法的呢？

　　　　　　有人说，可以每个微服务节点都写一套权限认证逻辑（现在我们原始项目就是这么做的/(ㄒoㄒ)/~~），这种方法是不可取的，会造成代码膨胀，同时，若权限认证逻辑变更，得挨个修改每个项目中的代码，要疯掉了。

　　　　　　或者写一个统一权限认证工具，通过jar包形式集成在各个项目中。这种方式尚可，但是如果我要进行版本升级，得所有微服务挨个停止、升级、重启，运维同事估计要提着大刀来砍你了。

　　　　（3）对于外部的请求，我想知道哪些请求是比较热门的，每天有多少客户端请求，并记录日志，这个需求如何处理呢？

　　　　问题一旦可以明确，就相当于解决了一半。这个时候，很明显需要一个大管家，管理客户端到服务器的请求，来解决我们上述这些问题，所以微服务网关这个概念出现了。

　　　　微服务网关概念，摘自wiki百科：

　　　　　　转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉，自己的通信目标是一个网关。

　　　　微服务网关主要职能：

　　　　　　请求接入：作为所有 API 接口服务请求的接入点，管理所有的接入请求；

　　　　　　业务聚合：作为所有后端业务服务的聚合点，所有的业务服务都可以在这里被调用；

　　　　　　中介策略：实现安全、验证、路由、过滤、流控，缓存等策略，进行一些必要的中介处理；

　　　　　　统一管理：提供配置管理工具，对所有 API 服务的调用生命周期和相应的中介策略进行统一管理。

　　　　　　（参考https://www.jianshu.com/p/a2f292221b5c）

　　　　微服务网关框架：

　　　　　　Zuul : 由Netflix公司开发，已经进入维护状态了。

　　　　　　Zuul2 : 还在开发过程中，多次跳票。

　　　　　　Spring Cloud GateWay ：Spring Cloud开发，在SpringMvc上构建的API网关框架。

　　5、配置统一管理

　　　　原来的单应用项目，一个项目的配置文件集中的写在几个配置文件中，由于项目文件不多，维护、配置起来都比较方便，不能算作问题。但是微服务架构下，单个服务都拥有着自己的配置文件，当服务变多，再考虑到开发、测试、生产环境使用不同的配置文件，配置工作一下就变得复杂了起来，需要进行统一管理，方便配置修改及部署上线。

　　　　现在开源的配置管理框架：

　　　　　　Spring Cloud Config : Spring开发的配置服务，可以从github、支持JDBC的数据库或者其他文件系统中拉取配置。

　　　　　　Nacos ：nacos除了有注册中心的功能之外，还可以提供配置管理服务。

　　6、分布式事务

　　　　在单应用的项目中，我们的事务一般交给数据取进行处理，但是微服务项目，不同的微服务连接着不同的数据库，原来的事务处理模式已经不可行了，那么在分布式微服务的项目中，我们该如何进行事务管理呢？

　　　　现在有通用的四种解决思路：

　　　　　　两阶段提交（2PC）

　　　　　　TCC（Try-Confirm-Cancel）

　　　　　　可靠的消息最终一致性

　　　　　　最大努力通知

　　　　分布式事务知识点很多，这里对四种思路不进行详细的介绍，有兴趣的同学自行学习。这里直接给出参考结果：Seata。下面借用seata官网一句话：

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

三、整理

　　回到本文的最一开始，自2018年底，Netflix陆续宣布Eureka、Hystrix等框架进入维护状态，不再进行新功能的开发，那么2020年，微服务项目该用啥子框架呢？推荐整理如下：

　　　　微服务的注册与发现：Nacos、Consul、Zookeeper

　　　　微服务调用：OpenFeign

　　　　服务降级、限流、熔断：Sentinel

　　　　微服务网关 ：Spring Cloud Gateway

　　　　配置统一管理：Nacos

　　　　分布式事务：Seata

　　本文从上述六个角度进行了微服务常用框架的梳理，一个好的微服务项目，需要考虑的点多的很，各位看官，仅供参考。