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

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

单体架构到微服务

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

微服务微服务是服务化思想的一种最佳实践方向，更强调服务的粒度，服务的职责更加单一精炼

SpringCloud Alibaba 体系

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

面试题

soa和微服务的区别

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

你是怎么理解微服务的

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

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

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

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

提供统一服务入口，让微服务对前台透明
聚合后台的服务，节省流量，提升性能
提供安全，过滤，流控等API管理功能

服务之间如何通信抓住对内RPC，对外REST

RPC 远程过程调用（Thrift, Dubbo）传输效率高，其对象会被压缩(序列化)。只需要序列化一次
内网不需要防火墙，RPC速度更快（RPC不能通过防火墙，HTTP才可以）

异步消息调用异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的 Broker

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、大数据等，都是本人研究的方向。我将定期在公众号中分享技术干货，希望以我一己之力，抛砖引玉，帮助朋友们提升技术能力，共同进步！

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