微服务(Microservice)Spring Cloud Alibaba
Spring Boot 是 Pivotal 团队在 Spring 的基础上提供的一套全新的开源框架，其目的是为了简化 Spring 应用的搭建和开发过程。Spring Boot 去除了大量的 XML 配置文件，简化了复杂的依赖管理。
随着近些年来微服务技术的流行，Spring Boot 也成了时下炙手可热的技术。Spring Boot 具有 Spring 一切优秀特性，用于构建独立的生产就绪Spring应用，用于创建微服务。
微服务（Microservice）是什么？
微服务(Micro Service)是一种允许开发人员独立开发和部署服务的体系结构。每个运行的服务都有自己的流程，这实现了轻量级模型以支持业务应用程序。
微服务是商业应用程序开发中最热门的新事物。微服务这个词取代了敏捷、DevOps和RESTful，成为了所有简历和大会演讲中都必须提及的新热门词。
微服务这一概念出现于2012年，因敏捷开发方法创始人之一的Martin Fowler而流行，微服务架构是一项在云中部署应用和服务的新技术。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通。”关键在于该服务可以在极致的程序中运行。
微服务作为一项云中部署应用和服务的新技术，已成为当下最新的热门话题。大部分为稍微服务的争论都集中在容器或其他技术是否能够很好地实施微服务。企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和拓展。
架构的不同风格
单体架构Monolithic
早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。
互联网早期，一般的网站应用流量较小，只需要一个应用，将所有的功能代码都部署在一起就可以，这样可以减少开发，部署和维护的成本。
传统的web开发方式，全部的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等全部逻辑。
比如说一个电商系统，里面包含用户管理，商品管理，订单管理，物流管理等，我们把它做成一个web项目，并打包成war包，部署在一个tomcat上。
优点：
- 项目架构简单，适合小型项目，开发成本低
- 项目部署在一个节点上，维护方便
缺点：
- 全部功能集成在一个工程中，对大型项目来说，不易开发和维护
- 项目模块之间紧密耦合，单点容错率低
- 无法针对不同模块进行针对性优化和水平扩展
如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元，如图所示。
所以，从思路和理念上来讲，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫作“微服务”，而围绕着这个思路和理念构建的一系列基础设施和指导思想，笔者将它称为“微服务体系”。
垂直应用架构
随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候你会发现，并不是所有的模块都会有比较大的访问量。
以电商系统为例子，用户访问量的增加会影响用户管理模块和订单模块等，对营销管理，运营管理系统等可能影响较小，这时候我们希望只增加用户管理和订单管理的节点，但是单体应用架构无法做到，这时候垂直应用架构诞生了。
所谓的垂直应用架构，就是将原来的一个应用拆分成互不相干的几个应用，以提升效率。
比如我们可以对电商系统进行拆分：
- 电商系统（用户管理，订单管理，商品管理等）
- 运营管理系统（商家管理，活动管理，客服系统，订单管理，用户管理，商品管理等）
- CMS系统（广告系统，营销管理等）
这样拆分完成之后，一旦用户的访问量变大，只需要增加电商系统的节点就可以了，而无需增加运营管理系统和CMS系统的节点。
分布式架构（未落地实现）
当垂直应用越来越多，重复的业务代码就会越来越多。
比如运营管理系统也需要对订单，用户，商品等做管理。
营销管理中也需要对订单做相关的调用。
这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层做为独立的服务，然后由前端控制层调用不同的业务层服务呢？
这就产生了新的架构，分布式架构。
它将工程拆分为表现层和服务层两部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来进行实现。服务层可以部署多个节点来提升系统的性能。
优点：
- 抽取公共的功能为服务层，提高代码复用性
缺点：
- 系统间耦合度变高，调用关系错综复杂，难以维护
- 当服务节点过多后，表现层需要维护的信息也变的过多，更进一步增加了维护的难度。
SOA（面向服务的架构）
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行管理。
在SOA架构中，通常这个调度中心被称为注册中心。服务层将服务注册在注册中心，表现层只需要向注册中心索要服务地址即可，负载均衡，心跳检测等都由注册中心(SOA架构的核心)来实现。
优点：
- 使用注册中心，解决了服务间的调用关系
- 扩展也大大增强
缺点：
- 服务和服务之间有耦合，比如说多个服务使用同一个数据库服务
- 服务关系复杂，无法独立执行，部署，增加了运维和测试的难度
微服务架构
现代微服务的定义：微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维
SOA架构→微服务
微服务架构从某种程度上来说，是对SOA架构的延伸，它强调服务的彻底拆分。具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理
服务原子化
把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来
每一个服务都可以独立部署，独立运行，独立升级，独立扩展，有自己的数据库服务。
此时的服务称为“微服务”。
优点：
- 服务原子化，每个服务任务清晰，易于扩展维护
缺点：
- 维护成本过高（容错，分布式事务等）
松耦合和高内聚
微服务重在独立布署和独立业务，而所谓的微服务，并不是越小越好，而是通过团队规模和业务复杂度由粗到细的划分过程，所遵循的原则是松耦合和高内聚
- 松耦合 修改一个服务不需要同时修改另一个，每个微服务都可以单独修改和布署
- 高内聚 把相关的事务放在一起，把不相关的排除出去，聚集在一起的事务只能干同一件事
具体实现手段
- 单独的数据库，如果该微服务的数据量比较大，需要分库分表。
- 统一的服务接口，尤其是使用了API网关
- 所有的微服务都是独立的Java进程跑在独立的虚拟机上
微服务的好处（优点）有哪些？
可以解决复杂性的问题，在功能不变的情况下，分解为多个相互协作的微服务，通过rest API定义边界，这样极大易于开发、理解和维护。
微服务架构是的每个服务可以由专门的开发团队或者个人开发者进行开发，开发者可以自由选择技术，不必受制于规定的技术和框架，只要API服务协议好交互方式即可（如restful）。这样即使重新技术过时的微服务模块儿或者重写以前的代码，也不是很困难。
微服务架构模式使得每个微服务独立部署，且每个服务独立扩展，开发者不再需要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。
显然，随着系统复杂度的提升，以及对系统扩展性的要求越来越高，微服务化是一个很好的方向，但除此之外，微服务还会给我们带来哪些好处？
独立，独立，还是独立
我们说微服务打响的是各自的独立战争，所以，每一个微服务都是一个小王国，这些微服务跳出了“大一统”（Monolith）王国的统治，开始从各个层面打造自己的独立能力，从而保障自己的小王国可以持续稳固的运转。
首先，在开发层面，每个微服务基本上都是各自独立的项目（project），而对应各自独立项目的研发团队基本上也是独立对应，这样的结构保证了微服务的并行研发，并且各自快速迭代，不会因为所有研发都投入一个近乎单点的项目，从而造成开发阶段的瓶颈。开发阶段的独立，保证了微服务的研发可以高效进行。
服务开发期间的形态，跟服务交付期间的形态原则上是不需要完全高度统一的，即使我们在开发的时候都是各自进行，但交付的时候还是可以一起交付，不过这不是微服务的做法。
在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。
服务交付之后需要部署运行，对微服务来说，它们运行期间也是各自独立的。
微服务独立运行可以带来两个比较明显的好处，第一个就是可扩展性。我们可以快速地添加服务集群的实例，提升整个微服务集群的服务能力，而在传统 Monolith 模式下，为了能够提升服务能力，很多时候必须强化和扩展单一结点的服务能力来达成。如果单结点服务能力已经扩展到了极限，再寻求扩展的话，就得从软件到硬件整体进行重构。
软件行业有句话：“Threads don’t scale，Processes do！”，很明确地道出了原来 Monolith 服务与微服务在扩展（Scale）层面的差异。
对于 Java 开发者来说，早些年（当然现在也依然存在），我们遵循 Java EE 规范开发的 Web 应用，都需要以 WAR 包的形式部署到 TOMCAT、Jetty、RESIN 等 Web 容器中运行，即使每个 WAR 包提供的都是独立的微服务，但因为它们都是统一部署运行在一个 Web 容器中，所以扩展能力受限于 Web 容器作为一个进程（process）的现状。
无论如何调整 Web 容器内部实现的线程（thread）设置，还是会受限于 Web 容器整体的扩展能力。所以，现在很多情况下，大家都是一个 TOMCAT 只部署一个 WAR，然后通过复制和扩展多个 TOMCAT 实例来扩展整个应用服务集群。
当然，说到在 TOMCAT 实例中只部署一个 WAR 包这样的做法，实际上不单单只是因为扩展的因素，还涉及微服务运行期间给我们带来的第二个好处，即隔离性。
隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。
在架构设计上有一种实践模式，即隔板模式（Bulkhead Pattern），这种架构设计模式的首要目的就是为了隔离系统中的各个功能单元和实体，使得系统不会因为一个单元或者服务的失败而导致整体失败。
这种思路在造船行业、兵工行业都有类似的应用场景。现在任何大型船舶在设计上都会有隔舱，目的就是即使有少量进水，也可以只将进水部位隔离在小范围，不会扩散而导致船舶大面积进水，从而沉没。当年泰坦尼克号虽然沉了，但不意味着他们没有做隔舱设计，只能说，伤害度已经远远超出隔舱可以提供的基础保障范围。
在坦克的设计上，现在一般也会将弹药舱和乘员舱隔离，从而可以保障当坦克受创之后，将伤害尽量限定在指定区域，尽量减少对车乘成员的伤害。
前面我们提到，现在大家基本上弱化了 Java EE 的 Web 容器早期采用的“一个 Web 容器部署多个 WAR 包”的做法，转而使用“一个 Web 容器只部署一个 WAR 包”的做法，这实际上正是综合考虑了 Web 容器的设计和实现现状与真实需求之后做出的合理实践选择。
这些 Web 容器内部大多通过类加载器（Classloader）以及线程来实现一定程度上的依赖和功能隔离，但这些机制从基因上决定了这些做法不是最好的隔离手段。而进程（Process）拥有天然的隔离特性，所以，一个 WAR 包只部署运行在一个 Web 容器进程中才是最好的隔离方式。
现在回想一下，好像自从各个微服务打响独立战争并且独立之后，无论从哪个层面来看，各自“活”得都挺好。
多语言生态
微服务独立之后，给了对应的团队和组织快速迭代和交付的能力，同时，也给团队和组织带来了更多的灵活性，实际上，对应交付不同微服务的团队或者组织来说，现在可以基于不同的计算机语言生态构建这些微服务，如图所示。
微服务的提供者既可以使用 Java 或者 Go 等静态语言完成微服务的开发和交付，也可以使用 Python 或者 Ruby 等动态语言完成微服务的开发和交付，对于团队内部拥有繁荣且有差异的语言文化来说，多语言生态下的微服务开发和交付将可以最大化的发挥团队和组织内部各成员的优势。
当然，对于多语言生态下的微服务研发来说，有一点需要注意：为了让服务的访问者可以用统一的接口访问所有这些用不同语言开发和交互的微服务，应该尽量统一微服务的服务接口和协议。
在微服务的生态下，互通性应该是需要重点关注的因素，没有互通，不但服务的访问者和用户无法很好地使用这些微服务，微服务和微服务之间也无法相互信赖和互助，这将大大损耗微服务研发体系带来的诸多好处，而多语言生态也会变成一种障碍和负累，而不是益处。
记得时任黑猫宅急便社长的小仓昌男在其所著的《黑猫宅急便的经营学》中提到一个故事，日本国铁曾经采用不同于国际标准的集装箱和铁路规格，然后发现货物的运输效率很低，经过考察发现，原来是货物从国际标准集装箱卸载之后，在通过日本国铁运输之前，需要先拆箱，重新装入日本国铁规格的集装箱，然后装载到日本国铁上进行运输。
但是，如果日本国铁采用国际标准的集装箱规格，那么货物集装箱从远洋轮船上卸载之后就可以直接装上国铁，这将大大加快运输效率（日本，国铁改革后也证明确实如此）。日本国铁在前期采用私有方案时，只关注了自己的利益和效率，舍弃了互通，也带来了效率的低下。
所以，在开发和交付微服务的时候，尤其是在多语言生态下开发和交付微服务，我们从一开始就要将互通性作为首要考虑因素，从而不会因为执迷于某些服务或者系统的单点效率而失去了整个微服务体系的整体效率。
实现微服务会带来哪些挑战？
使用微服务也就面临着由单体项目向微服务项目过渡，而采用了微服务架构后也就意味着服务之间的调用链路会比以前延长了很多，在调用链路上发生故障的几率也就随之增大，同时调用链路越长，性能越会受影响。
微服务架构中是存在很多陷阱的，并不是简单的拿来使用就可以，所以企业要大规模使用微服务不仅仅是从思想和业务上面进行合理划分，还需要诸多技术组件以及高效的运维来协同合作，如图所示。
防止雪崩
当一个服务无法承受大请求压力的时候，是否会影响所依赖的其他服务？这时候可以考虑限流等措施。
功能降级
当某个服务出现故障时，是否有容错手段能够让业务继续跑下去，而不影响整体应用。
冥等
当用户多次下同一订单时，得到的结果永远同一个。
缓存
当请求量较大时，为避免对数据库造成较大压力，可以适当将一些变化较小，读取量较大的数据放入缓存。
超时
超时时间对于调用服务来说非常重要，超时时间设置太长可能会把整体系统拖慢，而设置短了又会造成调用服务未完成而返回，我们在实际工作中需要根据业务场景进行分析，选择一个恰当的超时设定值。
熔断
使用熔断器（断路器），当请求下游的服务时发生了一定数量的失败后，熔断器打开，接下来的请求快速返回失败。过一段时间后再来查看下游服务是否已恢复正常，重置熔断器。
服务隔离
当所调用的服务发生故障的时候，上游服务能够隔离故障确保业务能够继续运行下去
可伸缩
当并发量较大，原有服务集群无法满足现有业务场景时，可以采用扩容策略，而当并发量较小时，服务集群可以采用缩容策略，以节省资源。
微服务架构的常见问题
- 这么多小服务，如何管理它们？（服务治理，注册中心【服务注册，发现，剔除】）
- 这么多小服务，它们之间如何通讯？（restful RPC）
- 这么多小服务，客户端怎么访问他们？（网关）
- 这么多小服务，如果出现问题，如何自处理？（容错）
- 这么多小服务，一旦出现问题，应该如何排错？（链路追踪）
对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。
服务治理
服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。
服务注册： 服务实例将自身服务信息注册到注册中心。
服务发现： 服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
服务剔除： 服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。
服务调用
在微服务架构中，通常存在多个服务之间的远程调用需求。
目前主流的远程调用技术有基于HTTP的RESTFUL接口和基于TCP的RPC协议。
- REST： 这是一种HTTP的调用格式，更标准，更通用，无论哪种语言都支持http协议。
- RPC： 一种进程间的通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要作用就是让远程服务调用更简单，透明。RPC框架负责屏蔽底层的传输方式，序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
区别与联系：
| 比较项 | Restful | RPC |
|---|---|---|
| 通讯协议 | HTTP | 一般使用TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 较高 |
服务网关
随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如何让客户端直接与各个微服务通信可能出现：
- 客户端需要调用不同的url地址，增加难度
- 在一定的场景下，存在跨域请求的问题
- 每个微服务都需要单独进行身份认证
- 微服务可能使用的协议不同，客户端需要进行适配
- 客户端需要自己实现负载均衡
- …
针对这些问题，API网关顺势而生。
API网关字面意思上理解，是将所有的API调用都接入到API网关，由网关层统一接入和输出。
一个网关的基本功能有：
- 统一接入
- 安全防护
- 协议适配
- 流量管控
- 长短链接支持
- 容错能力
- 负载均衡
有了网关之后，各个API服务提供团队可以专注于自己的业务逻辑处理，而API网关更专注于安全，流量，路由等问题。
服务容错
在微服务当中，一个请求经常会设计调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
我们没法预防雪崩效应的发生，只能尽可能去做好容错。
服务容错的三个核心思想：
- 不被外界环境影响
- 不被上游请求压垮
- 不被下游响应拖垮
链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发，可能使用不同的编程语言来实现，有可能部署在了几千台，上万台服务器上，横跨多个不同的数据中心。
因此需要对一次请求涉及的多个服务链路进行日志记录，性能监控。
这就是链路追踪。
微服务架构的常见解决方案
ServiceComb
Apache ServiceComb 是一个微服务的开源解决方案。其包含多个组件，通过组件之间的搭配，可以灵活的应对不同的场景。
Apache ServiceComb 提供了融合开源生态的一站式微服务开源解决方案，致力于帮助企业、用户和开发者将应用轻松微服务化上云，实现对微服务应用的高效运维管理。
华为开源的。
Spring Cloud
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复造轮子，它只是将目前各家公司开发比较成熟的，经得起实际考验的服务框架组合起来，通过Spring Boot风格进行在封装，屏蔽掉了服务的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包。
Spring Cloud Alibaba（国内主流）
Spring Cloud Alibaba为分布式应用程序开发提供一站式解决方案。它包含开发分布式应用程序所需的所有组件，使您可以轻松使用Spring Cloud开发您的应用程序。
使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将Spring Cloud程序接入Alibaba的分布式解决方案，并使用阿里巴巴中间件构建分布式应用系统。
Spring Cloud Alibaba介绍
- 阿里巴巴结合自身微服务实践，开源的微服务全家桶
- 在Spring Cloud项目中孵化，很可能成为Spring Cloud第二代标准的实现
- 在业界广泛使用，已有很多成功案例
主要功能
- 服务限流降级：默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
- 服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持，使用Alibaba Nacos。
- 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新，使用Alibaba Nacos。
- 消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力，配合RocketMQ使用。
- 分布式事务：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题，使用Seata。
- 阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。
- 阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
官方介绍：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md
组件
官方介绍：https://github.com/alibaba/spring-cloud-alibaba/blob/master/Roadmap-zh.md
Sentinel
阿里巴巴开源产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos
阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ
Apache RocketMQ™ 基于 Java 的高性能、高吞吐量的分布式消息和流计算平台。
Dubbo
Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata
阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud OSS
阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX
阿里中间件团队开发的一款分布式任务调度产品，支持周期性的任务与固定时间点触发任务。
Alibaba Cloud SMS
覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
Spring Cloud Alibaba真实应用场景
- 大型复杂的系统，例如大型电商系统
- 高并发系统，例如大型门户，秒杀系统
- 需求不明确，且变更很快的系统，例如初创公司业务系统
Spring Cloud Alibaba与Spring Cloud
简单来说，SpringCloud Alibaba是SpringCloud的子项目，它是SpringCloud第二代的实现；
总结来说：
- 组件性能更强
- 良好的可视化界面
- 搭建简单，学习曲线低
- 文档丰富并且是中文