SpringCloud Alibaba学习
1、微服务介绍
系统架构演变
随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。从互联网早起到现在,系统架构大体经历了下面几个过程单体应用架构----->垂直应用架构------>分布式架构>SOA架构—>微服务架构,当然还有悄然兴起的Service Mesh(服务网格化).接下来我们就来了解一下每种系统架构是什么样子的,以及各有什么优缺点。
架构的演变过程
- 单体应用架构
互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。
比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。
优点
开发成本低 架构简单
项目都部署在一个节点,方便维护
缺点
不宜开发和维护
紧密偶尔,容错率低
无法针对不同模块优化扩展
- 垂直应用架构
优点
可以水平扩展
提高了容错率
缺点
系统之间相互独立,无法进行相互调用
系统之间相互独立,会有重复的开发任务
- 分布式架构
优点
抽取公共的功能为服务层,提高代码复用性
缺点
耦合度变高,关系错综复杂,难以维护
- SOA架构
优点
使用治理中心(ESB\dubbo) 解决了服务间调用关系的自动调节
缺点
服务间会有依赖关系 一旦某个出错会影响较大(服务雪崩)
服务关系复杂,运维,测试部署困难
- 微服务架构(和SOA区别)
- 是SOA的升华
- 每个服务必须独立部署
- 数据库都是不同的
优点
服务原子化拆分,独立打包,部署和升级,保证每个微服务清晰的任务划分,利于扩展
微服务之间采用 Restful等轻量级的协议相互调用
缺点
分布式系统开发技术成本高(容错,分布式事务等)
复杂性更高。各个微服务进行分布式独立部署,当进行模块调用的时候,分布式将会变得更加麻烦
微服务架构介绍
他说微服务其实是一种架构风格, 我们在开发一个应用的时候这个应用城该是由一组小型服务组成,每个小型服务都运行在自己的进程内,小服务之间通过HTP的方式进行互联互通.
微服务架构的常见问题
一旦采用微服务系统架构,就势必回遇到这样几个问题
- 这么多小服务,如何管理他们?(服务治理注册中心[服务注册发现剔除]) nacos
- 这么多小服务,他们之间如何通讯? (restful rpc dubbo feign) httpclient"“ur”;参数), springBoot restTemplate(“url”.参数) , feign
- 这么多小服务,客户端怎么访问他们?(网关) gateway
- 这么多小服务,一旦出现问题了,应该如何自处理? (容错) sentinel
- 这么多小服务,一旦出现问题了,应该如何排错? (链路追踪) skywalking
对于上面的问题,是任何一个微服务设计者都不能绕过去的,因此大部分的微服务产品都针对每个问题提供了相应的组件来解决它们。
常见微服务架构
1.dubbo: zookeeper +dubbo + SpringMVC/SpringBoot
- 配套通信方式: rpc
- 注册中心: zookeeper / redis
- 配置中心: diamond
2.SpringCloud:全家桶+轻松嵌入第三方组件(Netflix)
- 闭源 不更新了
配套通信方式: http restful
注册中心: eruka / consul
配置中心: config
断路器: hystrix网关:zuul
分布式追踪系统: sleuth + zipkin
3.SpringCloud Alibaba 主流
- 对SpringCloud 的标准实现
- 以微服务为核心的整体解决方案