Spring Cloud微服务架构从入门到会用（一）—总览

本教程不定时更新，如果这些文章对你有帮助，请加个关注，谢谢！

本教程仅仅能教会大家怎么使用Spring Cloud的各个组件，没有深挖实现原理，要想精通就就看各位看官老爷们自己了。

微服务框架

在说微服务之前我们先大概了解下框架的演进（此处我们主要讲Java后端开发的演变过程）

1. 单体应用

最初我们使用的都是Spring + MyBatis/Hibernate/JDBC + Struts/SpringMVC + jsp，开发人员即写页面，又写Java逻辑一个人完成整个功能，开发完成后打成一个war包，部署到Tomcat里，然后为用户提供服务。

2. 前后端分离

接下来Spring发布了SpringBoot，为了紧跟这个技术潮流，我们将开发框架切换为SpringBoot，采用前后分离的开发方式，前端用的是的jQuery，通过ajax与后台进行交互。这个时候我们变成了用nginx+jar的方式，把页面静态资源和后端服务分开了。

3. 负载均衡

发展到前后端分离，一版情况能满足大部分的企业应用了，毕竟大部分企业应用使用的用户不是很多。但是有一部分企业应用用户量偏大，采用以上的架构，在用户集中使用的时候就会出现问题，比如学校的教务系统，平时大家看看通知，下载个文件，查查分数，但是到了每学期一度的选课，大家集中在一个时间，去登录系统去抢课，这个时候服务器可能就崩溃了，或者是页面一直在加载，刷不出页面。这个时候就要上负载均衡了，nginx的吞吐量很高，这个时候的性能瓶颈是后端服务，也就是部署的那个jar包，比如我们一个jar同时能支持100人，那我启动10个，通过nginx的反向代理，我代理10个jar，这个时候我们也能解决问题。

4.微服务

采用了负载均衡的方案之后基本上就能满足更大一部分企业了，虽然能满足绝大部分企业了，但是有些企业的管理者觉得互联网公司上了微服务，我们也要上。这个时候我们的架构就要像微服务转变。那我们介绍下什么是微服务？所谓微服务它一定要“微”，也就是单一职责，一个服务只解决一个业务领域的问题；第二个是服务，对外提供我们能处理的业务服务。那么这么做有什么优点呢？

• 一个服务只负责一个业务领域，影响小，集使某个服务宕机了其他服务还能正常使用
• 代码量少，易于维护，不会很多人一起开发代码冲突
• 便于迭代升级，不需要和其他应用一起上线
• 耦合度低

当然，微服务也是有缺点的

• 运维成本上升
• 架构复杂度上升
• 带来更多的需要解决的问题（不同服务间调用事务问题）

一个微服务架构的系统由几十甚至几百个微服务组成，各个服务直接互相依赖，服务如何拆封，内部接口规范，事务等等问题。尤其是服务拆分，需要团队非常熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景。

Spring Cloud都有哪些组件（常用的6个组件）

• 服务注册发现 —— Eureka
• 服务网关——Spring Cloud Gateway
• 客户端负载均衡——Ribbon
• 熔断器——Hystrix
• 分布式配置——Spring Cloud Config
• 服务调用——Feign

以上组件时Spring Cloud官网提供的并建议使用的组件，我们呢要替换其中几个组件，替换为目前使用较多的，评价也比较好的组件

• 熔断器——Hystrix -> Sentinel
• 分布式配置——Spring Cloud Config -> Nacos

接下来我们将使用以上组件搭建一个Spring Cloud的工程，供大家参考学习。

在这里我想说一句，没有最好的架构，只有最适合的架构，比如公司要开发一个报销系统，你非得上微服务就没有意义了，增加了开发成本，增加了运维成本。再比如你们公司突然要发展电商，要开发一个商城系统，如果你还用springmvc，弄一个工程部署到tomcat里，那就是不负责任的表现。当然，选择某一个架构不只是根据业务，也要根据公司的实际情况去考虑，公司有没有那么多成本让你搞微服务，或者是暂时先上单体应用，然后慢慢再搞微服务。