微服务入门概念

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

 

技术架构演变

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

 

 

1.单一应用架构

 

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

特色

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

优势：

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

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

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

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

缺点：

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

2.垂直应用架构

 

 

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

　　

特色

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

优势

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

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

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

• 能够针对不一样系统进行扩容、优化；

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

• 不一样的项目可采用不一样的技术；

• 系统间相互独立。

缺点

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

3.SOA 面向服务架构

 

 

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

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

特色

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

优势

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

缺点

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

 

4.微服务架构

特色

• 将系统服务层彻底独立出来，并将服务层抽取为一个一个的微服务。
• 微服务中每个服务都对应惟一的业务能力，遵循单一原则。
• 微服务之间采用 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）。

Basically Available（基本可用）

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

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

Soft state（软状态）

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

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

Eventually consistent（最终一致性）

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

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

总结

　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 在伦敦的微服务大会上提出了四种解决方案：

单点登陆（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的关系（区别）

微服务只是一种项目的架构方式，或者说是一种概念，就如同咱们的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：该版本表示最终版。