2021 年最新基于 Spring Cloud 的微服务架构分析，java 技术经理岗位职责
构建在开发团队之外的 API 网关必须具备负载均衡能力，可以配置多个 IP 地址。通过该 API 网关也最好具备和 Docker 容器扩展后的服务自动注册和地址加入扩展能力。
Eureka 的竞品分析：Nacos、ZooKeeper、Etcd
=================================
服务发现是一个古老的话题，当应用开始脱离单机运行和访问时，服务发现就诞生了。目前的网络架构是每个主机都有一个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。DNS 协议是最早将一个网络名称翻译为网络 IP 的协议，在最初的架构选型中，DNS+LVS+Nginx 基本可以满足所有的 RESTful 服务的发现，此时服务的 IP 列表通常配置在 Nginx 或者 LVS。后来出现了 RPC 服务，服务的上下线更加频繁，人们开始寻求一种能够支持动态上下线并且推送 IP 列表变化的注册中心产品。
Eureka
======
Spring Cloud Eureka 所选择的是 AP，采用的是去中心化结构，放弃了强一致性。也就是说 Eureka 集群中的各个结点都是平等的，没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个 Eureka Server 结点挂掉了，还有其他同等的结点来提供服务，并不会引发服务的中断
Eureka 只能当注册中心，想搞配置中心的话，还得搭配 Spring Cloud Config+Spring Cloud Bus。其中后者支持 Rabbiimq 和 Kafka 两种模式。
使用 Java 语言来开发的，并且也是 Spring Cloud 的子项目，所以可以直接通过引入 jar 包的方式来集成 Eureka，这点非常方便
1. ZooKeeper
=============
这是一款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长一段时间里，它是国人在提起 RPC 服务注册中心时心里想到的唯一选择，这很大程度上与 Dubbo 在中国的普及程度有关。
Apache Zookeeper 所选择的是 CP，也就是放弃了高可用性。Zookeeper 集群在进行消息同步的时候，必须有一半以上结点完成了同步才会返回；而当 Master 结点挂了或者集群中有过半的结点不能工作了，此时就会触发故障恢复，重新进行 Master 选举。在这个过程中，整个 Zookeeper 集群无法对外提供服务，从而实去了 A（可用性）
为了达到 C，Zookeeper 采用的是自己的 ZAB 协议。
2. Nacos
=========
Nacos 是阿里巴巴旗下的开源项目，在 2018 年开源，携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户一个新的选择。
Nacos 一大特性是即支持 CP，也支持 AP。可以根据需要灵活选择。
Nacos 除了注册中心之外，也能充当配置中心的作用。且配置中心可以按照 namespace，group 等维度来进行数据隔离，来达到不同环境之间配置隔离的功能。
值得一提的是，Nacos 作为配置中心的持久化机制可以依赖于 Mysql 来完成（默认依赖于内置数据库）。只需要将 Nacos 目录下的 sql 脚本放到 mysql 中执行（会生成 11 个表），然后在 nacos 配置文件里面配一下 mysql 的账号密码即可。这样使用 mysql 作为数据源的方式相比于 nacos 内置数据库来说更容易管理
3. Consul
==========
Consul 是 HashiCorp 公司推出的一个开源工具。
Consul 是用 Go 语言编写的，所以无法像 Eureka 那样直接引入 jar 包就能集成，它还需要去服务器中进行额外的安装。
除了注册中心的功能之外，Consul 还能起到配置中心的作用。
Consul 它保证的是 CP，使用 raft 协议，要求必须有过半的结点都写入成功才算是注册成功了，并且它也有 Master 和 Follower 的概念，在 Master 挂掉后，也需要自己内部进行
4. Etcd（待续）
============
对比 SpringCloud，Kubernetes 也提供完整的分布式微服务管理框架，几乎所有组件都有对应的产品，其中 Etcd 也可以提供类似 Eureka 的注册中心。
在 Go 生态中，还可以选择基于 Etcd 作为注册中心，Etcd 是由 CoreOS 团队维护的、高可用分布式键值存储数据库，可用于为集群提供配置和服务发现功能，Google 开源的容器管理工具 Kuberbetes 就是基于 Etcd 的。
和 Consul 一样，Etcd 也是基于 Raft 协议作为分布式一致性算法来解决领导者选举和日志复制问题，同样也是基于 Go 语言编写。
Etcd 也支持代理模式（proxy），只不过在 Etcd 中，代理模式和 Consul 的客户端代理模式类似，安装在部署服务的节点上，用来转发请求到 Etcd 集群，本身不存储任何数据，Etcd 集群相当于 Consul 中以服务端模式运行的 Consul 集群，通常要求配置三个及以上节点（不要太多，3~5 就够了，以便可用性和性能上达到平衡），负责真正的请求处理 —— 服务注册与发现。
在目前最新版本的 Etcd v3 中，通过网关模式（gateway）取代了 V2 版本中的代理模式（proxy）。
从服务发现的实现原理上来说，Consul 和 Etcd 的基本设计思路是一致的，Etcd 更简单，Consul 则更像一个全栈的解决方案，功能比 Etcd 要更丰富，比如支持可视化的 Web UI 管理界面、支持多数据库中心、安全层面除了 HTTPS 外还支持 ACL、更加全面的健康检查功能、内置 DNS Server 等，这些都是 Etcd 所不具备的，但是更全面的功能往往意味着更高的复杂性，针对微服务的服务注册和发现场景，Etcd 完全够用了。
Spring Cloud 全家桶的简介
===================
Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。
Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Zuul：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Consul：封装了 Consul 操作，Consul 是一个服务发现与配置工具，与 Docker 容器可以无缝集成。
Spring Cloud for Cloud Foundry：通过 Oauth2 协议绑定服务到 CloudFoundry，CloudFoundry 是 VMware 推出的开源 PaaS 云平台。
Spring Cloud Sleuth：日志收集工具包，封装了 Dapper 和 log-based 追踪以及 Zipkin 和 HTrace 操作，为 Spring Cloud 应用实现了一种分布式追踪解决方案。
Spring Cloud Data Flow：大数据操作工具，作为 Spring XD 的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。
Spring Cloud Security：基于 Spring Security 的安全工具包，为你的应用程序添加安全控制。
Spring Cloud Zookeeper：操作 Zookeeper
的工具包，用于使用 Zookeeper 方式的服务发现和配置管理。
Spring Cloud Stream：数据流操作开发包，封装了与 Redis、Rabbit、Kafka 等发送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
Turbine：Turbine 是聚合服务器发送事件流数据的一个工具，用来监控集群下 Hystrix 的 Metrics 情况。
Feign：Feign 是一种声明式、模板化的 HTTP 客户端。
Spring Cloud Task：提供云端计划任务管理、任务调度。
Spring Cloud Connectors：便于云端应用程序在各种 PaaS 平台连接到后端，如：数据库和消息代理服务。
Spring Cloud Cluster：提供 Leadership 选举，如：Zookeeper，Redis，Hazelcast，Consul 等常见状态模式的抽象和实现。
Spring Cloud Starters：Spring Boot 式的启动项目，为 Spring Cloud 提供开箱即用的依赖管理。
本书适合具有一定 Java 基础和 Spring MVC 基础的人群以及希望往架构师方向发展的开发者阅读。
书籍教程结构
======
本书共分四部分，从基础到实战，讲解了基于 Spring Cloud 的常用组件。
第一部分(基础篇):第 1~4 章
第二部分(实战篇):第 5~10 章
第三部分(高级篇):第 11~13 章
第四部分(部署篇):第 14~15 章
第一部分(基础篇)
=========
第 1 章微服务概述
我们要学习微服务架构，就要了解它，本章将带领大家初步了解微服务，为后面系统学习微服务架构奠定良好的基础。
第 2 章 Spring Boot 基础
本书以实战为导向，讲解了如何使用 Spring Cloud 开发微服务项目，而 Spring Cloud 基于 SpringBoot,所以本章先来初步了解如何使用 Spring Boot 搭建框架。
第 3 章 Spring Boot 核心原理
通过第 2 章的学习，读者应该对 Spring Boot 有了一个大致的认识，利用 Spring Boot 可以极大地简化应用程序的开发，这都归功于 Spring Boot 的四大核心原理:起步依赖、自动配置、Actuator 和 Spring Boot 命令行。本章中，我们将深入探讨 Spring Boot 的核心原理，以便读者能更好地学习和使用 Spring Boot。
第 4 章 Spring Cloud 概述
从本章开始，我们将正式踏上探索 Spring Cloud 秘密的旅程。学完本书后，读者将学会搭建一个完整的分布式架构，从而向架构师的目标靠近。
第二部分(实战篇)
=========
SpringCloud 实战演练文档 K8S+实战+笔记+项目教程转发+评论，关注我私信回复"笔记"即可免费获取
第 5 章 项目准备阶段
本章中，我 将开始 个大型实战项目一一博客网站。通过“以战代练”的方式来学习如何构建 Spring loud 微服务架构，让读者走出理论的丛林，在实践中玩转微服务架构。
第 6 章 公共模块封装
从本章开始，我们将学习框架的搭建。由于代码量巨大，本书不可能全部贴出，所以只展示一些核心代码。全部源码可以从本书配套源码中查看。
第 7 章 注册中心: Spring Cloud Netflix Eureka
通过前面的学习，我们可以总结出来，注册中心是整套微服务架构的核心，即系统的心脏，它能够帮助我们管理所有的微服务，精确定位到具体的服务就是通过注册中心来实现的。构建注册中心的好处也是不言而喻的，通过注册中心，我们可以实现服务的负载均衡。配置的统-管理。服务间的通信等。目前。我们可以采用多种技术实现注册中心，如 Eureka. ZooKeeper. Consul 等，本书采用 SpringCloud 默认集成的 Eureka 框架来构建注册中心。
第 8 章 配置中心: Spring Cloud Config
我们知道，一个微服务系统可能由成千上万的服务组成，每个服务都会有自己的配置，不同服务之间的有些配置是相同的，比如数据库。如果对于每个服务，我们都复制相同的配置，一旦该配置发生了变化，那么每个服务都需要修改，代价可想而知。Spring Cloud 已经考虑到了这一点, 它为我们提供了一整套解决方案， 那就是强大的 Spring CloudConfig。
第 9 章 服务网关: Spring Cloud Gateway
本将介绍的微服务的又一大组件一一服务网关。我们需要服务网关，还有一些很重要的因素，比如服务网关会对接口进行统一拦截并做合法性校验，一个服务可以启动多个端口，利用服务网关进行负载均衡处理等。目前市面上有很多产品可以实现服务网关这一功能， 如 Nginx. Apache. Zuul 以及 Spring CloudGateway 等。Spring Cloud 集成了 Zuul 和 Gateway,我们可以很方便地实现服务网关这一功能。
第 10 章 功能开发
通过前几章的学习，我们已经搭建好了博客网站的基本框架。本章我们将正式开始网站的功能开发。
第三部分(高级篇)
=========
SpringCloud 实战演练文档 K8S+实战+笔记+项目教程转发+评论，关注我私信回复"笔记"即可免费获取
第 11 章 服务间通信: Spring Cloud Netflix Ribbon 和 Spring Cloud OpenFeign
一个大型的 系统由多个微服务模块组成，我们一-般 可以通过内部接口调用的形式(服务 A 提供一个接口，服务 B 通过 HTTP 请求调用服务 A 的接口)实现各模块之间的通信。为了简化开发，SpringCloud 集成了 Spring Cloud Netlix Ribbon 和 Spring Cloud OpenFeign,两个组件都支持通过 HTTP 请求不同的服务。本书将简要介绍 Spring Cloud Netflix Ribbon,借此引出 Sping Cloud OpenFeign,并详细介绍其用法。
第 12 章 服务链路追踪: Spring Cloud Sleuth
我们知道,微服务之间通过网络进行通信,但在我们提供服务的同时,不能保证网络一定是畅通的。相反地，网络是很脆弱的，网络资源也有限，因此我们有必要追踪每个网络请求，了解它们经过了哪些微服务，延迟多少，每个请求所耗费的时间等。只有这样才能更好地分析系统瓶颈，解决系统问题。在 Spring Cloud 中，我们可以使用 Spring Cloud Sleuth 组件来实现微服务追踪。
第 13 章 服务治理: Spring Cloud Consul 和 Spring Cloud ZooKeeper
在前面的章节中，读者已经接触到了 Spring Cloud 默认集成的服务治理框架 Spring Cloud NettlixEureka。在本章，我们将接触到新的服务治理框架，以便读者在实际应用中有多种选择。
第四部分(部署篇)
=========
第 14 章系统发布上线
通过前几章的学习，我们顺利完成了应用的开发，仅仅完成框架搭建和功能开发是不够的，我们还需要将应用发布到服务器上供客户端访问。本章中，我们将开始详解应用的发布。
第 15 章使用 Kubernetes 部署分布式集群容器技术的出现带给了我们新的思路。我们可以将服务打包成镜像，放到容器中，通过容器来运行服务，这样可以很方便地进行分布式管理，同样的服务也可以很方便地进行水平扩展。Docker 是容器技术方面的佼佼者，它是一-个开源容器，而 Kubernetes (以下简称 K8S)是一个分布式集群方案的平台，它和 Docker 就是天生的一对。 通过 K8S 和 Docker 的配合，我们很容易搭建分布式集群环境。下面，我们就来看一下 Docker 和 K8S 的诱人之处。
评论