SpringCloud（微服务）
一、SpringCloud基础
1、SpringCloud五大组件
- 服务注册与发现——Netflix Eureka
- 负载均衡：
- 客户端负载均衡——Netflix Ribbon
- 服务端负载均衡：——Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口)
- 断路器——Netflix Hystrix
- 服务网关——Netflix Zuul
- 分布式配置——Spring Cloud Config
Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
Feign：基于Ribbon和Hystrix的声明式服务调用组件；
Zuul：API网关组件，对请求提供路由及过滤功能。
2、什么是微服务
微服务 (Microservices) 就是一些协同工作小而自治的服务。
微服务(Microservice Architecture) 是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
究竟什么是微服务呢？我们在此引用ThoughtWorks 公司的首席科学家 Martin Fowler 于2014年提出的一段话：
汉化：
- 就目前而言，对于微服务，业界并没有一个统一的，标准的定义。
- 但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它体长将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值，服务之间采用轻量级的通信机制(HTTP)互相沟通，每个服务都围绕着具体的业务进行构建，并且能狗被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应该根据业务上下文，选择合适的语言，工具(Maven)对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。
3、什么是微服务架构
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的
类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
**概念：**把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
**定义：**围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
**本质：**用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
类似于Idea中一个project包含了多个model
4、微服务的特点
优点：独立部署、扩展性强
缺点：运维的新挑战；接口的一致性；分布式的复杂性；
优点
- 单一职责原则；
- 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
- 开发简单，开发效率高，一个服务可能就是专一的只干一件事；
- 微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
- 微服务允许利用和融合最新技术；
- 微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库；
缺点
- 开发人员要处理分布式系统的复杂性；
- 多服务运维难度，随着服务的增加，运维的压力也在增大；
- 系统部署依赖问题；
- 服务间通信成本问题；
- 数据一致性问题；
- 系统集成测试问题；
- 性能和监控问题；
5、微服务架构
服务组件化；
按业务组织团队；
做”产品“的态度；
智能端点与哑管道（服务调用方式，实时，异步中间件）
去中心化治理（组件能针对不同的业务特点选择不同的技术平台）
去中心化管理数据（多个不同的MySql实例，各服务之间进行“无事务”的调用，数据一致性，只要求数据在最后的处理状态是一致的即可。补偿机制）
基础设施自动化（自动化测试、自动化部署）
容错设计（快速检测出故障资源并尽可能地自动回复服务是必须被设计和考虑的）
演进式设计
- 围绕业务功能进行组织（organized around business capability），不再是以前的纵向切分，而改为按业务功能横向划分，一个微服务最好由一个小团队针对一个业务单元来构建。
- 做产品而非做项目（product not project），不再是做完一个个项目，交付后就完工了，而是做产品，从设计编码到产品运维，做到全过程掌控和负责，即自己构建，自己运维（you build it，you run it）。
- 智能终端加简单通道（smart endpoints and dumb pipe），使用基于资源的API，将大量逻辑放在客户端，而服务器端则着重于提供资源，推荐基于Web而不是在Web之后做复杂逻辑（be of the Web，not behind the Web）。
- 去中心化管理（decentralized governance），自行其是，自我管理，不必在局限在一个系统里，不必围绕着一个中心。
- 去中心化数据管理（decentralized data management），只管理和维护自己的数据，相互之间互不直接访问彼此的数据，只通过API来存取数据。
- 基础设施自动化（infrastructure automation），每个微服务应该关注于自己的业务功能实现，基础设施应该尽量自动化——构建自动化、测试自动化、部署自动化、监控自动化。
- 为应对失败而设计（design for failure），设计之初就要考虑高可靠性（high reliability）和灾难恢复（disaster recover），并考虑如何着手进行错误监测和错误诊断。
- 演进式设计（evolutionary design），没有完美的架构，唯一不变的是变化。要善于应对变化，容易改变其设计和实现，因为其小，故而易变。
6、微服务技术栈
微服务条目 | 技术 |
服务开发 | Springboot、Spring、SpringMVC |
服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
服务注册与发现 | Eureka、Consul、Zookeeper等 |
服务调用 | REST、RPC、gRPC |
服务熔断器 | Hystrix、Envoy等 |
负载均衡 | Ribbon、Nginx等 |
服务接口调用（客户端调用服务发简单工具） | Feign等 |
消息队列 | kafka、RabbitMQ、ActiveMQ等 |
服务配置中心管理 | SpringCloudConfig、Chef等 |
服务路由（API网关） | Zuul等 |
服务监控 | Zabbix、Nagios、Metrics、Spectator等 |
全链路追踪 | Zipkin、Brave、Dapper等 |
服务部署 | Docker、OpenStack、Kubernetes等 |
数据流操作开发包 | SpringCloud Stream（封装与Redis，Rabbit、Kafka等发送接收消息） |
事件消息总线 | SpringCloud Bus |
7、为什么选择springcloud作为微服务架构
1.造型依据
- 整体解决方案和框架成熟度
- 社区热度
- 可维护性
- 学习曲线
2.各大IT公司用的微服务架构有那些
- 阿里Dubbo/HSF
- 京东JSF
- 新浪微博Motan
- 当当网DubboX
3.各微服务框架对比
功能点/服务框架 | Netflix/Spring cloud | Motan | gRPC | Thrift | Dubbo/DubboX |
功能定位 | 完整的微服务框架 | RPC框架，但整合了ZK或Consul，实现集群环境的基本的服务注册/发现 | RPC框架 | RPC框架 | 服务框架 |
支持Rest | 是 Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
支持多语言 | 是（Rest形式） | 否 | 是 | 是 | 否 |
服务的注册/发现 | 是(Eureka) Eureka服务注册表，Karyon服务端框架支持服务注册和健康检查 | 是(zookeeper/consul) | 否 | 否 | 是 |
负载均衡 | 是(服务端zuul+客户端Ribbon) Zuul-服务，动态路由 云端负载均衡 Eureka(针对中间层服务器) | 是(客户端) | 否 | 否 | 是(客户端) |
配置服务 | Netflix Archaius Spring cloud Config Server 集中配置 | 是(zookeeper提供) | 否 | 否 | 否 |
服务调用链监控 | 是(zuul）Zuul提供边缘服务，API网关 | 否 | 否 | 否 | 否 |
高可用/容错 | 是(服务端Hystrix+客户端Ribbon） | 是(客户端) | 否 | 否 | 是(客户端) |
典型应用案例 | Netflix | Sina | Google | Facebook | |
社区活跃度 | 高 | 一般 | 高 | 一般 | 已经不维护了(2017年以前) |
学习难度 | 中等 | 低 | 高 | 高 | 低 |
文档丰富度 | 高 | 一般 | 一般 | 一般 | 高 |
其他 | Spring Cloud Bus为我们的应用程序带来了更多管理端点 | 支持降级 | Netflix内部在开发集成gRPC | IDL定义 | 实践的公司比较多 |
