写在前面
之所以开始学习SpringCloud是因为之前的开源项目需要搭建一个高可用的分布式服务正在想注册中心用什么去搞,参考了下zookeeper自己搭建以及etcd等开源的注册中心之后还是跟进一下潮流吧毕竟借此机会去接触一下SpringCloud(据说这东西学习成本极地拿来即用)
学习的目的
学习一件事情或者是一项技术都需要吧自己的目明确出来,毕竟程序员做事就是那么的直接有目的.
- 使基础服务实现高可用,可以通过docker统一部署统一管理,使用spring的healty等指标为我的大数据分析平台进行监控
就这就么一个简单low逼得目的我开始了学习SpringCloud
讲讲什么是微服务
简单点来说就是将单一的程序开发成一组小程序去运行部署,微服务应该具有以下特性:
- 每个微服务可以独立部署在自己的进程里.
- 一系列独立运行的微服务共同构建整个系统
- 每个微服务为独立的业务开发,一个微服务只关注摸个特定的功能,列入订单管理用户管理等.
- 微服务之间通过一些轻量级的通信机制进行通信,例如通过RESTful API进行通信
- 可以使用不同的语言以及数据库存储技术
- 全自动的部署机制
说说微服务的优缺点
优点:
- 已与开发和维护:一个微服务只关注一个特定的业务功能,他的业务清晰,打码量少.开发和维护单个服务相对很简单.
- 单个服务启动快:代码量少启动快.
- 局部修改容易部署:由于服务是单体分离的所以方便独立部署修改.
- 技术站不受限制:微服务中个个服务可以独立部署所以可以使用很多不同的技术,只需要关心服务之间的通信就可以了.
- 按需求伸缩:这也是微服务的一大亮点,可以快速的部署并且某些关键模块可以按照需求的大小按量的去伸缩.
缺点:
- 运维要求比较高:更多的服务需要统一的管理,服务之间的调度也需要很好的协调.
- 分布式固有的复杂性:系统的容错性,网络的延迟,分布式的事务管理.
- 接口调整成本高:如果需要调整一个借口可能整个服务(多个服务)的API接口都需要调整.
- 重复劳动:有的时候很多服务会有很多相近的功能不能单独的抽出来这个时候就需要在不同的服务里重复的去写.
微服务的设计原则
和数据库的设计N范式一样,微服务也有一定的设计原则,这些原则知道我们更加合理的实际微服务.
- 单一职责原则
- 单一职责指的是一个单元(类,方法或服务等)只关注整个系统功能中,单独的有界限的一部分.
- 服务自治原则
- 服务自治是指没个微服务应具有独立的业务能力,依赖于运行环境,在微服务架构中服务式独立的业务单元,与其他服务高度解耦,没个微服务从开发测试构部署都是独立的.
- 轻量级的通讯机制
- 轻量级的通信应该具备服务的调用应该是跨平台跨语言的如RESTful协议
- 微服务粒度
- 微服务的粒度是难点,也常常是争论的焦点.应当使用合理的粒度划分微服务,而不是一味地把服务做小.代码量的多少不能作为微服务划分的一句,因为不同的微服务本身的业务复杂性是不同的.
- 我们在划分微服务的时候可以使用领域驱动(Domain Driven Design 简称DDD),可以作为划分微服务的边界,确定微服务里的的重要依据.
技术选型
相对单题应用的交付,微服务和应用的交付要复杂很多,不仅需要开发框架的支持,还需要一些自动化部署工具的支持.如Jenkins等,可以从两个方向来考虑技术选型:
- 开发框架选择
- 可以使用Spring Cloud作为微服务开发框架
- Spring Cloud具有开箱即用的特性,可以大大的提高开发效率;再者Spring Cloud的文档丰富,社区活跃,遇到问题比较容易支持;更为可贵的是Spring Cloud位微服务架构提供了完整的解决方案.
- 运行平台
- 微服务并不绑定运行平台,将为服务部署在PC Server或者是阿里云,等平台都是可以的.出于轻量考虑我选择的是将Spring Cloud部署到Docker上
一个简单的微服务框架图
Spring Cloud特点
- 约定由于配置
- 适合各种环境.开发,部署在各种环境
- 隐藏了组件的复杂性,提供声明式配置方式
- 开箱即用
- 总之就是上手比较容易(前提是有使用过SpirngBoot的经验,以及了解各组件的实现功能)