前言
随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构——垂直应用架构——分布式架构——SOA架构——微服务架构，接下来我们就来了解一下每种系统架构是什么样子的， 以及它们的缺点和优点。
一、微服务介绍
互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。
二、微服务环境搭建
我们本次是使用的电商项目中的商品、订单、用户为案例进行讲解。
三、Nacos Discovery--服务治理
先来思考一个问题
通过上一章的操作，我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址（ip，端口）等硬编码到了代码中，这种做法存在许多问题：
- 一旦服务提供者地址变化，就需要手工修改代码
- 一旦是多个服务提供者，无法实现负载均衡功能
- 一旦服务变得越来越多，人工维护调用关系困难
那么应该怎么解决呢， 这时候就需要通过注册中心动态的实现服务治理
四、Sentinel--服务容错
在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪
五、Gateway--服务网关
大家都都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用
六、Sleuth--链路追踪
在大型系统的微服务化构建中，一个系统被拆分成了许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。在这种架构中，一次请求往往需要涉及到多个服务，也就意味着这种架构形式也会存在一些问题：
- 如何快速发现问题？
- 如何判断故障影响范围？
- 如何梳理服务依赖以及依赖的合理性？
- 如何分析链路性能问题以及实时容量规划？
七、Rocketmq--消息驱动
在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间加入消息队列 MQ。
八、SMS--短信服务
短信服务（Short Message Service）是阿里云为用户提供的一种通信服务的能力。
- 产品优势：覆盖全面、高并发处理、消息堆积处理、开发管理简单、智能监控调度
- 产品功能：短信通知、短信验证码、推广短信、异步通知、数据统计
- 应用场景：短信验证码、系统信息推送、推广短信等
九、Nacos config--服务配置
首先我们来看一下,微服务架构下关于配置文件的一些问题：
- 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。
- 配置文件无法区分环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
- 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。
基于上面这些问题，我们就需要配置中心的加入来解决这些问题
十、Seata--分布式事务
事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。简单地说，事务提供一种“要么什么都不做，要么做全套”机制。
十一、Dubbo--rpc通信
//暴露服务:注意这里使用的是dubbo提供的注解
@Service,而不是Spring的 @Service public class ProductServiceImpl implements ProductService {
@Autowired private ProductDao productDao;
@Override public Product findByPid(Integer pid) {
return productDao.findById(pid).get();
}
}为了不影响阅读在这就展示了整个目录和内容截图 ，这份SpringCloudAlibaba学习笔记需要的可以自己领取，希望可以对大家的知识提升有帮助！