1.微服务
微服务是一种架构模式或者说是一种架构风格,它是提倡单一应用程序划分成一组小的服务,每个服务运行在其独立的自己的环境中,可以单独构建和部署,服务之间互相协调,互相配合,各项服务在工作(和出现故障)时不会相互影响,服务之间采用轻量级的通信机制互相沟通,通常是基于 Http 的 RESTful API 。
2.微服务架构的优势
- 可扩展性
在增加业务功能时,单一应用架构需要在原先架构的代码基础上做比较大的调整,而微服务架构只是要增加新的微服务节点,并调整与之有关联的微服务节点即可。在增加业务响应能力时,单一架构需要进行整体扩容,而微服务架构仅需要扩容响应能力不足的微服务节点。 - 扩容性
在系统发生故障时,单一应用架构需要进行整个系统的修复,涉及到代码的变更和应用的启停,而微服务架构仅仅徐璈针对有问题的服务进行代码的变更和服务启停,其他服务可通过重试、熔断等机制实现应用层面的容错。 - 技术选型灵活
微服务架构下,每个微服务节点可以根据完成需求功能的不同自由选择最合适的技术栈,即使对单一的微服务节点进行重构,成本也非常低。 - 开发运维效率更高
每个微服务节点都是一个单一进程,都专注于单一功能,并通过定义良好的接口清晰表述服务边界。由于体积小,复杂父低,每个微服务可由一个小规模团队或者个人完全掌控,易于保持高可维护性和开发效率。
3.微服务架构的缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度,随着服务的增加,运维的压力也在增大
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
4.SOA 和微服务架构的区别
功能 | SOA | 微服务 |
---|---|---|
组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
耦合 | 通常松耦合 | 总是松耦合 |
公司架构 | 任何类型 | 小型,专注于功能交叉的团队 |
管理 | 着重中央管理 | 着重分散管理 |
目标 | 确保应用能够交叉操作 | 执行新功能,快速拓展开发团队 |
5.服务治理
服务治理主要用于对分布式系统中大量微服务进行有效控制管理。
6.服务降级
服务降级就是对不重要的服务进行低优先级的处理。
也就是说,就是尽可能的大系统资源让给优先级高的服务。资源有限,而请求是无限的。如果在并发高峰期,不做服务降级处理,一方面肯定会影响整体服务的性能,严重的话可能导致宕机某些重要的服务不可用。所以在高峰期,为了保证网站核心功能服务的可用性,都要对某些服务降级处理。
7.服务降级方案
1.拒绝服务
判断应用来源,高峰时拒绝低优先级应用的服务请求,保证核心应用正常工作。也可以随机拒绝请求,直接返回服务器繁忙,避免同时通入过多的请求,这在电商秒杀时用的特别多。
2. 关闭服务
既然时高峰期,那么可以关闭一些冷门的或者边缘不重要的服务,给核心服务让出资源。如淘宝每年双11时候都会关闭评价、确定收货等一些与下单核心业务无关的服务,以保证用户下单支付正常,当然肯定也会使用拒绝服务,0点高峰期很多用户看到的基本服务器繁忙。
8.服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C有调用其他的微服务,这就是所谓的“扇出”,如扇出的链路上某个微服务的调度响应式过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统雪崩,所谓的“雪崩效应”。
9.服务熔断
服务熔断的作用类似于我们家用的保险丝,当某服务出现不可用或响应超时的情况时,为了防止整个系统出现雪崩,暂时停止对该服务的调用。
熔断机制时应对服务雪崩效应的一种微服务链路保护机制,扇出链路的某个微服不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息,当检测到该节点微服务响应正常后恢复调用链路。
10.服务网关
在微服务中,服务网关可以做到跨所有服务的路由转发、过滤和公共处理、统一接入、流量管控、安全防护、业务隔离等功能。