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接口保持业务逻辑的一致

领域模型的缺点：

• 对程序员要求比较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应
• 领域驱动建模要求对领域模型完全而透彻的了解，只给出一个用例实现步骤是无法得到领域模型的，这需要和领域专家充分讨论，错误的领域模型对项目的危害非常大，所以实现一个好的领域模型非常困难
• 对于简单的软件，使用领域模型，优点大才小用了