微服务(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上。

优点：

1. 项目架构简单，适合小型项目，开发成本低
2. 项目部署在一个节点上，维护方便

缺点：

1. 全部功能集成在一个工程中，对大型项目来说，不易开发和维护
2. 项目模块之间紧密耦合，单点容错率低
3. 无法针对不同模块进行针对性优化和水平扩展

如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元，如图所示。

所以，从思路和理念上来讲，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫作“微服务”，而围绕着这个思路和理念构建的一系列基础设施和指导思想，笔者将它称为“微服务体系”。

垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候你会发现，并不是所有的模块都会有比较大的访问量。

以电商系统为例子，用户访问量的增加会影响用户管理模块和订单模块等，对营销管理，运营管理系统等可能影响较小，这时候我们希望只增加用户管理和订单管理的节点，但是单体应用架构无法做到，这时候垂直应用架构诞生了。

所谓的垂直应用架构，就是将原来的一个应用拆分成互不相干的几个应用，以提升效率。

比如我们可以对电商系统进行拆分：

1. 电商系统（用户管理，订单管理，商品管理等）
2. 运营管理系统（商家管理，活动管理，客服系统，订单管理，用户管理，商品管理等）
3. CMS系统（广告系统，营销管理等）

这样拆分完成之后，一旦用户的访问量变大，只需要增加电商系统的节点就可以了，而无需增加运营管理系统和CMS系统的节点。

分布式架构（未落地实现）

当垂直应用越来越多，重复的业务代码就会越来越多。

比如运营管理系统也需要对订单，用户，商品等做管理。

营销管理中也需要对订单做相关的调用。

这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层做为独立的服务，然后由前端控制层调用不同的业务层服务呢？

这就产生了新的架构，分布式架构。

它将工程拆分为表现层和