什么是微服务，它有哪些优缺点，微服务中的代码框架spring cloud

什么是微服务，它为什么如此受欢迎？
首先从最基本的开始了解。下图是一个假想的视频共享平台的实现方式，左侧是传统的整体式架构（单个巨型单元），右侧则是微服务：

两种模式的区别在于第一种是整体式架构，只有一个大单元。第二种则由多个小单元构成，每个小单元都是独立的服务。上图已足够细致，从中很容易找到微服务模式的吸引力所在。

微服务架构的具体好处？
独立开发： 小型的独立组件可由小型的独立团队构建。一个小组可以专门负责开发“Upload”服务，不用去管其他服务。每个组件的功能变得简单，这样一来，开发人员了解组件的时间大大减少，更容易开发新功能。
独立部署： 每个单独的组件都可以独立部署。这样一来发布新功能的速度就更快，风险也更小。假设“Streaming”组件修复了 bug 或者新增了功能，那么部署时并不会影响其他组件。
独立扩展： 每个组件可以独立地进行扩展。在新节目刚发布的繁忙时期，可以扩展“Download”组件，以支持增加的负载，而不必扩展所有组件，这样一来扩展更具弹性并且降低了成本。
可重用性： 每个组件各自实现一个小的、特定的功能。这意味着它们可以很容易地适用于其他系统、服务或者产品。“Transcode”组件可以被其他业务单元使用，甚至可以改写成一个新的业务，从而为其他组提供转码服务。
从以上细节层面可见，微服务模式相比整体式架构的好处显而易见。

Spring Cloud是什么鬼？
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，springcloud就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，springcloud做为大管家需要管理好这些微服务，自然需要很多小弟来帮忙。
核心成员
Spring Cloud Netflix
这可是个大boss，地位仅次于老大，老大各项服务依赖与它，与各种Netflix OSS组件集成，组成微服务的核心，它的小弟主要有Eureka, Hystrix, Zuul, Archaius… 太多了
Netflix Eureka
服务中心，云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。这个可是springcloud最牛鼻的小弟，服务中心，任何小弟需要其它小弟支持什么都需要从这里来拿，同样的你有什么独门武功的都赶紧过报道，方便以后其它小弟来调用；它的好处是你不需要直接找各种什么小弟支持，只需要到服务中心来领取，也不需要知道提供支持的其它小弟在哪里，还是几个小弟来支持的，反正拿来用就行，服务中心来保证稳定性和质量。
Netflix Hystrix
熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。比如突然某个小弟生病了，但是你还需要它的支持，然后调用之后它半天没有响应，你却不知道，一直在等等这个响应；有可能别的小弟也正在调用你的武功绝技，那么当请求多之后，就会发生严重的阻塞影响老大的整体计划。这个时候Hystrix就派上用场了，当Hystrix发现某个小弟不在状态不稳定立马马上让它下线，让其它小弟来顶上来，或者给你说不用等了这个小弟今天肯定不行，该干嘛赶紧干嘛去别在这排队了。
Netflix Zuul
Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。当其它门派来找大哥办事的时候一定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者是需要找那个小弟的直接给带过去。
Netflix Archaius
配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。可以实现动态获取配置， 原理是每隔60s（默认，可配置）从配置源读取一次内容，这样修改了配置文件后不需要重启服务就可以使修改后的内容生效，前提使用archaius的API来读取。
Spring Cloud Config
俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。就是以后大家武器、枪火什么的东西都集中放到一起，别随便自己带，方便以后统一管理、升级装备。
Spring Cloud Bus
事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。相当于水浒传中日行八百里的神行太保戴宗，确保各个小弟之间消息保持畅通。
Spring Cloud for Cloud Foundry
Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题
其实就是与CloudFoundry进行集成的一套解决方案，抱了Cloud Foundry的大腿。
Spring Cloud Cluster
Spring Cloud Cluster将取代Spring Integration。提供在分布式系统中的集群所需要的基础功能支持，如：选举、集群的状态一致性、全局锁、tokens等常见状态模式的抽象和实现。如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。
Spring Cloud Consul
Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对.
Spring Cloud Consul 封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
其它小弟
Spring Cloud Security
基于spring security的安全工具包，为你的应用程序添加安全控制。这个小弟很牛鼻专门负责整个帮派的安全问题，设置不同的门派访问特定的资源，不能把秘籍葵花宝典泄漏了。
Spring Cloud Sleuth
日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。
Spring Cloud Data Flow
Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL，批量运算和持续运算的统一编程模型和托管服务。
对于在现代运行环境中可组合的微服务程序来说，Spring Cloud data flow是一个原生云可编配的服务。使用Spring Cloud data flow，开发者可以为像数据抽取，实时分析，和数据导入/导出这种常见用例创建和编配数据通道 （data pipelines）。
Spring Cloud data flow 是基于原生云对 spring XD的重新设计，该项目目标是简化大数据应用的开发。Spring XD 的流处理和批处理模块的重构分别是基于 Spring Boot的stream 和 task/batch 的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等现代运行环境。
Spring Cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。
Spring Cloud Stream
Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于Spring Boot创建，用来建立单独的／工业级spring应用，使用spring integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了
Spring Cloud Task
Spring Cloud Task 主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。
Spring Cloud Zookeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理，抱了Zookeeper的大腿。
Spring Cloud Connectors
Spring Cloud Connectors 简化了连接到服务的过程和从云平台获取操作的过程，有很强的扩展性，可以利用Spring Cloud Connectors来构建你自己的云平台。便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。
Spring Cloud Starters
Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。
Spring Cloud CLI
基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

和Spring Boot 是什么关系?
Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现,可以不基于Spring Boot吗？不可以。
Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖的关系。即spring -> spring boot > Spring Cloud 这样的关系。

微服务有什么问题？
微服务模式优点多多，那么它的缺点是什么呢？据我所知它主要有下列问题。

开发的复杂性增加
对于开发者来说事情会变得更加困难。当开发人员开发一个新功能时，如果该功能依赖其他服务的话，那么开发人员不得不在他们的机器上运行所有服务，或者连接到这些服务。这通常比简单地运行单个程序更加复杂。
这个问题可以通过一些工具得到部分缓解，但随着构成系统的服务数量的增加，开发人员在整个系统运行时面临的挑战也越来越多。
运营的复杂性增加
对于维护服务的团队来说，潜在的复杂性是一个巨大的挑战。他们管理的服务不是简单的几个，而是数十、数百甚至数千个正在运行的服务。服务数量越多，通信链路就越多，那么出错的可能性就会变大。
devops 的复杂性增加
以上两点表示开发和运营是分开进行的，随着 devops 的普及（我是 devops 的忠实粉丝），devops 能够缓解这个问题吗？
如今有许多组织仍然依靠独立的开发和运营团队来工作，而也有一些组织更倾向于采用微服务。
对于已经采用了devops 的组织来说，这仍然很难。既是开发者又是运营者已经非常艰难（但是要建立好的软件却很关键）了，还得了解集群容器系统的细微差别，特别是快速发展的系统，那就更困难了。
它需要资深专家
如果开发团队成员都是专家级别，那么结果可能会很好。但想象一下，一个使用单一的整体式系统运行的不是很顺畅。如果增加系统的数量，就会增加运行的复杂性。
通过有效的自动化、监控和集群等技术可以做到。但瓶颈很少在于技术本身，而在于找到能够有效使用这些技术的人。目前这些技能需求非常高，可能很难找到。
真实世界的系统往往界限不清
当我们描述微服务的好处时，经常谈到独立的组件。但是在很多情况下，组件并不是独立的。在论文中，某些领域可能看起来有限，但是当你深入细节时，你会发现他们比你预期的更具挑战性。
事情变得非常复杂。如果你的界限没有明确的定义，那么即使理论上的服务可以单独部署，你也会发现，由于服务之间的相互依存关系，你必须部署一组服务。
这意味着你需要一系列管理协同工作的服务版本，这些服务版本之间的协作需要通过验证和测试，你实际上没有可独立部署的系统，为了部署新功能，你需要仔细编排并同时部署许多服务。
状态的复杂性往往被忽略
在前面的例子中，我提到一个功能的部署可能需要同时部署多个版本的多个服务。假设合理的部署技术可以缓解这种情况，例如 blue/green 部署（大多数服务编排平台可轻松应对），或者并行运行的多个服务版本，以及决定使用哪个版本的通道。
如果服务是无状态的，这些技术可以缓解大量的挑战。但是无状态服务非常容易处理。事实上，如果你有无状态的服务，那么我会倾向于考虑跳过微服务，而考虑使用无服务器模型。
实际上，大多数服务都需要状态。比如我们的视频共享平台例子中的订阅服务。新版的订阅服务可以用新的形式将数据存储在订阅数据库中。如果你并行运行两个服务，则一次运行了两个模式的系统。如果你进行了 blue green 部署，而其他服务依赖于新的数据，那么必须同时更新这些服务，如果订阅服务部署失败并回滚，则需要层级回滚。
你可能会认为在 NoSQL 数据库中这些问题不存在，但事实并非如此。不强制执行模式的数据库并不意味着它是无模式系统 - 它仅仅意味着模式在应用级而不是数据库级进行管理。理解数据的形状及其演变过程的挑战依然存在。
通信的复杂性往往被忽略
当你建立一个相互依赖的大型网络服务时，可能会涉及到很多服务间的通信，挑战随之而来。首先，潜在的失败无处不在。假设网络调用失败了，那么当一个服务调用另一个服务失败时，它至少应当重试几次。服务之间的调用关系越多，那么情况将变得愈加复杂。
假设用户上传视频到共享服务中。那么我们需要运行上传服务，然后将数据传递到转码服务，此外，还得更新订阅和推荐服务。所有这些调用都需要一定程度的协调，如果失败，就得重试。而重试逻辑可能很难管理。同步运行往往不是很稳定，很容易失败。在这种情况下，更可靠的解决方案是使用异步模式来处理通信。此处面临的挑战是异步模式会使系统具有状态性。如前所述，分布式系统和状态系统很难处理。
当一个微服务系统使用消息队列进行服务内通信时，基本上会有一个大的数据库（消息队列或代理）将这些服务粘合在一起。虽然起初看起来似乎没什么问题，但模式始终是一个隐患。新版本的服务可能会写入新的格式的消息，当发送服务更改发送消息的详细信息时，依赖于该消息的服务也需要更新。
当然可以拥有多个不同格式的消息处理服务，但数量一多就很难管理。当部署一个新版本的服务时，两个不同版本的服务可能会处理来自同一队列的消息，尽管消息来自不同版本的发送服务。这可能会导致复杂的边缘情况。为了避免这些边缘情况的产生，最好是只允许特定版本的消息存在，这意味着你需要将一组服务的版本作为一个整体来部署，以确保先前版本的消息被适当地排除。
这再次表明，当你深入细节时会发现独立部署的想法可能与预期的有所差异。
版本控制变难
为了缓解前面提到的问题，我们需要谨慎管理版本。遵循像 semver 这样的标准能够解决这个问题吗？答案是否定的。Semver 是一个利器，但是你仍然需要跟踪协同工作的服务和 API 的版本。
这件事颇具挑战，你可能自己都搞混，不知道哪个版本的服务可以一起正常工作。
在软件系统中管理依赖关系是非常困难的，无论是节点模块、Java 模块、C 库还是其他东西。独立组件和单一整体之间的冲突很难处理。
当依赖关系是静态，并且能够进行修补、更新、编辑的时候，挑战在所难免。但是如果依赖关系本身是实时服务，那么你可能无法仅仅更新它们 - 你可能需要运行许多版本，或者直到整个系统得到修复。
分布式事务
在需要跨操作交易完整性的情况下，微服务可能会非常痛苦。分布式状态很难处理，很多小的失败单元可能会很难进行集群操作。
可以通过操作幂等性、重试机制等方法来避免这个问题，这些手段在许多情况下能够起作用。但有些情况你需要保证操作的事务性，要么成功，要么失败，而不能处于失败和成功的中间状态。在微服务模型中想要解决这个问题或者实现事务难度是很大的。
微服务可能是一种变相的整体式模型
单独的服务和组件可以独立部署，但是在大多数情况下，你将不得不运行某种集群平台，比如 Kubernetes。如果你使用谷歌的 GKE 或者亚马逊的 EKS 这样的托管服务，它们会帮你完成复杂的集群管理。
但是，如果你自己管理集群的话，那么面对的是一个庞大而复杂的系统。虽然单个服务拥有前文提到的大量优点，但是你依然需要非常小心。这个系统的部署、更新、故障转移等等操作起来都不是那么简单。
在大多数情况下，优点能够得到体现，但是任然不要轻视或低估管理一个庞大而复杂的系统的难度。托管服务可能会有所帮助，但这些服务大都刚刚新起（例如，亚马逊的 EKS 在2017年底才发布）。

微服务的狂热将开始降温
仔细考虑避免加入对微服务的狂热追捧。为了帮助解决这个问题，我已经注意到了一些你可能想问自己的问题，并列举了问题的答案：

点击下载 PDF 版本：microservice-questions.pdf（https://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf）。

不要把微服务和架构混淆
没有微服务架构一说。微服务只是组件的另一种模式或实现。不论微服务是否在系统中使用，它都与架构无关。
微服务在许多方面与打包和操作的技术过程有关，而与系统设计无关。组件边界仍然是工程系统中最重要的挑战之一。
无论你的服务体量有多大，是否在 Docker 容器中，你都需要仔细考虑如何将系统放在一起。这里没有标准答案，只是多一个选择而已。

参考文章：
1.springcloud(一)：大话Spring Cloud
2.2018 疯狂微服务之死