SpringCloud 2018

微服务概述
SpringCloud 概述
微服务工程搭建
Eureka 服务注册与发现
Ribbon 客户端负载均衡
Feign 服务接口调用
Hystrix 断路器
Zuul 路由网关
SpringCloud Config 分布式配置中心
SpringCloud 技术梳理

GitHub

https://github.com/hjyang19/microservicecloud.git
https://github.com/hjyang19/microservicecloud-config.git

微服务概述

1-微服务概述
- 1.1-面试题
- 1.2-是什么
- 1.3-微服务拆分
- 1.4-微服务设计
2-微服务与微服务架构
- 2.1-微服务
- 2.2-微服务架构
3-微服务优缺点
- 3.1-微服务优点
- 3.2-微服务缺点
4-微服务技术栈
- 4.1-技术栈
- 4.1-技术选型

1-微服务概述

1.1-面试题

什么是微服务？
微服务之间是如何独立通讯的？
SpringCloud 和 Dubbo 有哪些区别？
SpringBoot 和 SpringCloud，请你谈谈对他们的理解？
什么是服务熔断？什么是服务降级？
微服务的优缺点分别是什么？说下你在项目开发中碰到的坑？
你所知道的微服务技术栈有哪些？请列举一二？
Eureka 和 Zookeeper 都可以提供服务注册与发现的功能，请说说两个的区别？
…

1.2-是什么

业界大牛马丁.福勒(Martin Fowler)论文网址(https://martinfowler.com/articles/microservices.html)

就目前而言，对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architectural style)。

通常而言，微服务架构是一种架构模式或者说是一种架构风格：它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 Http 的 Restful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

技术维度理解：微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事。 从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

1.3-微服务拆分

微服务无统一维度主要原因：拆分维度的界定。

从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如我们有 User 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的 Service 更好还是应该合并到 User 服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节。

拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

1.4-微服务设计

单一职责原则：

每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
服务自治原则：

每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
轻量级通信原则：

首先是通信的语言非常的轻量，其次该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
接口明确原则：

由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

2-微服务与微服务架构

2.1-微服务

微服务强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用。狭意的看：可以看作 Eclipse 里面的一个个微服务工程或者 Module。

2.2-微服务架构

微服务架构是⼀种架构模式，它提倡将单⼀应⽤程序划分成⼀组小的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。每个服务运⾏在其独立的进程中，服务与服务间采⽤轻量级的通信机制互相协作（通常是基于 Http 协议的 Restful API）。每个服务都围绕着具体业务进⾏构建，并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外应当尽量避免统⼀的、集中式的服务管理机制，对具体的⼀个服务⽽⾔，应根据业务上下⽂，选择合适的语⾔、⼯具对其进⾏构建。

3-微服务优缺点

3.1-微服务优点

每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是 2 ~ 5 人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins、Hudson、Bamboo。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和 Html、Css 或其他界面组件混合。
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。

3.2-微服务缺点

开发人员要处理分布式系统的复杂性。
服务运维难度，随着服务的增加，运维的压力也在增大。
系统部署依赖。
服务间通信成本。
数据一致性。
系统集成测试。
性能监控。

4-微服务技术栈

4.1-技术栈

微服务条目	落地技术
服务开发	Spring Boot、Spring、SpringMVC 等。
服务配置与管理	Netflix 公司的 Archaius、阿里的 Diamond 等。
服务注册与发现	Eureka、Consul、Zookeeper 等。
服务调用	Rest、RPC、gRPC。
服务熔断器	Hystrix、Envoy 等。
负载均衡	Ribbon、Nginx 等。
服务接口调用（客户端调用服务简化工具）	Feign 等。
消息队列	Kafka、RabbitMQ、ActiveMQ 等。
服务配置中心管理	Spring Cloud Config、Chef 等。
服务路由（API网关）	Zuul 等。
服务监控	Zabbix、Nagios、Metrics、Spectator 等。
全链路追踪	Zipkin，Brave、Dapper 等。
服务部署	Docker、OpenStack、Kubernetes 等。
数据流操作开发包	SpringCloud Stream（封装与Redis、Rabbit、Kafka等发送接收消息）。
事件消息总线	SpringCloud Bus。
…	…