微服务微服务架构

Posted 2023-03-30 刘婉晴

本文主要大致介绍微服务架构的方式，即对每部分的实现技术

微服务架构方式

1. 外网部署部分

客户端 —— 手机端、网站等

2. 内网部署部分

后台服务集群

请求流程：

请求 —— Nigix 集群 —— 网关 —— 认证中心 —— 服务处理

详细解释：

网关功能： 路由到指定服务器、负载均衡、服务熔断、服务降级、限流等 （Webflux、Ribbon、Sentinel）

认证中心功能: 进行权限判断，是否可以登入 （QAuth2.0）

对整个服务提供：

1. 缓存（Redis）、消息队列(RabbitMQ)、持久化(mysql)、 搜索引擎(ElasticSearch) 、对象存储(OSS)

2. 注册中心(Nacos) 、配置中心(Nacos) 、服务追踪(Sleuth、Zipkin、Metrics等)

3. CI/CD 持续集成和部署（K8s、 Docker）

---

---

业务微服务划分：

商品服务
优惠服务
仓储服务
订单服务
支付服务
用户服务
秒杀服务
检索服务
购物车服务
第三方服务

服务治理：

SpringCloud Alibaba —— Nocas Seata Sentinel
SpringCloud —— Feign Gateway Sleuth Zipkin

数据支撑层：

redis MySQL RabbitMQ elastic OSS

微服务架构总览

参考技术A 微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

什么场景下适用微服务？什么阶段时适用微服务？

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。

网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：

现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；

在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；

微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：

如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。

全链路监控的基本原理都是：

全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。

断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高弹性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。

断路器的三个状态和含义如下：

主流常见的断路器有Hystrix、Sentinel等；

如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：

各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。

如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习。