第 1 节 互联网应用架构演进
随着互联网的发展,用户群体逐渐扩大,网站的流量成倍增⻓,常规的单体架构已无法满足请求压力
和业务的快速迭代,架构的变化势在必行。下面我们就以拉勾网的架构演进为例,从最开始的单体架构
分析,一步步的到现在的微服务架构。
淘宝:LAMP,Linux、Apache、MySQL、PHP
1 )单体应用架构
在诞生之初,拉勾的用户量、数据量规模都比较小,项目所有的功能模块都放在一个工程中编码、
编译、打包并且部署在一个Tomcat容器中的架构模式就是单体应用架构,这样的架构既简单实 用、便于维护,成本又低,成为了那个时代的主流架构方式。
优点:
高效开发 :项目前期开发节奏快,团队成员少的时候能够快速迭代
架构简单 :MVC架构,只需要借助IDE开发、调试即可
易于测试 :只需要通过单元测试或者浏览器完成
易于部署 :打包成单一可执行的jar或者打成war包放到容器内启动
单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。
缺点:
可靠性差 : 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃
复杂性高 :以一个百万行级别的单体应用为例,整个项目包含的模块多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。使得整个项目非常复杂。
扩展能力受限 : 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。
业务量上涨之后,单体应用架构进一步丰富变化,比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等,通过以上措施增强应对高并发的能力、应对一定的复杂业务场景,但依然属于单体应用架构。
2 )垂直应用架构
为了避免上面提到的那些问题,开始做模块的垂直划分,做垂直划分的原则是基于拉勾现有的业务特性来做,核心目标标第一个是为了业务之间互不影响,第二个是在研发团队的壮大后为了提高效率,减少组件之间的依赖。
优点:
- 系统拆分实现了流量分担,解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展,负载均衡,容错率提高
- 系统间相互独立,互不影响,新的业务迭代时更加高效
缺点
- 服务之间相互调用,如果某个服务的端口或者ip地址发生改变,调用的系统得手动改变
- 搭建集群之后,实现负载均衡比较复杂,如:内网负载,在迁移机器时会影响调用方的路 由,导致线上故障
- 服务之间调用方式不统一,基于 httpclient 、 webservice ,接口协议不统一
- 服务监控不到位:除了依靠端口、进程的监控,调用的成功率、失败率、总耗时等等这些监 控指标是没有的
3 )SOA应用架构
在做了垂直划分以后,模块随之增多,维护的成本在也变高,一些通用的业务和模块重复的越来越多,为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡,引入了阿里巴巴开源的
-
Dubbo ,一款高性能、轻量级的开源Java
-
RPC框架,可以和Spring框架无缝集成。它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
SOA (Service-Oriented Architecture),即面向服务的架构。根据实际业务,把系统拆分成合适的、独立部署的模块,模块之间相互独立(通过Webservice/Dubbo等技术进行通信)。
优点:分布式、松耦合、扩展灵活、可重用。
缺点:服务抽取粒度较大、服务调用方和提供方耦合度较高(接口耦合度)
4 )微服务应用架构
微服务架构可以说是SOA架构的一种拓展,这种架构模式下它 拆分粒度更小 、服务更独立。把应用
拆分成为一个个微小的服务,不同的服务可以使用不同的开发语言和存储,服务之间往往通过Restful等轻量级通信。微服务架构关键在于 微小、独立、轻量级通信 。
微服务是在 SOA 上做的升华粒度更加细致,微服务架构强调的一个重点是 业务需要彻底的组件化和服务化
微服务架构和SOA架构相似又不同
微服务架构和SOA架构很明显的一个区别就是 服务拆分粒度的不同 ,但是对于拉勾的架构发展来 说,我们所看到的SOA阶段其实服务拆分粒度相对来说已经比较细了(超前哦!),所以上述拉勾SOA到拉勾微服务,从服务拆分上来说变化并不大,只是引入了相对完整的新一代Spring Cloud微服务技术。自然,上述我们看到的都是拉勾架构演变的阶段结果,每一个阶段其实都经历了很多变化,拉勾的
服务拆分其实也是走过了从粗到细,并非绝对的一步到位。
举个拉勾案例来说明SOA和微服务拆分粒度不同
我们在SOA架构的初期,“简历投递模块”和“人才搜索模块”都有简历内容展示的需求,只不过说可能略有区别,一开始在两个模块中各维护了一套简历查询和展示的代码;后期我们将服务更细粒度拆分,拆分出简历基础服务,那么不同模块调用这个基础服务即可。
第 2 节 微服务架构体现的思想及优缺点
微服务架构设计的核心思想就是 “微” ,拆分的粒度相对比较小,这样的话单一职责、开发的耦合度 就会降低、微小的功能可以独立部署扩展、灵活性强,升级改造影响范围小。
微服务架构的优点 :
- 微服务架构和微服务
- 微服务很小,便于特定业务功能的聚焦
- 微服务很小,每个微服务都可以被一个小团队单独实施(开发、测试、部署上线、运维),团队合作一定程度解耦,便于实施敏捷开发
- 微服务很小,便于重用和模块之间的组装
- 微服务很独立,那么不同的微服务可以使用不同的语言开发,松耦合
- 微服务架构下,我们更容易引入新技术
微服务架构的缺点
- 微服务架构下,分布式复杂难以管理,当服务数量增加,管理将越加复杂;
- 微服务架构下,分布式链路跟踪难等;
第 3 节 微服务架构中的核心概念
服务注册与服务发现
- 例如:职位搜索 ->简历服务
服务提供者:简历服务
服务消费者:职位搜索
服务注册: 服务提供者将所提供服务的信息(服务器IP和端口、服务访问协议等)注册/登记到注册中心
服务发现: 服务消费者能够从注册中心获取到较为实时的服务列表,然后根究一定的策略选择一个服务访问
负载均衡
负载均衡即将请求压力分配到多个服务器(应用服务器、数据库服务器等),以此来提高服务的性能、 可靠性
熔断
熔断即断路保护。微服务架构中,如果下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。
链路追踪
微服务架构越发流行,一个项目往往拆分成很多个服务,那么一次请求就需要涉及到很多个服务。不同的微服务可能是由不同的团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在了很多服务器上(甚至百台、千台)横跨多个不同的数据中心。所谓链路追踪,就是对一次请求涉及的很多个服务链路进行日志记录、性能监控
API 网关
微服务架构下,不同的微服务往往会有不同的访问地址,客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:
1 )客户端需要调用不同的url地址,增加了维护调用难度
2 )在一定的场景下,也存在跨域请求的问题(前后端分离就会碰到跨域问题,原本我们在后端采
用Cors就能解决,现在利用网关,那么就放在网关这层做好了)
3 )每个微服务都需要进行单独的身份认证
那么,API网关就可以较好的统一处理上述问题,API请求调用统一接入API网关层,由网关转发请求。API网关更专注在安全、路由、流量等问题的处理上(微服务团队专注于处理业务逻辑即可),它的功能比如
1 )统一接入(路由)
2 )安全防护(统一鉴权,负责网关访问身份认证验证,与“访问认证中心”通信,实际认证业务逻辑交移“访问认证中心”处理)
3 )黑白名单(实现通过IP地址控制禁止访问网关功能,控制访问)
3 )协议适配(实现通信协议校验、适配转换的功能)
4 )流量管控(限流)
5 )长短链接支持
6 )容错能力(负载均衡)