您的位置：首页 > 运维架构 > 网站架构

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

2021-03-31 17:09 1191 查看

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

单体架构到微服务

  • 单体架构 项目初期的一般方案是采取单体架构，把所有功能模块打包到一个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、大数据等，都是本人研究的方向。我将定期在公众号中分享技术干货，希望以我一己之力，抛砖引玉，帮助朋友们提升技术能力，共同进步！

    原创不易，转载请在开头著名文章来源和作者。如果我的文章对您有帮助，请点赞/收藏/关注鼓励支持一下吧❤❤❤❤❤❤
    • 内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
    标签： 
    相关文章推荐
    新的分享
    章节导航