微服务的应用标准化(上)————技术标准化(栈)

水深无声 2023-10-03 12:59 7阅读 0赞

近年，Spring Cloud俨然已经成为微服务开发的主流技术栈，在国内开发者社区⾮常⽕爆。

但其实Spring Cloud也存在多种技术组件，⽐如Spring Cloud Netflix 和Spring Cloud Alibaba两系，其都有注册中⼼组件，这个时候技术选型就成了问题。如何去选择⼀个好的 微服务框架？结合云基地的项⽬实践，做出⼀些经验总结和看法。

### 核心支撑组件 ###

### 服务框架SpringBoot ###

Spring可以说是史上最成功的Web App/API开发框架之⼀，它融⼊了Java社区中多年来沉淀 下来的最佳实践，虽然有将近15年历史，但⽬前的社区活跃度仍呈上升趋势。Spring Boot 在Spring的基础上进⼀步打包封装，提供更贴⼼的Starter⼯程，⾃启动能⼒，⾃动依赖管 理，基于代码的配置等特性进⼀步降低接⼊门槛。

**另外Spring Boot也提供actuator这样的生产级监控特性，支持DevOps研发模式，它是微 服务开发框架的推荐首选。**

REST契约规范Swagger和Spring有比较好的集成，使得Spring也支持契约驱动开发 (Contract Driven Development)模型。对于一些中大规模的企业，如果业务复杂团队较 多，考虑到互操作性和集成成本，建议采用契约驱动开发模型，也就是开发时先定义 Swagger契约，然后再通过契约生成服务端接又和客户端，再实现服务端业务逻辑，这种开发模型能够标准化接又，降低系统间集成成本，对于多团队协同并⾏开发⾮常重要。

### API对外网关 - SpringCloud Gateway ###

SpringCloud Gateway 作为 Spring Cloud ⽣态系统中的⽹关，⽬标是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新⾼性能版本进⾏集成，仍然还是使 ⽤的Zuul 2.0之前的⾮Reactor模式的⽼版本。⽽为了提升⽹关的性能，SpringCloud Gateway是基于WebFlux框架实现的，⽽WebFlux框架底层则使⽤了⾼性能的Reactor模式通 信框架Netty。

Spring Cloud Gateway 的⽬标，不仅提供统⼀的路由⽅式，并且基于 Filter 链的⽅式提供了 ⽹关基本的功能，例如：安全，监控/指标，和限流。

**Spring Cloud Gateway 底层使⽤了⾼性能的通信框架Netty。**

Spring在2017年下半年迎来了Webflux，Webflux的出现填补了Spring在响应式编程上的空 ⽩，Webflux的响应式编程不仅仅是编程风格的改变，⽽且对于⼀系列的著名框架，都提供 了响应式访问的开发包，⽐如Netty、Redis等等。

SpringCloud Gateway 使⽤的Webflux中的reactor-netty响应式编程组件，底层使⽤了Netty 通讯框架。

Webflux模式替换了旧的Servlet线程模型。⽤少量的线程处理request和response io操作， 这些线程称为Loop线程，⽽业务交给响应式编程框架处理，响应式编程是⾮常灵活的，⽤ 户可以将业务中阻塞的操作提交到响应式框架的work线程中执⾏，⽽不阻塞的操作依然可 以在Loop线程中进⾏处理，⼤⼤提⾼了Loop线程的利⽤率。

### 服务注册发现与配置中心 - SpringCloudAilibaba Nacos ###

Nacos 是⼀个更易于构建云原⽣应⽤的动态服务发现、配置管理和服务管理平台。它孵化于 阿⾥巴巴，成长于⼗年双⼗⼀的洪峰考验，沉淀了简单易⽤、稳定可靠、性能卓越的核⼼竞 争⼒。

Nacos⽤来做服务注册中⼼以及配置中⼼，相当于Spring Cloud的Eureka（已停⽌维护）或 者Zookeeper（没有控制台，不⽅便查阅注册服务）抑或Consul（某种原因，不建议使⽤） 服务注册中⼼，以及Spring Cloud Config或携程开源的Apollo配置中⼼⼆者的结合版。

并且Nacos是像⼀个中间件⼀样，不同于erueka是⼀个⾃⼰单独写的springboot项⽬。 Nacos，需要安装⼀个service，它是已经写好的⼀套组件，安装之后运⾏即可。并且它是基 于Java 环境运⾏，只要服务器上⾯有JDK，那么就能够使⽤，不管什么操作系统，不管什么 架构(X86,ARM64... ...)都能够运⾏

并且Nacos2.0拥有全新 2.0 架构。不仅将性能⼤幅提升 10 倍，⽽且内核进⾏了分层抽象， 并且实现插件扩展机制。

Nacos 2.0 架构层次如下图，它相⽐Nacos1.X的最主要变化是：

*  通信层统⼀到 gRPC 协议，同时完善了客户端和服务端的流量控制和负载均衡能 ⼒，提升的整体吞吐。
 *  将存储和⼀致性模型做了充分抽象分层，架构更简单清晰，代码更加健壮，性能更 加强悍。
 *  设计了可拓展的接⼜，提升了集成能⼒，如让⽤户扩展实现各⾃的安全机制。

![60a03fda070fadd99493103f7db0b810.png][]

### 服务安全组件 ###

### 认证授权中⼼ - SpringSecurity OAuth3 ###

⼀般意义来说的应⽤访问安全性，都是围绕认证（Authentication）和授权 （Authorization）这两个核⼼概念来展开的。即⾸先需要确定⽤户⾝份，在确定这个⽤户 是否有访问指定资源的权限。认证这块的解决⽅案很多，主流的有CAS、SAML2、OAUTH2 等，我们常说的单点登录⽅案（SSO）说的就是这块，授权的话主流的就是spring security 和shiro。⽐较轻量级，相⽐较⽽⾔spring security确实架构⽐较复杂。但是在功能⽅⾯， spring security是最为丰富的。

Spring Security⼤家都不陌⽣，它是⼀套安全框架，可以基于RBAC（基于⾓⾊的权限控 制）对⽤户的访问权限进⾏控制，核⼼思想是通过⼀系列的filter chain来进⾏拦截过滤。

⽽OAuth2，它是⼀个关于授权的开放标准，核⼼思路是通过各类认证⼿段（具体什么⼿段 OAuth2不关⼼）认证⽤户⾝份，并颁发token（令牌），使得第三⽅应⽤可以使⽤该令牌在 限定时间、限定范围访问指定资源。主要涉及的RFC规范有RFC6749（整体授权框 架）,RFC6750（令牌使⽤）,RFC6819（威胁模型）这⼏个。获取令牌的⽅式主要有四种， 分别是授权码模式，简单模式，密码模式和客户端模式

Spring Security OAuth2是Spring Security基础上的⼀个扩展,将OAuth2和Spring Security集 成，可以得到⼀套完整的安全解决⽅案。

但是Spring Security OAuth2还只是⼀个框架，不是⼀个端到端的开箱即⽤的产品，企业级 应⽤仍需在其上进⾏定制，例如提供Web端管理界⾯，对接企业内部的⽤户认证登录系统， 使⽤Cache缓存令牌，和微服务⽹关对接等。

### 服务容错组件 ###

### 流控和降级 - SpringCloudAlibaba Sentinel ###

随着微服务的流⾏，服务和服务之间的稳定性变得越来越重要。Hystrix其实是⼀个⾮常好 的选择，但是⽐较可惜的是Netflix已经宣布对Hystrix停⽌更新。

Sentinel 以流量为切⼊点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳 定性。

那么Sentinel又有什么样的特征呢？

丰富的应⽤场景： Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景，例如秒 杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填⾕（对于突然到来的⼤量请 求，您可以配置流控规则，以稳定的速度逐步处理这些请求，从⽽避免流量突刺造成系统负 载过⾼）、集群流量控制、实时熔断下游不可⽤应⽤等

完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接⼊应⽤的 单台机器秒级数据，甚⾄ 500 台以下规模的集群的汇总运⾏情况

⼴泛的开源⽣态： Sentinel 提供开箱即⽤的与其它开源框架 / 库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快 速地接⼊ Sentinel

完善的 SPI 扩展点： Sentinel 提供简单易⽤、完善的 SPI 扩展接⼜。您可以通过实现扩展 接⼜来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

![6dfda5ca1373785e834d8b0d964b42db.png][]

### 消息队列 ###

### Kafka / RabbitMQ ###

市⾯上的消息队列也有很多，⽐如阿⾥云的oss，RocketMQ，ZeroMQ，RabbitMQ，Kafka 等，甚⾄Java中的List也可以称为⼀个简单的消息队列，种类如此繁多，我们该如何选择 呢？

没有最好的消息队列，只有最适合的消息队列

现阶段最主流的两⼤消息队列：Kafka和RabbitMQ⼆者有很多相似的地⽅，也都有各⾃的 优势。并且他们都是Spring默认集成的消息队列。

**RabbitMQ**是⼀个开源的消息代理的队列服务器，⽤来通过普通协议在完全不同的应⽤之间 共享数据。

RabbitMQ是使⽤Erlang语⾔来编写的，并且RabbitMQ是基于AMQP协议的。Erlang语⾔在 数据交互⽅⾯性能优秀，有着和原⽣Socket⼀样的延迟，这也是RabbitMQ⾼性能的原因所 在。可谓“⼈如其名”，RabbitMQ像兔⼦⼀样迅速。

**kafka**是⼀个分布式消息队列。具有⾼性能、持久化、多副本备份、横向扩展能⼒。⽣产者 往队列⾥写消息，消费者从队列⾥取消息进⾏业务逻辑。⼀般在架构设计中起到解耦、削 峰、异步处理的作⽤。

kafka对外使⽤topic的概念，⽣产者往topic⾥写消息，消费者从读消息。为了做到⽔平扩 展，⼀个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量 来进⾏横向扩容。单个parition内是保证消息有序。

每新写⼀条消息，kafka就是在对应的⽂件append写，所以性能⾮常⾼。

**Kafka**的适⽤场景：

1.  从A系统到B系统的消息没有复杂的传递规则，并且具有较⾼的吞吐量要求。
2.  需要访问消息的历史记录的场景，因为kafak是持久化消息的，所以可以通过偏移量访问 到那些已经被消费的消息（前提是磁盘空间⾜够，kafka没有将⽇志⽂件删除）
3.  流处理的场景。处理源源不断的流式消息，⽐较典型的是⽇志的例⼦，将系统中源源不断 ⽣成的⽇志发送到kafka中。

**rabbit**的适⽤场景：

1.  需要对消息进⾏更加细粒度的控制，包括⼀些可靠性⽅⾯的特性，⽐如死信队列。
2.  需要多种消费模式（点对点，⼴播，订阅发布等）
3.  消息需要通过复杂的路由到消费者。

### 监控组件 ###

### ⽇志监控ELK ###

ELK：ElasticSearch 、Logstash、Beats、Kibana。是⽇志监控⼀块的标配技术栈。ELK已 经⾮常成熟，基本上是开箱即⽤，后续主要的⼯作在运维、治理和调优。

其有完备的数据分析⼯具

Elastic Stack包括了

*  Kibana ->数据探索和可视化分析
 *  Elasticsearch ->数据存储、查询和分析
 *  Beats Logstash ->数据收集和处理

可⽤于搜索引擎，⽇志分析，指标分析

基本上⽇志的采集，传输和展⽰使⽤ELK就已经⾜够了，现阶段云⼚商的⽇志服务基本上也 是ELK这⼀套东西来实现的。

并且ELK还可以和Kafka配套使⽤，因为⽇志分词操作还是⽐较耗时的，Kafka主要作为前置 缓冲，起到流量消峰作⽤，抵消⽇志流量⾼峰和消费（分词建索引）的不匹配问题。

### 分布式追踪与监控 - Skywalking ###

[Skywalking][] 是由国内开源爱好者吴晟（原OneAPM⼯程师，⽬前在华为）开源并提交到 Apache孵化器的产品，它同时吸收了Zipkin/Pinpoint/CAT的设计思路，⽀持⾮侵⼊式埋 点。是⼀款基于分布式跟踪的应⽤程序性能监控系统。

![45c47f634fd1ca39062e0b49f16e997b.png][]

从这个架构图可以看出来，Sky walking不仅能够进⾏分布式追踪，对请求的路径进⾏全链 路追踪，还可以对Metric指标进⾏统计记录，⽐如做⼀个服务的 TBS 的正确率、成功率、 流量指标统计等。

[60a03fda070fadd99493103f7db0b810.png]: https://img-blog.csdnimg.cn/img_convert/60a03fda070fadd99493103f7db0b810.png
[6dfda5ca1373785e834d8b0d964b42db.png]: https://img-blog.csdnimg.cn/img_convert/6dfda5ca1373785e834d8b0d964b42db.png
[Skywalking]: https://link.zhihu.com/?target=https%3A//github.com/apache/skywalking
[45c47f634fd1ca39062e0b49f16e997b.png]: https://img-blog.csdnimg.cn/img_convert/45c47f634fd1ca39062e0b49f16e997b.png