微服务理论性知识
从书本上摘抄一些知识点。
1.单体架构存在的不足
1.1 单体架构存在的不足
-
- 业务越来越复杂,单体应用的代码量、代码的可读性、可维护性和可扩展性等变差。扩展困难。
-
- 用户量增加,单体架构性能差,并发能力有限。
-
- 测试的难度越来越大,业务的扩张导致复杂度指数上升。
1.2 单体架构使用集群存在的不足
-
- 系统仍然为单体应用,大量的业务意味着大量的代码,代码的可读性、可维护性、可扩展性很差。
-
- 海量用户,数据库将成为瓶颈。
-
- 持续交付能力差,业务越复杂,代码越多,修改程序问题,实现新需求需要的时间成本高。
2.微服务
2.1 什么是微服务
微服务没有统一的定义。
比较常用的定义是
简而言之,微服务架构的风格,就是将单一程序开发成一个微服务,每个微服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP RESTFUL API.这些服务围绕业务能力来划分构建的,并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言,以及不同数据存储技术,以保证最低限度的集中式管理。
特点如下:
-
- 按业务划分为一个独立运行的程序,即服务单元
-
- 服务之间通过HTTP协议通信
-
- 自动化部署
-
- 不同的编程语言
-
- 不同的存储技术
-
- 服务集中化管理
-
- 微服务是一个分布式系统
2.2 熔断机制
为了防止雪崩效应出现。
什么是雪崩效应?
存在微服务a,a依赖b,同时b也是其他微服务的依赖服务。
此时如果服务b出现阻塞,会导致a以及其他依赖b服务的微服务出现阻塞,
就会造成系统大量的阻塞服务,导致系统崩溃。
什么是熔断机制?
当确认服务b出现阻塞,那么其他请求b服务时,快速返回失败,从而使得调用者失败。
这样服务失败,但是不会阻塞。
自我修复?
当出现服务b熔断后,过去一定的时间,将服务b变为半熔断状态(允许部分请求,其余请求仍然是快速失败)
如果部分请求成功,那么会将服务b设置为正常。
此时,就实现了自我修复。
3.微服务的不足
3.1 微服务的复杂度
服务与服务之间相互依赖,如果修改某一服务,会对依赖的服务产生影响。如果无法准确的评估影响范围,那么造成的后果是灾难性的。
3.2 分布式事务
对于分布式事务存在cap理论。
即,同时满足一致性,可用性和分区容错是一件不可能的事情。
C:Consistency:数据的强一致性。
A:Availability:服务的可用性。
P:Partition-tolerance:分区容错。
微服务一般是AP系统,为了保证C,使用分布式事务。
分布式事务常用两阶段提交
1.发起分布式事务,分布式事务管理进行协调,并让参与的节点进行准备。将undo和redo写入日志,返回准备成功。
2.事务管理器收集所有参与阶段的准备结果,如果都成功,那么就提交,否则就回滚。
不过两阶段提交仍然无法保证数据一致性。
因为如果2阶段失败,就会造成数据异常。
3.3 服务划分
服务的划分一般根据业务进行划分,不能太大,不能太小。
3.4 服务部署
微服务多,部署复杂,使用自动化部署有额外成本。开发人员学习成本高。
4.微服务应该具备的功能
4.1 微服务的特点
-
- 按照业务来划分服务
-
- 每个服务都有自己的独立的基础组件
-
- 微服务之间通过HTTP协议或者消息组件进行通信
-
- 微服务有一套服务治理的解决方案,服务之间不耦合。随时增减微服务
-
- 单个微服务能够集群化部署,并且有负载均衡的能力
-
- 整个微服务应该有安全机制
-
- 整个微服务有链路最总的能力。
-
- 有完整的日志系统
4.2 微服务的组成
-
- 服务的注册与发现
-
- 服务的负载均衡
-
- 服务的容错
-
- 服务网关
-
- 服务配置统一管理
-
- 服务链路追踪
5.spring Cloud
5.1 常用组件
-
- 服务注册与发现 Eureka
-
- 熔断组件 Hystrix
-
- 负载均衡组件 Ribbon
-
- 路由网关 Zuul
上述4个组件来自Netflix公司,统称为Spring Cloud Netflix
- 路由网关 Zuul
-
- spring Cloud Config 配置
-
- spring Cloud Security 安全
-
- spring Cloud Sleuth 链路追踪
-
- spring Cloud Stream 数据流,操作mq