SpringCloud学习1_基本概念
1.微服务概述
摘抄自网络
单个轻量级服务一般为一个单独微服务，微服务讲究的是 专注某个功能的实现，比如登录系统只专注于用户登录方面功能的实现，讲究的是职责单一，开箱即用，可以独立运行。微服务架构系统是一个分布式的系统，按照业务进行划分服务单元模块，解决单个系统的不足，满足越来越复杂的业务需求。
马丁福勒（Martin Fowler）：就目前而言，对于微服务业界并没有一个统一的、标准的定义。但通常而言，微服务架构是一种架构模式或者说是架构风格，它提倡将单一应用程序划分成一组小的服务。每个服务运行在其独立的自己的进程中服务之间相互配合、相互协调，为用户提供最终价值。服务之间采用轻量级通信。每个服务都围绕具体业务进行构建，并能够独立部署到生产环境等。另外应尽量避免统一的、集中的服务管理机制。
自己的理解
将以前的一站式服务,解耦成一个个服务,每个服务去做一件事情,然后我们就可以进行组合啊各种操作,就像上面写的一样,甚至各个服务的编程语言都可以不同,只要提供我们所需要的能力即可.
基于这种架构思想,为了能成功的运行这一套体系,有了微服务的各种框架.
服务于这个架构理念,解决其中的通信、容灾等问题的解决方案.
2.微服务与微服务架构
-
微服务
形容的是服务的大小,这个应用能解决某个或者某一类的问题,就可以称之为一个微服务.
-
微服务架构
一种架构理念,就是最开始介绍的这一堆.
服务之间互相协调配合,最后为用户提供整套的功能.
每个微服务之间是独立的,有自己的服务器啊数据库啊等等,开发部署啊这些都可以独立完成.
3.微服务架构的优缺点
- 微服务的优点
（1）微服务更容易聚焦在特定的业务上。
（2）微服务可以由小团队独立开发
（3）微服务是松耦合的，可以独立部署
（4）可以使用不同的语言开发
（5）单个应用的业务更容易被理解，修改，小团队更容易关注自己的工作成果，无须合作而体现价值。
（6）更容易使用新技术
（7）微服务只是业务逻辑的代码，不会与HTML/CSS或其他界面混合。
- 微服务的缺点
（1）前期架构需要更多的工作量。
（2）与运维需要更多的交流
（3）带来更多的技术难点
（4）分布式的架构维护难度更高。
（5）问题跟踪更难
（6）随着服务的增加，管理的成本增加
4.微服务涉及的部分技术
5.微服务架构的4个核心问题:
- 服务很多,客户端如何访问?
- 这么多服务,服务之间如何通信?
- 这么多服务,如何管理?
- 服务挂了怎么办?
6.基于这四个问题,有了一系列的解决方案.
-
SpringCloud与NetFlix
一站式解决方案
Api网关: zuul组件
通信: Feign(基于Http)
服务注册与发现: Eureka
熔断机制: Hystrix
-
Dubbo与Zookeeper
半自动,需要整合别人的.
API网关: 没有,得找第三方组件,或者自己实现.
通信: Dubbo(高性能的RPC框架)
服务注册与发现: Zookeeper
没有:借助第三方
-
SpringCloud Alibaba
新的一站式解决方案,更简单,因为上面cloud的Netflix停更了.
7.以后可能用到的新概念
服务网格:Server Mesh、Istio
8.所以核心还是这四个问题
1.API
2.通信问题:Http、RPC
3.注册与发现
4.熔断机制
9.为啥会有这些问题?
网络不可靠,信息可能会丢失.
如果网络可靠,那只要最开始配置好了,设置好各个服务之间的通信关系,以后就不用管了,也不会考虑服务挂掉之类的问题.
就是因为情况太多变了,一切都可能存在着变化,由此才产生了上面的4个核心问题.
10.各种微服务框架的对比
| 功能点/服务框架 | Netflix/SpringCloud | Motan | gRPC | Thrift | Dubbo/DubboX |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服务框架 | RPC框架，但整合了ZK或Consul，实现集群环境的基本服务注册/发现 | RPC框架 | RPC框架 | 服务框架 |
| 支持Rest | 是，Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 支持RPC | 否 | 是（Hession2） | 是 | 是 | 是 |
| 支持多语言 | 是（Rest形式）？ | 否 | 是 | 是 | 否 |
| 负载均衡 | 是（服务端zuul+客户端Ribbon），zuul-服务，动态路由，云端负载均衡Eureka（针对中间层服务器） | 是（客户端） | 否 | 否 | 是（客户端） |
| 配置服务 | Netfix Archaius，Spring Cloud Config Server集中配置 | 是（zookeeper提供） | 否 | 否 | 否 |
| 服务调用链监控 | 是（zuul），zuul提供边缘服务，API网关 | 否 | 否 | 否 | 否 |
| 高可用/容错 | 是（服务端Hystrix+客户端Ribbon） | 是（客户端） | 否 | 否 | 是（客户端） |
| 典型应用案例 | Netflix | Sina | |||
| 社区活跃程度 | 高 | 一般 | 高 | 一般 | 2017年后重新开始维护，之前中断了5年 |
| 学习难度 | 中等 | 低 | 高 | 高 | 低 |
| 文档丰富程度 | 高 | 一般 | 一般 | 一般 | 高 |
| 其他 | Spring Cloud Bus为我们的应用程序带来了更多管理端点 | 支持降级 | Netflix内部在开发集成gRPC | IDL定义 | 实践的公司比较多 |
