什么是微服务
微服务是一种架构思想,这种思想在近几年被广泛的应用;因为过去的单体架构中存在有许多问题,慢慢促使了微服务架构的广泛使用;
微服务架构是一种架构模式,或者说是一种架构风格,它体长将单一的应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程内,服务之间互相协调,互相配置,为用户提供最终价值,服务之间采用轻量级的通信机制(HTTP)互相沟通,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境中,另外,应尽量避免统一的,集中式的服务管理机制,对具体的一个服务而言,应该根据业务上下文,选择合适的语言,工具(Maven)对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。
微服务和微服务架构?
-
微服务:
强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用,狭义的看,可以看作是IDEA中的一个个微服务工程,或者Moudel。IDEA 工具里面使用Maven开发的一个个独立的小Moudel,它具体是使用SpringBoot开发的一个小模块,专业的事情交给专业的模块来做,一个模块就做着一件事情。强调的是一个个的个体,每个个体完成一个具体的任务或者功能。
-
微服务架构:
微服务架构是一种架构模式,它体长将单一应用程序划分成一组小的服务,服务之间相互协调,互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务之间采用轻量级的通信机制(如HTTP)互相协作,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境中,另外,应尽量避免统一的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具(如Maven)对其进行构建。
可以看一下服务架构的转变:
单体架构
单体架构就是ALL IN ONE,所有服务都集中在一个模块中,在初学过程中几乎接触的项目都是单体架构,最后都可以打成一个jar包或者war包部署到服务器上;这样一个模块的部署就非常的简单,还可以横向扩展,通过负载均衡将多个应用部署到多台服务器上;如下图:
但是问题也慢慢出现,每当服务有了改动时,都需要重新给整个模块进行部署,哪怕是细微的改动,就相当于是整个服务的修改;随着代码的沉积,整个服务间的各个模块间的逻辑会越来越复杂,不利于后期的重构和管理,这时就需要一个新的架构模式来解决这样的问题;于是分布式架构就出现在大众的视野里;
小总结——单体架构优缺点
优点:
- 架构简单
- 部署成本低
缺点:
- 耦合度高(维护困难、升级困难)
- debug困难
分布式架构
因为单体架构在一些项目上出现的问题,人们便想是否可以把一整个服务给拆分为多个服务,这样每个服务都是一个单独的项目,不仅利于管理,而且各个模块间的逻辑更加清晰了;
所以就出现了分布式架构,如图:
这样看确实清晰了很多,而且维护升级也更加方便,但是同样伴随着几个问题:
- 一个服务模块要拆分到什么程度?
- 拆分成了多个服务,该把哪里作为访问入口?
- 多个服务间如何通信调用?
- 如何管理多个服务?
- 服务出问题了该怎么办?
俗话说“无规矩不成方圆”,想要优雅的使用分布式架构,就需要有响应的标准来约束它,不然就可能出现一百个分布式服务就一百种风格;
小总结——分布式架构优缺点
优点:
- 降低服务耦合
- 有利于服务升级和拓展
缺点:
- 服务调用关系错综复杂,一个模块粗错可能导致全站瘫痪
- 不同服务间存在冗余
微服务
微服务可以认为是一种经过良好架构设计的分布式架构方案,它有以下特性:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
- 自治:团队独立、技术独立、数据独立,独立部署和交付
- 面向服务:服务提供统一标准的接口,与语言和技术无关
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
微服务的这些特性其实就是给分布式服务定义了一个标准,让分布式服务有了一个统一的风格;
如图可以看到微服务种各个服务互不相干,并且每个微服务都有自己的存储能力,有自己的数据库(当然也可以共用一个);这样各个服务可以由多个不同的小团队开发,每个团队的职责更加单一,这非常利于后期部署和管理,也实现了各个服务间的解耦;
虽然微服务有这么多优点,同样也有一些问题:
- 多服务运维难度增加,运维的压力也在增大;
- 系统部署依赖问题;
- 服务间通信成本问题;
- 数据一致性问题;
- 系统集成测试问题;
- 性能和监控问题;
- 安全问题;
总结一下微服务架构核心要素:
服务治理 | 可观测性 | 安全性 |
---|---|---|
服务注册 | 日志采集 | 身份验证 |
服务发现 | 日志分析 | 认证授权 |
负载均衡 | 监控打点 | 访问令牌 |
扩缩容 | 监控大盘 | 审计 |
流量治理 | 异常报告 | 传输加密 |
稳定性治理 | 链路追踪 | 黑产攻击 |
… | … | … |
基本概念:
- 服务(service):一组具有相同逻辑的运行实体;
- 实例(instance):一个服务中,每个运行实体即为一个实例;
- 实例与进程的关系:实例与进程之间没有必然对应关系,一个实例可以对应一个或多个进程;
- 集群(cluster):通常指服务内部的逻辑划分,包含多个实例;
- 常见实例承载形式:进程,VM,K8s pod…
- 有状态/无状态服务:服务和实例是否存储了可持久化的数据(如磁盘文件);
既然微服务是一种分布式架构方案,且微服务还存在一些问题,如何解决实现?于是就出现了多种微服务相关技术;
微服务相关技术
微服务常见组件大致为:
但是这些组件都是相互分离的,可以把它们整合起来,大致将微服务相关技术整合分为三种:
- Dubbo+zookeeper
- SpringCloud
- SpringCloud Alibaba
简单对比一下这三种方案:
Spring Cloud 最大的一点是抛弃了Dubbo的RPC通信,采用的是基于http协议的RestFul风格;相对于RPC通信,这两种方式各有优劣,http牺牲了服务调用的性能,但也避免了原生RPC带来的问题;而且RestFul相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这个优点在当下强调快速演化的微服务环境下,显得更加合适;
这三种方案的出现都是为了更好的实现微服务并解决其中的问题,目前社区活跃度比较高的就是SpringCloud和SpringCloud Alibaba,尤其是后者,它在服务远程调用方面不仅支持Feign方式,服务接口采用RestFul风格,可以通过http协议进行通信;并且还支持Dubbo协议的接口,使用RPC协议进行通信;可以说SpringCloud Alibaba是SpringCloud的再一次升级整合;
当然如果想使用微服务完成一个项目并非只有这些技术就可以完成了,还需要一些其他技术:nginx、MQ、Redis等,微服务虽然是核心但是离不开它们的辅助,所以对于微服务的学习还是一条很长的路要走;一个完整的微服务项目大致如下图:
总结
这只是我初学微服务总结的笔记,因为微服务当下确实比较流行,但是技术要会灵活使用,有些项目不一定必须使用微服务架构,学习还是要做到灵活;微服务说不准哪一天就会过时;就比如一种新的微服务架构趋势Server Mesh服务网格,它对微服务间的调用进一步简化,虽然现在只是刚起步,说不准以后就会是另一番光景;
单体架构和微服务架构:
参考资料:黑马程序员
参考文章:传送门