微服务架构的前世今生

JavacKaka

于 2023-05-08 23:46:39 发布

阅读量182

点赞数

分类专栏： Good article reprint 文章标签：微服务架构 java

原文链接：https://blog.csdn.net/weixin_43995372/article/details/104590900?spm=1001.2014.3001.5502

版权

Good article reprint 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

传统行业向互联网行业的转型

写在开头: 本文转载地址: 哈喽沃德先生的博客微服务架构前世今生

转载地址 : https://blog.csdn.net/weixin_43995372/article/details/104590900?spm=1001.2014.3001.5502

马云说

马云爸爸曾经说过：如果说传统制造业不拥抱互联网的话，那注定是死路一条。

马云曾说道：十五年以前，我在全国各地，至少两三年内讲过两三百次这样的演讲，提醒大家互联网、电子商务对各行各业会有冲击，但是没有人把这个话当回事情，那个时候我是Nobody，讲话等于白讲。但是今天，既然我已经有这样的资源，我还是要告诉大家，未来二三十年这个世界的变化超过所有人的想象力，而且绝大部分人是很倒霉的。今天的传统企业如果依然固步自封，不接受新时代和新的商业模式，势必会被淘汰。

传统行业 VS 互联网行业

互联网发展史

web 1.0

用户只能搜索和阅读网络信息。比如中国的几大门户网站：搜狐、新浪、网易、腾讯，平台提供内容和数据，用户被动接受，和用户缺乏交互。

web 2.0

用户能够创造内容，并分享在网路平台上跟大家进行互动，而不再只是单纯的访问者；这种范式的发展重新定义了市场和商业模式。比如QQ、天涯、微博、淘宝、美团、滴滴，提供一个平台，用户你们自己玩。用户需要注册，用户和平台交互变得很强，用户和用户之间可以交流，数据几乎由用户产生。

web 3.0

网络在接受信息的同时，通过数据分析，能够根绝用户的喜好产生出新的数据和信息并推送给用户。比如网易云音乐的推荐，搜索引擎的推荐，淘宝的商品推荐，地图应用的出行规划，堵车预测等等。其特征是使用 web 2.0 时代所产生的大量数据，更加精准、实时和深入的为用户提供服务。一个简单的例子：当你在淘宝上买了某件商品后，订单下方会出现很多类似商品推送。

小结

比如：你家楼下餐馆代表互联网，你饰演互联网用户。

WEB1.0时代：你晚上一进餐馆，老板给你上了一桌子菜，说兄弟都是你的吃吧！（不分析）你自己挨个尝试，因为你不知道哪个菜好吃。（缺乏交互）
WEB2.0时代：你晚上一进餐馆，你说：老板来斤饺子。老板说：没有饺子有面条。你说来碗面条，老板给你上了一碗面条。（被动分析）或者，你不知道吃什么好，但是坐在你旁边的食客会告诉你哪个好吃。（用户交互）
WEB3.0时代：你晚上一进餐馆，一进门老板就说：客官，来碗面条吧！你问为啥，老板说，你连续吃一礼拜面条了。（主动分析）WEB 3.0 是微服务、大数据、云计算、人工智能的时代

技术架构演变

单一应用架构

通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

特点：

所有的功能集成在一个项目工程中；
所有的功能打一个 war 包部署到服务器；
应用与数据库分开部署；
通过部署应用集群和数据库集群来提高系统的性能。

优点：

开发简单：一个 IDE 就可以快速构建单体应用；
便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；
易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；
容易部署：整个项目就一个 war 包，Tomcat 安装好之后，应用扔上去就行了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定

不足：

妨碍持续交付：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
不够灵活：随着项目的逐渐变大，整个开发流程的时间也会变得很长，即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
受技术栈限制：项目变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
可靠性差：某个环节出现了死循环，导致内存溢出，会影响整个项目挂掉。
伸缩性差：系统的扩容只能针对应用进行扩容，不能做到对某个功能进行扩容，扩容后必然带来资源浪费的问题。
技术债务：假设我的代码库中有一个混乱的模块结构。此时，我需要添加一个新功能。如果这个模块结构清晰，可能我只需要2天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以我需要4天时间。多出来的这两天就是债务利息。随着时间推移、人员变动，技术债务必然也会随之增多。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

特点

以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分成一个一个单体结构项目。
项目与项目之间存在数据冗余，耦合性较大，比如上图中三个项目都存在用户信息。
项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点

开发成本低，架构简单；
避免单体应用的无限扩大；
系统拆分实现了流量分担，解决了并发问题；
可以针对不同系统进行扩容、优化；
方便水平扩展，负载均衡，容错率提高；
不同的项目可采用不同的技术；
系统间相互独立。

缺点

系统之间相互调用，如果某个系统的端口或者 IP 地址发生改变，调用系统需要手动变更；
垂直架构中相同逻辑代码需要不断的复制，不能复用。
系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

SOA 面向服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

tip : Java 编程思想里提到：“所有的软件设计的问题都可以通过增加一个抽象的间接层而得到解决或者得到简化！”ESB 是一个抽象的间接层，提取了服务调用过程中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

特点

基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。

优点

将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
可以针对不同服务的特点制定集群及优化方案；
采用 ESB 减少系统中的接口耦合。

缺点

系统与服务的界限模糊，不利于开发及维护。
虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
抽取的服务的粒度过大，系统与服务之间耦合性高。
涉及多种中间件，对开发人员技术栈要求高。
服务关系复杂，运维、测试部署困难

微服务架构

特点

将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
微服务之间采用 RESTful 等轻量协议传输。

优点

团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
服务拆分粒度更细，有利于资源重复利用，提高开发效率；
一个团队的新成员能够更快投入生产；
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
适用于互联网时代，产品迭代周期更短。

缺点

微服务过多，服务治理成本高，不利于系统维护；
分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
多服务运维难度，随着服务的增加，运维的压力也在增大；
测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。

总结：

一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。

微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。
　　微服务是一种架构风格，架构就是为了解耦，实际使用的是分布式系统开发。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

:::info
**DDD领域驱动设计 : **
在2004年，由Eric Evans提出了， DDD是⾯对软件复杂之道。Domain-Driven- Design–Tackling Complexity in the Heart of Software
⼤泥团：不利于微服务的拆分。⼤泥团结构拆分出来的微服务依然是泥团机构，当服务业务逐渐复杂，这个泥团⼜会膨胀成为⼤泥团。
DDD只是⼀种⽅法论，没有⼀个稳定的技术框架。DDD要求领域是跟技术⽆关、跟存储⽆关、跟通信⽆关。
:::

微服务设计原则

AKF 拆分原则

业界对于可扩展的系统架构设计有一个朴素的理念，就是：通过加机器可以解决容量和可用性问题（如果一台不行就两台）。
　　用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿。
　　《The Art of Scalability》一书提出了一个系统的可扩展模型——AKF 可扩展立方。这个立方体中沿着三个坐标轴设置分别为 X，Y，Z

Y轴：基于不同业务拆分，比如商品管理、订单管理、用户管理等；
X轴：水平复制，通过绝对平等复制服务和数据，解决容量可用性问题
Z轴：基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整

场景说明：比如单体打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。我们可以水平扩展三个服务，形成各自服务的集群模式。实在不行最后根据北上广热门地区划分为多份，你在哪个城市打车，就给你展示哪个城市的司机数据分区。

前后端分离原则

未分离（MVC时代）

该时期代表：Servlet + Jsp + JavaBean

半分离 (SSM/SSH的Java框架时代)

该时期代表：SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts2 + Hibernate）

分离（MVVM）

该时期代表：VueJS、AngularJS、ReactJS
浏览器不再直接请求 JSP 的 API，而是：

浏览器请求服务器端的 NodeJS；
NodeJS 再发起 HTTP 去请求后端；
后端依然原样 API 输出 JSON 给 NodeJS；
NodeJS 收到 JSON 后再渲染出 HTML 页面；
NodeJS 直接将 HTML 页面 flush 到浏览器；
这样，浏览器得到的就是普通的 HTML 页面，而不用再发 Ajax 去请求服务器了。

总结

最后是Nodejs 引领的全栈时代。
前端只需要关注页面的样式与动态数据的解析及渲染，而后端专注于具体业务逻辑。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

Restful 通信风格

基于“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格，因为他有很多好处：

无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案HTTPS 可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

CAP原则和BASE理论

CAP原则

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定理。CAP 三者不可兼得。

特性	定理
Consistency	一致性，也叫做数据原子性，系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。
Availability	可用性，每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是在可以容忍的范围内返回结果，结果可以是成功或者是失败，且不保证获取的数据为最新数据。
Partition
tolerance	分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

总结：

现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在 C 和 A 之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C 必须保证，出现网络故障的话，宁可停止服务，可以在 A 和 P 之间做取舍。而互联网非金融项目普遍都是基于 AP 模式。
　　总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。

BASE

BASE：全称 Basically Available（基本可用），Soft state（软状态），和 Eventually consistent
（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

Basically Available（基本可用）

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）。需要注意的是，基本可用绝不等价于系统不可用。

响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state（软状态）

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
　　软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本数据同步的延时就是软状态的体现。

Eventually consistent（最终一致性）

系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
　　实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制都是需要时间的，这个复制过程中，业务读取到的值就是旧值。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

总结

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

微服务架构带来的问题

客户端访问服务？ API Gateway

一般在后台 N 个服务和客户端之间一般会一个代理（API Gateway），作用如下：

提供统一服务入口，聚合接口使得服务对调用者透明，客户端与后端的耦合度降低
聚合后台服务，节省流量，提高性能，提升用户体验
提供安全、流控、过滤、缓存、计费、监控等 API 管理功能
:::info
微服务在系统内部，通常无状态的\，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth2）。
:::

服务之间通信？

同步通信：
- REST （JAX-RS，Spring Boot）
- RPC （Dubbo，Thrift）
异步通信：
- RabbitMQ , Kafka
  :::info
  总而言之：对外 Rest 对内 RPC 异步 MQ
  :::

服务如何查找？注册中心

服务发现的问题了。基本都是通过类似 ZooKeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZooKeeper（或类似框架），并通过心跳维持长连接，实时更新连接信息。服务调用者通过 ZooKeeper寻址，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZooKeeper 会发通知给服务客户端。

服务挂了怎么办？熔断降级限流

请求缓存：支持将一个请求与返回结果做缓存处理；
请求合并：将相同的请求进行合并然后调用批处理接口；
请求限流：当请求过多时，可能会拖垮整个网站，通常会采取限流措施，降低机器的负载；
服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；
服务熔断：牺牲局部服务，保全整体系统稳定性的措施；
服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值。

微服务架构生态体系

服务网关

API 网关字面意思是将所有 API 调用统一接入到 API 网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短连接支持、容错能力。有了网关之后，各个 API 服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。

服务调用

目前主流的远程调用技术有基于HTTP 的 RESTful 接口和基于 TCP 的 RPC 协议。以上两种都属于同步通信，还有基于队列模式的异步通信

REST（Representational State Transfer）：一种 HTTP 调用的格式，更标准，更通用，无论哪种语言都支持 http 协议。
RPC（Remote Promote Call）：一种进程间通信方式，允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
| 类别 | REST | RPC |
| — | — | — |
| 通讯协议 | HTTP | 一般是 TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 低 |
| 应用 | 微服务架构 | SOA 架构 |

服务治理

服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现

服务注册：服务实例将自身服务信息注册到注册中心。
服务发现：服务实例通过注册中心，获取注册到其中的服务实例的信息，通过这些信息请求它们提供的服务。
服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

负载均衡

轮询：每次都顺序取下一个 provider，
权重轮询
随机 : 从 provider 列表中随机选择一个。
最少并发数：实现原理：选择正在请求中的并发数最小的 provider，除非这个 provider 在熔断中
重试策略：轮询策略服务不可用时不做处理，重试策略服务不可用时会重新尝试集群中的其他节点
可用性敏感：过滤性能差的 provider （①Eureka一直连接失败的，②高并发繁忙的）
区域敏感性：以区域考察可用性，丢弃整个不可用区域，从剩余区域选p
:::info
权重轮询实现原理：

根据每个 provider 的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
原理：一开始为轮询策略，并开启一个计时器，每 30 秒收集一次每个 provider 的平均响应时间，当信息足够时，给每个 provider 附上一个权重，并按权重随机选择 provider，高权越重的provider 会被高概率选中。
:::

服务容错

避免问题：一个服务不可用，导致一系列服务不可用
服务容错的核心思想是：

不被外界环境影响
不被上游请求压垮
不被下游响应拖垮

链路追踪

对一次请求涉及的多个服务链路进行日志记录，性能监控等等。单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来，
链路追踪系统做好了，链路数据有了，借助前端解析和渲染工具，可以达到下图中的效果：

配置中心

微服务不仅有代码，还要连接其他资源，（redis,MySQL等相关配置），可能成为一个网状结构，考虑扩展性，伸缩性，耦合性等
采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的来管理每个服务的配置信息。

安全认证

单点登录（SSO）

这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，随着微服务应用的增多，这种方案的弊端会更加明显。

分布式 Session 方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 Key来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全连接来访问，这时解决方案的实现就通常具有相当高的复杂性了。

客户端 Token 方案

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，David Borsos 更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。

客户端 Token 与 API 网关结合

这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。

总结

在微服务架构，我们更倾向于 David Borsos 所建议的 JWT 方案，将 OAuth2 和 JWT 结合使用，OAuth2 一般用于第三方接入的场景，管理对外的权限，所以比较适合和 API 网关结合，针对于外部的访问进行鉴权（当然，底层 Token 标准采用 JWT 也是可以的）。
　　JWT 更加轻巧，在微服务之间进行认证&鉴权已然足够，并且可以避免和身份认证服务直接打交道。当然，从能力实现角度来说，类似于分布式 Session 在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。

微服务架构技术支持

Spring Cloud

Netflix Eureka ：服务注册中心。
Zookeeper ：服务注册中心
Consul ：服务注册和配置管理中心。
Netflix Ribbon ：客户端负载均衡。
Netflix Hystrix ：服务容错保护 / 服务熔断
Netflix Feign / OpenFeign ：声明式服务调用 RPC调用
OpenFeign(可替代 Feign) ：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析SpringMVC 的 @RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。
Netflix Zuul ：API 网关服务，过滤、安全、监控、限流、路由
Gateway(可替代 Zuul) ：Spring Cloud Gateway 是 Spring 官方基于 Spring5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。
Security ：安全认证。
Config ：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等。
Bus ：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
Stream ：消息驱动微服务。
Sleuth ：分布式服务跟踪。
Spring Cloud Alibaba Nacos ：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Spring Cloud Alibaba Sentinel ：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Spring Cloud Alibaba RocketMQ ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Spring Cloud Alibaba Dubbo ：Apache Dubbo™ 是一款高性能 Java RPC 框架，用于实现服务通信。
Spring Cloud Alibaba Seata ：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Spring Cloud Alibaba OSS ：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Spring Cloud Alibaba SchedulerX ：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
Spring Cloud Alibaba SMS ：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

ELSE

**RibbitMQ **：RabbitMQ 是部署最广泛的开源消息中间件。是实现了高级消息队列协议（AMQP）的开源消息中间件。
Kafka ：Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统。
Redis ：Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。
MongoDB ：MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。
**Elasticsearch **：Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是最受欢迎的企业搜索引擎，其次是 Apache Solr，基于 Lucene。
MySQL ：MySQL 是一种开放源码的关系型数据库管理系统（RDBMS），免费、简单、占资源少、强大好用。
Oracle ：世界上最昂贵的数据库，一般金融系统使用居多。
FastDFS ：FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
HDFS ：Hadoop 生态组件，可以支持千万级的大型分布式文件系统。
**XX-JOB **：轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
TX-LCN ：分布式事务解决防范，LCN 并不生产事务，LCN 只是本地事务的搬用工（事务的协调工）。LCN 是一个高性能的分布式事务框架，兼容 Dubbo、Spring Cloud，支持 RPC 框架拓展，支持各种 ORM 框架、NoSQL、负载均衡、事务补偿。
Zipkin ：Twitter 公司开发贡献一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，其主要功能是聚集各个异构系统的实时监控数据。
Skywalking ：Apache Skywalking 是一个开源的，用于收集、分析，聚合，可视化来自于不同服务和本地基础服务的数据的可观察的平台。特别为分布式系统而设计的数据观察和监控系统。
Apollo ：携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
ConfigKeeper ：随行付架构部基于 Spring Cloud 研发的分布式配置中心。与 Spring Boot、Spring Cloud 应用无缝兼容。
JWT ：JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。
**Nginx **：Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强，中国大陆使用 Nginx 网站用户有：百度、淘宝、腾讯、京东、新浪、网易等。
**Git **：开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。
**Docker **：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
Kubernetes ：Kubernetes，简称 k8s，是用 8 代替 8 个字符“ubernete”而成的缩写。
Kubernetes 脱胎于 Google 的 Borg 系统，是一个开源的功能强大的容器编排系统，用于管理云平台中多个主机上的容器化的应用，实现了容器集群的自动化部署、扩容以及运维的开源平台。Kubernetes 的目标是让部署容器化的应用简单并且高效。