SpringCloud系列之一
SpringCloud整体认知与系统微服务化架构思考
1. SpringCloud和微服务架构的关系
SpringCloud是由Spring Framework直接挂牌的*项目,不是由开源社区生态打造,他是吸纳了很多优秀的框架整合出来,比如Netflix和Alibaba
可以说SpringCloud是一系列开源技术(组件)的集合,它是基于SpringBoot之上,将微服务领域的基础设施简化为一个个易于部署且配置简单的组件。
SpringCloud将各个组件通过抽象和改造,共同构建了一套生态体系
- 服务治理:Eureka、Nacos、Consul
- 负载均衡:Ribbon
- 服务调用:Feign
- 服务容错:Hystrix、Sentinel
- 配置中心:Config+Bus、Nacos
- 服务网关:Gateway、Zuul
- 调用链追踪:Sleuth(Sleuth+Zipkin+ELK)
- 消息驱动:Stream
2. SpringCloud组件来源介绍
-
Netflix
SpringCloud Netflix组件库依旧是SpringCloud中最受欢迎的项目
-
Alibaba
Nacos、Sentinel
-
Spring Open Source
这个应该是算是Spring自己的组织了
应用领域名称 | Netflix组件 | Alibaba组件 | Spring或其他开源厂商 |
---|---|---|---|
服务治理 | Eureka | Nacos、Dubbo(RPC) | Consul |
负载均衡 | Ribbon | Spring-Cloud-Loadbalancer | |
服务调用 | Feign(后划归openfeign) | ||
服务容错 | Hystrix+Turbine+Dashboard | Sentinel | |
限流 | Sentinel | Gateway支持网关限流 | |
服务网关 | Zuul | Gateway | |
配置管理 | Archaius | Nacos | Config |
消息总线 | Bus | ||
调用链追踪 | Sleuth | ||
消息驱动 | RocketMQ | Stream(对接RabbitMQ和Kafka) | |
任务调度 | Alibaba Cloud ScheduleX | spring-cloud-task | |
其他 | Slidecar(跨语言) | Seata(分布式事务) SMS(短信服务) |
3. SpringCloud的版本演进
- Angel 2015.3
- Brixton 2016.5
- Camden 2016.9
- Dalston 2017.4
- Edgware 2017.11
- Finchley 2018.6
- Greenwich 2019.1
- Hoxton 2019.11
SpringCloud版本升级的需要
- 业务需要
- 对当前业务是否有影响
- 上下游的兼容性
- 替换成本:开发资源,运维资源
- 技术需要
- 技术栈可扩展性
- Bug Fix及时性
- 新组件新功能能够支持新的业务场景有哪些要进行调研
Springcloud在项目技术栈的设计方式建议
- 半年/年度升级一次
- 只采用SR发布版,绝不冒进
- 对于新版本的新功能要持续关注,一旦有一些新功能对于你的系统有较大提升空间就可以尝试更新
- 更新后要进行全链路回归测试
4. 系统微服务的改造分析
拆?
- 拆分POM依赖项:每个POM只引入自己用到的依赖
- 公共组件的剥离:公共Utils类
- 平台中间件剥离:注册中心,配置中心
- 微服务模块拆分:根据业务粒度进行处理
核心的拆分工作就集中在微服务模块,通过领域模型来进行划分
进行领域模型划分前先弄明白两个概念:贫血模型、领域模型
-
贫血模型
实际开发工作中,80%都是贫血模型
所谓的贫血模型,是指Model中,仅包含属性,不包好行为(方法),采用这种设计是,需要分离出DB层(dao),专门用于数据库操作(数据库作为状态对象保存)
典型的结构:
po/bo/pojo:存放实体对象或持久化对象,仅包含属性和对应的Get/Set方法,没有行为方法
dao/mapper:存放数据库访问的方法
service:存放业务行为实现
controller:提供对UI层访问的入口或后端API入口
优点:
- 被许多程序员掌握,许多教材也是采用这种模型,适合入门
- 非常简单,易于理解,不需要对业务领域充分了解就可以开始开发
- 事务的边界相当清楚,一般来说可以将一个service看作是一个事务
缺点:
- 所有的业务都在service中处理,当业务越来越复杂时,service会变得越来越庞大,最终难以理解和维护
- 将所有业务放在无状态的service中实际是一个过程化的设计,他在组织复杂的业务时存在天然的劣势,随着业务的复杂度提升,业务会在service中多个方法间重复
- 当添加一个新的UI时,所有业务逻辑都得重写,导致重复的业务逻辑比较多,如何保持业务逻辑的一致是很大的挑战
-
领域模型
一般包括如下包结构
infrastructure:代表基础设施层,一般负责对象的持久化,基础服务,第三方工具,缓存,API网关服务,事件总线等
application:代表应用层,主要提供对UI层的统一访问接口,并作为事务界限。
domain:代表领域层,domain包含两个子包,分别是model和service,model中包含模型对象,Repository(DAO)接口,负责关键业务的逻辑。service包为一系列的领域服务,之所以需要servcie,按照DDD的观点,是因为领域中的某些概念本质是一些行为,并且不便于放入某个模型对象中的。
领域模型各层的逻辑如下:
领域模型的优点:
- 领域模型采用OO设计,通过职责分配到相依的模型对象或service,可以很好的组织业务逻辑,当业务变得复杂时,领域模型显出巨大的优势
- 当需要多个UI接口时,领域模型可以重用,并且各个业务逻辑只在领域中出现,这使得很容易对多个UI接口保持业务逻辑的一致
领域模型的缺点:
- 对程序员要求比较高,初学者对这种将职责分配到多个协作对象中的方式感到极不适应
- 领域驱动建模要求对领域模型完全而透彻的了解,只给出一个用例实现步骤是无法得到领域模型的,这需要和领域专家充分讨论,错误的领域模型对项目的危害非常大,所以实现一个好的领域模型非常困难
- 对于简单的软件,使用领域模型,优点大才小用了