微服务架构组件梳理之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：//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 服务的调用生命周期和相应的中介策略进行统一管理。
（参考//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
本文从上述六个角度进行了微服务常用框架的梳理，一个好的微服务项目，需要考虑的点多的很，各位看官，仅供参考。
