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定义 | 实践的公司比较多 |