前言
Spring框架自2002年诞生以来一直备受开发者青睐,它包括SpringMVC、SpringBoot、Spring Cloud、Spring Cloud Dataflow等解决方案。有人亲切的称之为:Spring 全家桶。
很多研发人员把spring看作心目中最好的java项目,没有之一。所以这是重点也是难点,工作中必须会,面试时肯定考。那么,花费10分钟,由阿里一线架构师,带你梳理Spring框架相关知识。
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
今天,就由某大厂一线架构师来手撕微服务架构,带你大战Spring Boot、Spring Cloud、Nginx和Docker,这些内容不信你看完还搞不懂!
注意:以下所有面试题(含答案)的文档,以及笔记整理、实战pdf,均可以免费分享给大家哦。
微服务是什么
微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service),根本思想类似于Unix的管道设计理念。2014年,由Martin Fowler 与 James Lewis共同提出了微服务的概念,定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法,每个服务运行在自己的进程中,并通过轻量级的机制进行通讯(HTTP API)。关键的三点是small、automated以及lightweight。
对比SOA,微服务可以看做是SOA的子集,是轻量级的SOA,粒度更细的服务,独立进程、数据分离,更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理:
-
单一职责
-
关注分离:
控制与逻辑相分离
-
模块化和分而治之
特点:
-
用服务进行组件化
-
围绕业务能力进行组织
-
是产品而非项目
-
端点智能化和哑管道: 控制逻辑都在端点,管道仅仅是传输
-
全自动化部署
-
语言和数据的去中心化控制
-
面向失败设计
-
渐进式设计
综合来看,其优缺点如下:
优点:
-
模块的强边界
-
独立部署
-
技术选型的多样性
缺点:
-
分布式带来编程复杂度,远程调用的消耗
-
舍弃强一致性,实现最终一致性
-
操作复杂性要求有一个成熟的运维团队或者运维基础设施
为什么要采用微服务
是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案,但是仍然是有不小的成本的。
生产力和复杂度的关系如图所示,可见系统越复杂,微服务带来的收益越大。此外,无论是单体应用还是微服务,团队的技能都需要能够把控住。
马丁.福勒的一个观点是:除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署),否则都不要考虑微服务。大部分应用都应该选择单体架构,做好单体应用的模块化而不是拆分成服务。
因此,系统一开始采用单体架构,做好模块化,之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰,再重构为微服务架构是一个合理的架构演化路径。
四个可以考虑上微服务的情况:
-
多人开发一个模块/项目,提交代码频繁出现大量冲突。
-
模块间严重耦合,互相依赖,每次变动需要牵扯多个团队,单次上线需求太多,风险大。
-
主要业务和次要业务耦合,横向扩展流程复杂。
-
熔断降级全靠if-else。
微服务的三个阶段:
-
微服务1.0:
仅使用注册发现,基于SpringCloud或者Dubbo进行开发。
-
微服务2.0:
使用了熔断、限流、降级等服务治理策略