微服务入门概念

此文章很大部分转载https://www.mrhelloworld.com/,博主均测试通过

 

技术架构演变

下图表示从单体应用逐渐转变为微服务应用。

 

 

 

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

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

  • 开发简单：一个 IDE 就可以快速构建单体应用；

  • 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；

  • 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；

  • 容易部署：整个项目就一个 war 包，Tomcat 安装好之后，应用扔上去就行了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。

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

 

 

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

　　

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

  • 开发成本低，架构简单；

  • 避免单体应用的无限扩大；

  • 系统拆分实现了流量分担，解决了并发问题；

  • 可以针对不同系统进行扩容、优化；

  • 方便水平扩展，负载均衡，容错率提高；

  • 不同的项目可采用不同的技术；

  • 系统间相互独立。

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

 

 

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

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

  • 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
  • 各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
  • 使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。
  • 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
  • 可以针对不同服务的特点制定集群及优化方案；
  • 采用 ESB 减少系统中的接口耦合。
  • 系统与服务的界限模糊，不利于开发及维护。
  • 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
  • 抽取的服务的粒度过大，系统与服务之间耦合性高。
  • 涉及多种中间件，对开发人员技术栈要求高。
  • 服务关系复杂，运维、测试部署困难

 

  • 将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
  • 微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
  • 微服务之间采用 RESTful 等轻量协议传输。
  • 团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
  • 技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
  • 前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
  • 数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
  • 服务拆分粒度更细，有利于资源重复利用，提高开发效率；
  • 一个团队的新成员能够更快投入生产；
  • 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
  • 可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
  • 适用于互联网时代，产品迭代周期更短。
  • 微服务过多，服务治理成本高，不利于系统维护；
  • 分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
  • 微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
  • 多服务运维难度，随着服务的增加，运维的压力也在增大；
  • 测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。

CAP 原则

 

 

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

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

Partition tolerance 中文叫做"分区容错"。 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可 能失败。

　　比如，一台服务器放在本地，另一台服务器放在外地（可能是外省，甚至是外国），这就是两个区，它们之间可能无法通信。

 

 上图中，S1 和 S2 是两台跨区的服务器。S1 向 S2 发送一条消息，S2 可能无法收到。系统设计的时候，必须考虑 到这种情况。 一般来说，分区容错无法避免，

因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做 到。

Consistency Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户 向 S1 发起一个写操作，将其改为 v1。

 

 接下来用户读操作就会得到v1。这就叫一致性。

 

 问题是，用户有可能会向S2发起读取操作，由于G2的值没有发生变化，因此返回的是v0，所以S1和S2的读操作不 一致，这就不满足一致性了

 

 为了让S2的返回值与S1一致，所以我们需要在往S1执行写操作的时候，让S1给S2也发送一条消息，要求也变成 v1

 

 这样子用户向S2发起读操作，就也能得到v1

 

 Availability Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 S1 或 S2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1， 否则就不满足可用性。

Consistency 和 Availability 的矛盾 一致性和可用性，为什么不可能同时成立？

答案很简单，因为可能通信失败（即出现分区容错）。 如果保证 S2 的一致性，那么 S1 必须在写操作时，锁定 S2 的读操作和写操作。

只有数据同步后，才能重新开放读写。锁定期间，S2 不能读写，没有可用性不。 如果保证 S2 的可用性，那么势必不能锁定 S2，所以一致性不成立。 综上所述，S2 无法同时做到一致性和可用性。

系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

  • CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
  • CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
  • AP without C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

eureka对比Zookeeper：

Zookeeper在设计的时候遵循的是CP原则，即一致性,

Zookeeper会出现这样一种情况，当master节点因为网络故 障与其他节点失去联系时剩余节点会重新进行leader选举，

问题在于，选举leader的时间太长：30~120s，且选举 期间整个Zookeeper集群是不可用的，这就导致在选举期间注册服务处于瘫痪状态，

在云部署的环境下，因网络环 境使Zookeeper集群失去master节点是较大概率发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致 长期的服务注册不可用是不能容忍的。

Eureka在设计的时候遵循的是AP原则，即可用性。

Eureka各个节点（服务)是平等的， 没有主从之分，几个节点 down掉不会影响正常工作，剩余的节点（服务） 依然可以提供注册与查询服务，

而Eureka的客户端在向某个 Eureka注册或发现连接失败，则会自动切换到其他节点，

也就是说，只要有一台Eureka还在，就能注册可用（保 证可用性）， 只不过查询到的信息不是最新的（不保证强一致），

除此之外，Eureka还有自我保护机制，如果在 15分钟内超过85%节点都没有正常心跳，那么eureka就认为客户端与注册中心出现了网络故障，此时会出现一下 情况:

1:   Eureka 不再从注册列表中移除因为长时间没有收到心跳而过期的服务。

2：Eureka 仍然能够接收新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点可用）

3： 当网络稳定后，当前实例新的注册信息会被同步到其它节点中

BASE 理论

CAP 理论已经提出好多年了，难道真的没有办法解决这个问题吗？也许可以做些改变。比如 C 不必使用那么强的一致性，可以先将数据存起来，稍后再更新，实现所谓的 “最终一致性”。

这个思路又是一个庞大的问题，同时也引出了第二个理论 BASE 理论。

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

BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

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

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

　　什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

　　软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本数据同步的延时就是软状态的体现。

　　系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。

　　实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制都是需要时间的，这个复制过程中，业务读取到的值就是旧值。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

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

什么是微服务？

微服务就是把原本臃肿的一个项目的所有模块拆分开来并做到互相没有关联，甚至可以不使用同一个数据库。

比如：项目里面有User模块和Power模块，但是User模块和Power模块并没有直接关系，仅仅只是一些数据需要交互，

那么就可以吧这2个模块单独分开来，当user需要调用power的时候，power是一个服务方，但是power需要 调用user的时候，user又是服务方了，

所以，他们并不在乎谁是服务方谁是调用方，他们都是2个独立的服务，这 时候，微服务的概念就出来了。

经典问题:微服务和分布式的区别

谈到区别，我们先简单说一下分布式是什么，

所谓分布式，就是将偌大的系统划分为多个模块（这一点和微服务很像）部署到不同机器上（因为一台机器可能承受不了这么大的压力或者说一台非常好的服务器的成本可能够好几台普通的了），各个模块通过接口进行数据交互，其实分布式也是一种微服务。 因为都是把模块拆分开来变为独立的单元，提供接口来调用，那么 他们本质的区别在哪呢？

他们的区别主要体现在“目标”上， 何为目标，就是你这样架构项目要做到的事情。 分布式的目标是什么？ 我们刚刚也看见了， 就是一台机器承受不了的，或者是成本问 题 ， 不得不使用多台机器来完成服务的部署， 而微服务的目标只是让各个模块拆分开来，不会被互相影响，比如模块的升级亦或是出现BUG等等... 讲了这么多，可以用一句话来理解：分布式也是微服务的一种，而微服务他可以是在一台机器上。

微服务架构带来的问题

　　传统的开发方式，所有的服务都是本地的，客户端可以直接调用，现在按功能拆分成独立的服务，客户端如何访问？

　　后台有 N 个服务，前台就需要管理 N 个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念，另外，N 个服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth2）。

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

  • 提供统一服务入口，聚合接口使得服务对调用者透明，客户端与后端的耦合度降低
  • 聚合后台服务，节省流量，提高性能，提升用户体验
  • 提供安全、流控、过滤、缓存、计费、监控等 API 管理功能

　　因为服务都是独立部署的，所以通信也就成了问题，不过好在业界已经有很多成熟的解决方案，比如：

  • 同步通信：
    • REST（JAX-RS，Spring Boot）
    • RPC（Dubbo，Thrift）
  • 异步通信：
    • RabbitMQ，Kafka

　　在微服务架构中，为了高可用，普遍采用集群方式构建服务。一个服务可能随时下线，也可能应对临时访问压力增加新的服务节点。

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

　　在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

　　雪崩是系统中的蝴蝶效应导致，其发生的原因多种多样，从源头我们无法完全杜绝雪崩的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估做好服务容错。

解决方案大概可以分为以下几种：

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

服务网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

  • 客户端会多次请求不同的微服务，增加了客户端的复杂性
  • 存在跨域请求，在一定场景下处理相对复杂
  • 身份认证问题，每个微服务需要独立身份认证
  • 难以重构，随着项目的迭代，可能需要重新划分微服务
  • 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难

　　针对这些问题，API网关顺势而生。

　　API 网关直面意思是将所有 API 调用统一接入到 API 网关层，由网关层统一接入和输出。

一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。

有了网关之后，各个 API 服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。

 

 

服务治理

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

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

负载均衡

服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务，此时就需要根据不同的负载均衡策略对服务进行调用。

　　实现原理：轮询策略表示每次都顺序取下一个 provider，比如一共有 5 个 provider，第 1 次取第 1 个，第 2 次取第 2 个，第 3 次取第 3 个，以此类推。

　　实现原理：

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

　　实现原理：从 provider 列表中随机选择一个。

　　实现原理：选择正在请求中的并发数最小的 provider，除非这个 provider 在熔断中。

　　实现原理：其实就是轮询策略的增强版，轮询策略服务不可用时不做处理，重试策略服务不可用时会重新尝试集群中的其他节点。

　　实现原理：过滤性能差的 provider

  • 第一种：过滤掉在 Eureka 中处于一直连接失败的 provider。
  • 第二种：过滤掉高并发（繁忙）的 provider。

　　实现原理：

  • 以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的 provider。
  • 如果这个 ip 区域内有一个或多个实例不可达或响应变慢，都会降低该 ip 区域内其他 ip 被选中的权重。

服务容错

在微服务中，一个请求经常会涉及到调用多个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。

最终的结果就是：一个服务不可用，导致一系列服务的不可用。

　　造成雪崩的原因可以归结为以下三点：

  • 服务提供者不可用（硬件故障，程序 BUG，缓存击穿，用户大量请求等）
  • 重试加大流量（用户重试，代码逻辑重试）
  • 服务消费者不可用（同步等待造成的资源耗尽）

　　我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：

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

链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控等等。

单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来。

链路追踪系统做好了，链路数据有了，借助前端解析和渲染工具，可以达到下图中的效果：

配置中心

配置文件是我们再熟悉不过的，在微服务系统中，每个微服务不仅仅只有代码，还需要连接其他资源，例如数据库的配置或功能性的开关 MySQL、Redis 、Security 等相关的配置。

除了项目运行的基础配置之外，还有一些配置是与我们业务有关系的，比如说七牛存储、短信和邮件相关，或者一些业务上的开关。

　　但是随着微服务系统的不断迭代，整个微服务系统可能会成为一个网状结构，这个时候就要考虑整个微服务系统的扩展性、伸缩性、耦合性等等。其中一个很重要的环节就是配置管理的问题。

　　常规配置管理解决方案缺点：

  • 硬编码（需要修改代码、繁琐、风险大）
  • properties 或者 yml（集群环境下需要替换和重启）
  • xml（重新打包和重启）

　　由于常规配置管理有很大的缺点，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的来管理每个服务的配置信息。

安全认证

从单体应用架构到分布式应用架构再到微服务架构，应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化，身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用，

如何保证高效安全的身份认证？面对外部的服务访问，该如何提供细粒度的鉴权方案？

　　David Borsos 在伦敦的微服务大会上提出了四种解决方案：

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

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

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

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

　　在微服务架构下，我们更倾向于 David Borsos 所建议的 JWT 方案，将 OAuth2 和 JWT 结合使用，OAuth2 一般用于第三方接入的场景，管理对外的权限，所以比较适合和 API 网关结合，针对于外部的访问进行鉴权（当然，底层 Token 标准采用 JWT 也是可以的）。

　　JWT 更加轻巧，在微服务之间进行认证&鉴权已然足够，并且可以避免和身份认证服务直接打交道。当然，从能力实现角度来说，类似于分布式 Session 在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。

微服务与Spring-Cloud的关系（区别）

微服务只是一种项目的架构方式，或者说是一种概念，就如同我们的MVC架构一样， 那么Spring-Cloud便是对这 种技术的实现。

微服务一定要使用Spring-Cloud吗？

我们刚刚说过，微服务只是一种项目的架构方式，如果你足够了解微服务是什么概念你就会知道，其实微服务就算不借助任何技术也能实现，只是有很多问题需要我们解决罢了例如：负载均衡，服务的注册与发现，服务调用，路 由。。。。等等等等一系列问题，所以,Spring-Cloud 就出来了，Spring-Cloud将处理这些问题的的技术全部打包好了，就类似那种开袋即食的感觉。。

Spring Cloud 是什么

Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、负载均衡、数据监控等等。

Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分布式系统解决方案。

Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，

它为开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。

Spring Cloud Netflix 第一代

Netflix是一家美国公司，在美国、加拿大提供互联网随选流媒体播放，定制DVD、蓝光光碟在线出租业务。

针对多种 Netflix 组件提供的开发工具包，其中包括 Eureka、Hystrix、Ribbon、Zuul、Archaius 等。

 

  1. Netflix Eureka：一个基于 Rest 服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。
  2. Netflix Hystrix：容错管理工具，实现断路器模式，通过控制服务的节点，从而对延迟和故障提供更强大的容错能力。
  3. Netflix Ribbon：客户端负载均衡的服务调用组件。
  4. Netflix Feign：基于 Ribbon 和 Hystrix 的声明式服务调用组件。
  5. Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。
  6. Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

Spring Cloud Alibaba 第二代

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

  • Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

  • Sentinel：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

  • RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

  • Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

  • Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

  • Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

  • Alibaba Cloud OSS：阿里云对象存储服务（简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

  • Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

  • Alibaba Cloud SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

作为 Spring Cloud 体系下的新实现，Spring Cloud Alibaba 跟官方的组件或其它的第三方实现如 Netflix，Consul，Zookeeper 等对比，具备了更多的功能：

 

 

常用组件

  • Spring Cloud Netflix Eureka：服务注册中心。
  • Spring Cloud Zookeeper：服务注册中心。
  • Spring Cloud Consul：服务注册和配置管理中心。
  • Spring Cloud Netflix Ribbon：客户端负载均衡。
  • Spring Cloud Netflix Hystrix：服务容错保护。
  • Spring Cloud Netflix Feign：声明式服务调用。
  • Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。
  • Spring Cloud Netflix Zuul：API 网关服务，过滤、安全、监控、限流、路由。
  • Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。
  • Spring Cloud Security：安全认证。
  • Spring Cloud Config：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等。
  • Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
  • Spring Cloud Stream：消息驱动微服务。
  • Spring Cloud 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：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

 

 虽然 Eureka，Hystrix 等不再继续开发或维护，但是目前来说不影响使用，不管怎么说感谢开源，向 Netflix 公司的开源致敬。

为什么 Spring Cloud 版本用的是单词而不是数字？

 

 

这样设计的目的是为了更好的管理每个 Spring Cloud 的子项目的清单。避免总版本号与子项目的版本号混淆。

例如：Spring Cloud 2.2.0.RELEASE 的 Spring Cloud Netflix 2.2.2.RELEASE 如果使用这种方式会让开发者混淆版本号。

 

 

发布计划

 

 

子项目版本说明

例如：Spring Cloud Alibaba 2.1.0.RELEASE

  • 2：主版本号。当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
  • 1：次版本号。次版本表示只是局部的一些变动。
  • 0：修改版本号。一般是 bug 的修复或者是小的变动。
  • RELEASE：希腊字母版本号。标注当前版本的软件处于哪个开发阶段。

希腊字母版本说明

  • Base：设计阶段。只有相应的设计没有具体的功能实现。
  • Alpha：软件的初级版本。存在较多的 bug。
  • Bate：表示相对 Alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
  • Gamma：是 Beta 版做过一些修改，成为正式发布的候选版本（Release Candidate）
  • Release：该版本表示最终版。
posted on 2020-06-07 16:59  路仁甲  阅读(573)  评论(0)  编辑  收藏  举报
Powered by:
博客园
Copyright © 2024 路仁甲
Powered by .NET 8.0 on Kubernetes