Spring Cloud学习(1)-----基础知识

思维导图:

引言:

    Spring Cloud学习系列是我对<>一书的读书笔记.本片文章则是第一章:基础知识的归纳总结.

    本文主要是通过对比单体服务和微服务的优缺点来说明微服务相关基础知识.最后会介绍微服务的普遍性的实现Spring Cloud.

一.系统架构

    此处的系统架构指的是整个系统的服务架构模式.一般来说,分为两种,一种是单体服务,一种是微服务.他们各有什么优缺点呢?

1.1 单体服务

    所谓的系统架构是单体服务是指整个系统都由一个服务所支撑,所有的业务逻辑也都在一个应用中.随着业务的增加而不停的增加业务模块.这样做有以下优缺点:

• 优点:前期业务逻辑和应用较小时,开发,测试,运维都比较方便和容易.
• 缺点:随着业务的不断增加,应用组件庞大起来.此时修改一个微小的功能,却需要将整个应用重新部署,影响其他业务模块的使用.

    所以,为了解决上述缺点,就逐渐开始使用微服务了.

1.2 微服务

    微服务是指将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过RESTful API进行通信协作.由于有了轻量级的通信协作基础,所以,这些微服务可以使用不同的语言实现.当然,微服务也拥有其自身的优缺点:

• 优点:与单体服务的缺点相对应,微服务可以在某一个业务上进行快速的开发,测试和部署.因为一个微服务只对应一个业务模块,所以体积小,易改动.
• 缺点:由于一整个服务被拆分成了需要通信协作的多个微服务,也会产生一些新的问题.比如如何对多个微服务进行运维.各个微服务之间的接口一致性问题,分布式环境的相关问题.

    Martin Fowler 在 Microservices一文中提炼出了微服务的如下几种特性,用于指导大家进行设计:

• 服务组件化:组件是可以独立更换和升级的单元.一个微服务的更替不影响其他微服务.
• 团队业务化:根据业务划分微服务并以此对团队进行组织.
• 做产品的态度:某一业务的微服务小团队需要对其产品的整个生命周期负责,而不是以开发和交付为目标
• 只能端点与哑管道:若将 微服务之间的通信改为RPC方式调用,会产生繁琐的通信,所以需要更粗粒度的通讯协议
• 去中心化治理:各个不同的微服务可以选用不同的技术平台,而不必有某种原生的短板出现
• 去中心化数据管理:每个微服务独自管理其自有的数据库.
• 基础设施自动化:随着业务的增加而微服务不断增加,运维和测试的难度随之增加.所以需要自动化测试和运维.
• 容错设计:微服务之间的调用可能出现不可控的错误,所以需要快速检测故障源并尽可能自动恢复服务
• 演进式设计:系统初期体量不大时可以使用单体服务,业务不同增加后可以转化为微服务.

二.Spring Cloud

    根据上述对微服务的描述可知,要使用微服务,我们就必须解决服务治理,分布式配置管理,服务跟踪,负载均衡等一系列的问题,一个问题可以使用某一个特殊的插件解决.最后,我们将使用大量的功能插件来实现微服务.Spring Cloud则是一个微服务架构的综合性解决框架,它整合了诸多被广泛实践和证明过的框架作为实施的基础部件,又在该基础上创建了一些非常优秀的边缘组件.如:

• Spring Cloud Config:配置管理工具
• Spring Cloud Netflix:核心组件,对多个Netflix OSS开源套件进行整合,如Eureke,Hystrix,Ribbon等.
• Spring Cloud Bus:事件,消息总线

Spirng Cloud的功能组件还有很多,此处不一一列举.