1 Spring Cloud与微服务概述

1 概述

本篇文章来源于《Spring Cloud 微服务 —— 尹吉欢 著》

  微服务架构师一种架构风格，Spring Cloud 是实现微服务架构的一系列框架的有序集合。

2 传统的单体应用

  所谓单体应用程序，通俗来说就是所有的功能全部堆积在一起。这个应用大部分都是一个 war 包或者一个 jar 包。随着业务的发展，功能的增加，多年以后这个单体项目将变得越来越臃肿。
  这样的单体应用在公司创建初期是比较好的一种方案，要快速增加新功能或部署发布都比较简单，随着时间的推移，危机慢慢就会显露出来。任何一个 BUG 都可能导致整个应用瘫痪，正所谓牵一发而动全身。

3 什么是微服务

  “微服务”是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间使用 Http 的 API 进行资源访问与操作。
  就好比一个公司的发展过程，从最开始的一个小公司，到后来的大集团。大集团可拆分出多个子公司，每个子公司的都有自己独立的业务、员工，各自发展，互不影响，合起来则威力无穷。

4 微服务的优势与劣势

4.1 优势

• 服务的独立部署：每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
• 服务的快速启动：拆分之后服务启动的速度必然要比没拆分之前的要快的多，因为依赖的库少了，代码量也少了。
• 更加适合敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不需要整体重新发布。
• 职责专一，由专门的团队负责专门的服务：业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
• 代码的复用：每个服务都提供 REST API ，所有的基础服务都必须抽出来，很多的底层实现都可以以接口库方式提供。

4.2 劣势

• 分布式部署，调用的复杂性搞：单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都要独立部署的，通过 Http 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
• 独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这样的模式有点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性。
• 测试的难度提升：服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方法都是有影响的，这个时候自动化测试就非常重要了，如果要靠人一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。
• 运维难度的提升：在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。

5 什么是 Spring Cloud

  Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务注册、服务发现、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot 的开发风格做到一键启动和部署。通俗地将，Spring Cloud 就是用于构建微服务开发和治理的框架集合（并不是具体的一个框架），主要贡献来自 Netflix OSS。

5.1 Spring Cloud 模块介绍

• Eureka：服务注册中心，用于服务管理。
• Ribbon：基于客户端的负载均衡组件。
• Hystrix：容错框架，能够防止服务的雪崩效应。
• Feign：Web 服务器客户端，能够简化 Http 接口的调用。
• Zuul：API 网关，提供路由转发、请求过滤等功能。
• Config：分布式配置管理。
• Sleuth：服务跟踪。
• Stream：构建消息驱动的微服务应用程序的框架。
• Bus：消息代理的集群消息总线

  当然还有一些常用模块如Cli、Task…

5.2 SpringBoot与SpringCloud的版本对应详细版

• 大版本对应

Spring Boot	Spring Cloud
1.2.x	Angel版本
1.3.x	Brixton版本
1.4.x	stripes Camden版本
1.5.x	Dalston版本、Edgware版本
2.0.x	Finchley版本

• 在实际开发过程中，我们需要更详细的版本对应：
  .