微服务架构
随着互联网的发展，用户群体逐渐扩大，网站的流量成倍增长，常规的单体架构已无法满足请求压力和业务的快速迭代，架构的变化势在必行。下面我们看一看架构演进，从最开始的单体架构分析
单体应用架构
项目之初，用户量、数据规模较小，项目所有的功能模块都放在一个项目中编码、编译、打包并且部署在一个Tomcat容器中的架构模式，这样的架构简单实用、便于维护、成本低。
优点：
- 高速开发：项目前期节奏快
- 架构简单：MVC架构：只需要借助IDE、调试即可
- 易于测试：只需要通过简单的单元测试
- 易于部署：打包成单一可执行的jar或者war包放在容器内启动
缺点：
- 随着需求的不断增加，越来越多的人加入开发团队，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低
- 可靠性差 某个应用的bug 例如死循环、内存溢出等，可能导致整个应用的崩溃
- 复杂性高：一个百万行级别的单体应用为例，整个项目包含的模块多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐。整个项目非常复杂
- 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如：应用中有的模块是计算密集型的，他需要强劲的CPU，有的模块是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协
业务量上涨之后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等。虽然增强了应对高并发的能力、应对一定的复杂业务场景，但依然属于单体应用架构。
垂直应用架构
垂直应用架构，做模块的垂直划分，做垂直划分的原则是基于现有的业务特性来做，核心目标是为了业务之间互不影响。第二是研发团队壮大后为了提高效率，减少组件之间的依赖。
优点：
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展，负载均衡、容错率提高
- 系统间互相独立。互不影响，新的业务迭代时更加高效
缺点:
- 服务之间互相调用，如果某个服务的端口或者IP地址发生改变，调用的系统得手动改变
- 搭建集群之后，实现负载均衡比较复杂，如：内网负载，在迁移机器时会影响调用方的路由，导致线上故障
- 服务之间调用方式不同意，基于httpclient webservice接口协议不统一
- 服务监控不到位，除了依赖端口、进行的监控，调用的成功率、失败率、总耗时等等这些监控指标是没有的
SOA应用架构(Service-Oriented Architecture 面向服务架构)
SOA 面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间互相独立(通过webservice/dubbo等技术进行通信)
做了垂直划分以后，模块随之增多，维护的成本也变高，一些通用的业务和模块重复的越来越多，为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡，引入了阿里巴巴开源的Dubbo，高性能、轻量级的开源Java RPC框架，可以和spring框架无缝集成。它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡，以及服务自动注册和发现。
优点：分布式、松耦合、扩展灵活、可重用
缺点：服务抽取粒度大、服务调用方和提供方耦合度较高(接口耦合度)
微服务架构
微服务架构可以说是SOA架构的一种扩展，这种架构模式下它拆分粒度更小、服务更独立，把应用拆分成一个个微笑的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于：微小、独立、轻量级通信。
微服务是在SOA上左的升华粒度更加细致，微服务架构强调的一个重点是业务需要彻底的组件化和服务化
GateWay 网关：整个应用程序的入口，通过负载均衡先到达网关，可以记录日志、鉴权、认证、流量控制等
Eureka : 服务注册中心，所有服务启动之后，都要在这里进行注册
配置中心：共有的配置提取出来，可以放到github上，直接修改自动刷新微服务
举例SOA和微服务拆分粒度不同：
例如在SOA架构的初期，“简历投递模块”和“人才搜索模块”都有简历内容展示的需求，只不过略有区别， 一开始在两个模块中各维护了一套简历查询和展示的代码；后期我们将服务更细粒度拆分，拆分出简历基础服务，那么不同模块调用这个基础服务即可。
微服务架构设计的核心思想就是“微”，拆分的粒度相对比较小，单一职责，开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强，升级改造影响范围小。
微服务架构的优点：微服务架构和微服务
- 微服务很小，便于特定业务功能的聚焦
- 微服务很小，每个微服务都可以被一个小团队独立实施(开发、测试、部署上线、运维)团队合作一定程度解耦，便于敏捷开发
- 微服务很小，便于重用和模块之间的组装
- 微服务很独立，那么不同的微服务可以使用不同的语言开发，松耦合
- 微服务架构下，更容易引入新技术
微服务架构的缺点：
- 微服务架构下，分布式复杂难以管理。当服务数量增加，管理将越加复杂。
- 微服务架构下，分布式链路跟踪难等。
微服务架构的核心概念
- 服务注册与服务发现
例如：职位搜索服务调用-简历服务
服务提供者：简历服务
服务消费者：职位搜索服务
服务注册：服务提供者将所提供服务的信息(服务器IP和端口、服务访问协议等)注册登记到注册中心
服务发现：服务消费者能够从注册中心获取到较为实时的服务列表，然后根据一定的策略选择一个服务访问
- 负载均衡
负载均衡即将请求压力分配到多台服务器，以此来提高服务的性能、可靠性
- 熔断
熔断即断路保护。微服务架构中，如果下游服务因访问压力过大而影响变慢或失败，上游服务为了保证系统整体可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。
- 链路追踪
微服务架构将一个项目拆分成很多个服务，那么一次请求就需要设计到很多个服务。不同的微服务可能是由不同的团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在很多服务器上(甚至百台、千台)横跨多个不同的数据中心(不同的城市甚至国家).所谓链路追踪，就是对一次请求涉及的很多歌服务链路进行日志记录、性能监控。
- API 网关
在微服务架构下，不同的微服务往往会有不同的访问地址，客户端需要调用多个服务的接口才能完成一个业务需求。如果让客户端直接与各个微服务通信可能出现：
- 客户端需要调用不同的URL地址，增加了维护调用难度
- 在一定的场景下，也存在跨域请求的问题(之前前后端分离跨域问题，在后端采用CORS就能解决，现在可以利用网关，那么就放在网关这层做)
- 每个微服务都需要进行独立的身份认证
API网关就可以较好的统一处理上述问题，API请求调用统一的API网关层，有网关转发请求，API网关更专注在安全、路由、流量等问题的处理上：
- 统一接入(路由)
- 安全防护(统一鉴权，负责网关访问身份认证验证与访问认证中心通信，实际认证业务逻辑交移访问认证中心处理)
- 黑白名单(实现通过IP地址控制禁止访问网关功能，控制访问)
- 协议适配(实现通信协议校验、适配转换的功能)
- 流量管控(限流)
- 长短连接支持
- 容错能力(负载均衡)
Spring Cloud概述
Spring Cloud 是一系列框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发。Spring Cloud并没有重复造轮子，他只是将目前各家公司开发的比较成熟，经得起实际经验考验的服务框架组合起来，通过springBoot风格进行在封装屏蔽掉了复杂的配置和实现原理，最终给开发者一套简单易懂、易部署和易维护的分布式系统开发工具包
:::tips Spring Cloud 是一系列框架的有序集合（Spring Cloud是一个规范）。 :::
Spring Cloud 解决了什么问题
spring cloud规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的一些问题：
- Distrbuted/versioned configuration 分布式/版本化配置
- service registration and discovery 服务注册与发现
- Routing 智能路由
- service - to -service 服务调用
- Load balancing 负载均衡
- Circuit Breaker 熔断器
- Global locks 全局锁
- Leadership election and cluster state 选举与集群状态管理
- Distributed messaging 分布式消息传递平台
spring cloud 核心组件：
spring cloud 组件协同工作机制
spring cloud与dubbo对比：
Dubbo是阿里巴巴公司开源的一个高性能的服务框架，基于RPC调用，底层使用的是TCP协议，目前使用率较高的Spring Cloud Netfix来说，它是基于HTTP的，在效率上没有Dubbo高，但是问题在于Dubbo体系的组件补全，不能够提供一站式解决方案，比如服务注册与发现需要借助于Zookeeper等实现，而Spring Cloud Netfix则是真正的提供了一站式服务化解决方案。
spring cloud 与 spring Boot的关系：
Spring cloud 利用了Spring Boot的特点，让我们能够快速的实现微服务组件开发，否则不使用springboot的话，我们在使用springcloud时，每一个组件相关jar包都需要我们自己导入配置以及需要开发人员考虑兼容等情况，所以springboot是我们快速把spring cloud微服务技术应用起来的一种方式。
若有收获，就点个赞吧
0 人点赞
