SpringCloud微服务介绍

SpringCloud微服务介绍

一、微服务

1.1 概念

介绍微服务之前，我们需要了解单体架构、SOA以及微服务的基本概念

1. 单体架构：单体架构就是把系统的功能实现全部放在一个项目里面，打包的时候以一个jar包或war包发布。其部署简单，但随着需求激增，肯定会暴露很致命的缺陷。
2. SOA：SOA全称为Service Oriented Architecture，即面向服务的体系结构。其旨在提升代码的复用性、低耦合性等，多种服务组成一个完整的系统。
3. 微服务：微服务是由世界级软件开发大师Martin Fowler和James Lewis共同提出的概念。其定义如下：微服务是由多个功能单一的小服务组成的，服务可以根据业务功能设计进行拆分；这些服务分别独立部署；不同的服务之间可以使用不同的技术来进行实现（包括不同的编程语言、不同的数据库等）；服务与服务之间采用HTTP等轻量协议传输数据，服务之间独立性强。其具有显著提升了代码的复用性及可拓展性，降低耦合等等有点。

1.2 对比

1.2.1 单体架构与微服务

• 单体架构优点： 在业务初期，功能足够简单且网站流量不大的情况下是一个效率很高且成本较低的方案。
• 单体架构缺点： 随着时间的推移，业务量及网站流量的激增会导致单体架构程序出现很多问题

序号	问题	问题描述
1	代码复杂度高	因为所有代码都糅合在一起，耦合度很高，修改一处会伤筋动骨
2	程序出错影响服务稳定性	若某处代码出错，会导致大量地占用系统资源，服务宕机等情况
3	体积大、部署慢	若功能很多，项目打包后体积会很大，导致打包、发布的过程缓慢
4	阻碍技术更新	单体架构往往只使用一种编程语言或框架，若加入新的框架很大概率导致不兼容
5	历史遗留问题	一般经历多年的单体应用，都经过很多程序员的改动。由于每个人的编码习惯和编程能力不同，使代码比较难理解，修改的难度很大

• 微服务是否能解决？： 首先微服务是一组小服务，每个服务代码量较小，启动及部署很快。再者每个服务都是独立的进程或独立服务器运行，所以不存在一个程序报错影响全部的情况。最后每个服务可以使用不同的编程语言，而且服务可以根据业务进行细粒度的拆分，使得代码可以较快地理解，不管是引入新框架还是将服务进行动态延伸都很方便。

1.2.2 SOA与微服务

• 微服务相比于SOA提升的地方： 首先SOA和微服务在本质上都是拆分，降低耦合性以及提升代码复用性。而微服务相比SOA来说，更加突出了服务的独立性，可以更细粒度地拆分服务。例如一个短信服务，可以拆分成营销短信服务、订单短信服务等。拆分的粒度界限没有统一的标准，需要自己进行判断。

1.3 优点及缺点

1.3.1 微服务优点

序号	优点	描述
1	代码复杂度低	根据细粒度拆分成多个小服务，功能清晰，代码体积小，便于维护
2	技术类型不受束缚	每个服务可以选择合适的语言、框架等进行实现
3	独立部署	修改一个服务，就只需要重新部署这个服务即可，影响范围小
4	服务动态伸缩	若某个服务的承载量达到了上限，就多部署一些节点或增加服务器配置；相反的话就减少节点或降低服务器配置
5	错误隔离	多个服务中，若管理员端后台服务宕机了，但用户端的后台服务可以正常运行，错误只会影响到管理员端的后台
6	易于分库	每个应用可以单独连接一个数据库，大大省去分库的成本

1.3.2 微服务缺点

序号	缺点	描述
1	构建较复杂	例如构建SpringCloud微服务系统不是简单的服务调用，还要考虑网络延迟、网络故障等因素
2	服务依赖	例如有A1, A2, A3三个服务，A1调用A2，A2调用A3，而A3是最底层的服务。若A3出了问题，到了必须要修改的时候，A1和A2很可能也要进行改动
3	数据一致性	微服务中，各个服务都是独立的进程。若A1调用A2服务，在调用过程中，刚好遇到网络延迟，A1中受到异常数据回滚，而A2中已经将数据保存了，此时就会出现问题
4	接口测试排除BUG较困难	随着微服务的服务数量增多，要准确定位问题所在的话，可能不得不需要同时查看多个服务的情况
5	运维及部署	检查监控多个服务状态、快速地部署多个服务、根据负载情况实现服务的动态延伸等都是挑战

1.4 总结

• 虽然微服务存在一些缺点，但很多缺点可以通过工具来进行弥补。同时要注意根据业务情况来选择是否使用微服务，不要为了使用而使用。

---

二、微服务技术栈

从上文可以了解到，构建一个微服务系统没那么简单，所以需要介绍一下需要哪些技术栈来构建微服务系统，以及主流的落地实现（JAVA）

2.1 所需要的技术栈

序号	技术栈	技术栈描述
1	服务注册与发现	当调用接口服务时，首先从服务注册与发现服务中获取被调用服务的真实地址，然后调用到某个具体服务，调用端不必关心被调用服务的真实地址，容易实现目标服务的负载均衡，服务之间实现解耦
2	服务调用	调用端真正调用目标服务的技术
3	服务熔断、限流、降级	保证服务的稳定性
4	负载均衡	负载均衡算法决定调用这个集群中的哪个服务
5	配置中心	集中式管理项目的配置。方便修改，解决重复配置
6	消息队列	服务之间可以异步、解耦、减少链路调用
7	服务网关	可以用来验证，灰度发布等
8	服务监控	监控服务的健康状态
9	消息总线	可以用来更新配置
10	分布式链路追踪	用来查看接口的调用链路，方便排除BUG
11	自动化构建部署	持续集成、快速部署应用

2.2 SpringCloud技术栈

• JAVA目前已有通用的微服务解决方案，即SpringCloud。SpingCloud本身并不是一个拿来就可以用的框架，而是一套规范。主流的SpringCloud Netflix和SpringCloud Alibaba为开发者实现了这套规范。所以真正开发用的是SpringCloud Netflix和SpringCloud Alibaba的套件。
• 技术栈及实现（以上的实现方案均为简写，例如SpringCloud Config写成Config）

序号	技术栈	技术栈实现
1	服务注册与发现	Eureka、Zookeeper、Consul、Nacos
2	服务熔断、限流、降级	Hystrix、Resilience4j、Sentinel
3	服务调用	Ribbin、Loadbalancer、Feign、OpenFeign、Dubbo
4	配置中心	Config、Zookeeper、Consul、Nacos
5	服务网关	Zuul、Gateway
6	消息总线	Bus、Nacos

2.3 SpringCloud Alibaba

2.2中的实现方案既有SpringCloud Netflix的也有SpringCloud Alibaba的，那么该如何选择呢？

• SpringCloud Alibaba于2018年10月31日入驻Spring Cloud官方孵化器。之后的几个月，SpringCloud Netflix于2018年12月12日官宣进入维护模式，意味着SpringCloud Netflix套件将不再添加新功能，只修复高危问题，因此SpringCloud Netflix不适宜长期使用。
• 至此，SpringCloud Alibaba逐渐出现在我们视野。其经历大流量的考验，更符合国人的编码习惯，因此还是使用SpringCloud Alibaba比较稳妥。
• 下面来看看SpringCloud Alibaba具体提供了哪些组件

序号	技术栈	技术栈描述
1	Nacos	服务注册与发现，服务管理，配置中心
2	RocketMQ	开源的一款分布式消息中间件，主要提供可靠的消息发布与订阅服务
3	Dubbo Spring Cloud	远程调用框架
4	Sentinel	流控框架、提供服务限流、降级、熔断等功能，保护服务的稳定性
5	Seata	解决分布式系统中的事务问题（保证数据一致性）
6	OSS(收费)	提供高可用的文件存储服务
7	SchedulerX(收费)	阿里中间件开发的一款分布式任务调度产品
8	SMS(收费)	阿里云短信服务

2.4 总结

• 虽然SpringCloud Alibaba的组件很多，应用最广的还是它免费使用的组件，而且也可以尝试其他产品进行替代