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

• 微服务教程合集: https://www.jianshu.com/c/df2a688e828e
• 案例项目地址: https://gitee.com/spzmmd/spring-cloud-demo

单体架构到微服务

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

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