[微服务教程]1. 微服务架构概念&面试题

·  阅读 306

微服务系列教程:教程文集

单体架构到微服务

  • 单体架构 项目初期的一般方案是采取单体架构,把所有功能模块打包到一个jar/war包内,并发布于web容器内运行
  • 集群架构 随着用户量以及流量增加,服务器性能受到瓶颈,此时一般通过集群方式,添加新服务器来分散流量。此举可大幅度提升业务系统的并行处理能力
  • 业务垂直化拆分 集群下如果还是所有业务都放在一个包内运行,对于代码维护扩展是非常困难的,此时需要考虑对业务进行拆分,降低业务耦合度,提升稳定性。如拆分出用户、搜索、订单、支付等业务模块分别管理
  • 服务化(SOA)
    • 将通用的会被多个上层服务使用的模块独立抽离出来,形成独立的、可重用的共享服务,如用户查询、单点登录等
    • SOA面向服务架构,是一种软件组件和开发的方式,主要解决信息孤岛、互联互通、业务重用的问题
  • 微服务 微服务是服务化思想的一种最佳实践方向,更强调服务的粒度,服务的职责更加单一精炼

SpringCloud Alibaba 体系

  1. Dubbo, 用于实现高性能 Java RPC 通信
  2. Nacos, 服务注册发现、配置管理、服务管理
  3. Sentinel, 流量控制、熔断降级、系统负载保护
  4. RocketMQ, 分布式消息系统,提供低延时的、高可靠的消息发布与订阅服务
  5. Seata, 高性能微服务分布式事务解决方案

面试题

soa和微服务的区别

  • 微服务去除了SOA架构里面的服务总线
  • 微服务关注服务解耦,降低业务之间的耦合度
  • 微服务更关注持续交付,关注容器化

你是怎么理解微服务的

微服务架构是一种架构思想,实际以分布式系统方式开发,架构是为了结偶。 该架构应该解决分布式系统开发中主要遇到的四个问题

  • 客户端如何访问众多服务
  • 服务之间要如何通信
  • 服务之间如何发现
  • 服务挂了如何处理

如何处理微服务落地过程中的问题

  • 应用划分为众多服务以后,客户端需要如何访问 答案是通过统一的API网关入口解决,其作用如下

    • 提供统一服务入口,让微服务对前台透明
    • 聚合后台的服务,节省流量,提升性能
    • 提供安全,过滤,流控等API管理功能
  • 服务之间如何通信 抓住对内RPC,对外REST

    • 同步方式
      • HTTP REST(JAX-RS,Spring Boot) 需要序列化两次
      • RPC 远程过程调用(Thrift, Dubbo)
        • 传输效率高,其对象会被压缩(序列化)。 只需要序列化一次
        • 内网不需要防火墙,RPC速度更快(RPC不能通过防火墙,HTTP才可以)
    • 异步消息调用 异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能保证调用方的服务体验,继续干自己该干的活,不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱,需要接受数据 最终一致性;还有就是后台服务一般要实现 幂等性,因为消息送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验);最后就是必须引入一个独立的 Broker
      • Kafka
      • Notify
      • MessageQueue
  • 服务之间如何发现 服务注册与发现服务

    • 基于客户端的服务注册与发现
    • 基于服务端的服务注册与发现
  • 服务挂了如何处理

    • 重试机制 - 针对网络不可靠的问题
    • 限流 - 针对流量太大处理不过来
    • 熔断机制 - 一定时间无响应就不再连接
    • 负载均衡 - 针对高并发情况
    • 服务降级(本地缓存) - 保证核心服务可用,临时下线不必要的业务

什么是SpringCloud

  • 它制定了微服务、分布式系统框架的规范
  • 它集成了微服务落地需要的一系列框架,如配置管理、服务发现、熔断器、网关等
  • SpringCloud解决了什么问题 SpringCloud指定了微服务的规范,解决了微服务落地过程中需要处理的以下问题
    • 客户端如何访问众多服务
    • 服务之间要如何通信
    • 服务之间如何发现
    • 服务挂了如何处理

微服务架构的优点和缺点有哪些

优点:

  • 可用于解决复杂业务问题
  • 独立部署,可持续集成
  • 方便扩展,提高可用性
  • 业务拆分,方便复用,方便多团队开发

缺点:

  • 运维复杂
  • 数据一致性难以保证(事务难以保证)
  • 服务拆分后,不同业务模块之间的通信增加了时延

CAP定理是什么

一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

  • 一致性 更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致。 这里是强一致性,要不一起成功,要不一起失败
  • 可用性 服务一直可用,而且是正常响应时间。
  • 分区容错性 分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。 比如深圳机房和上海机房,上海机房无法使用的话深圳机房还可以用(这也叫异地多活)

BASE理论是什么

BASE 理论是对 CAP 理论的延伸,支持大型分布式系统。核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。

  • 基本可用(Basically Available) 基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。 电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务(如取消注册服务、聊天服务)。这就是损失部分可用性的体现。
  • 软状态(Soft State) 软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
  • 最终一致性(Eventual Consistency) 最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。 弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

后记

  • 欢迎加入Java交流群(qq群号: 776241689 )
  • 欢迎关注公众号"后端技术学习分享"获取更多技术文章! PS:小到Java后端技术、计算机基础知识,大到微服务、Service Mesh、大数据等,都是本人研究的方向。我将定期在公众号中分享技术干货,希望以我一己之力,抛砖引玉,帮助朋友们提升技术能力,共同进步!

原创不易,转载请在开头著名文章来源和作者。如果我的文章对您有帮助,请点赞/收藏/关注鼓励支持一下吧❤❤❤❤❤❤

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改