【SpringCloud】环境和工程搭建
环境和工程搭建
- 1. 案例介绍
- 1.1 需求
- 1.2 服务拆分
- 服务拆分原则
- 服务拆分⽰例
1. 案例介绍
1.1 需求
实现⼀个电商平台(不真实实现, 仅为演⽰)
⼀个电商平台包含的内容⾮常多, 以京东为例, 仅从⾸⻚上就可以看到巨多的功能
我们该如何实现呢? 如果把这些功能全部写在⼀个服务⾥, 这个服务将是巨⼤的.
巨多的会员, 巨⼤的流量, 微服务架构是最好的选择.
微服务应⽤开发的第⼀步, 就是服务拆分. 拆分后才能进⾏"各⾃开发"
1.2 服务拆分
服务拆分原则
微服务到底多⼩才算"微", 这个在业界并没有明确的标准. 微服务并不是越⼩越好, 服务越⼩, 微服务架构的优点和缺点都会越来越明显.
服务越⼩, 微服务的独⽴性就会越来越⾼, 但同时, 微服务的数量也会越多, 管理这些微服务的难度也会提⾼. 所以服务拆分也要考虑场景
拆分微服务—般遵循如下原则:
- 单⼀职责原则
单⼀职责原则原本是⾯向对象设计中的⼀个基本原则, 它指的是⼀个类应该专注于单⼀功能. 不要存在多于⼀个导致类变更的原因.
在微服务架构中, ⼀个微服务也应该只负责⼀个功能或业务领域, 每个服务应该有清晰的定义和边界, 只关注⾃⼰的特定业务领域.
组织团队也是, ⼀个⼈专注做⼀件事情的效率远⾼于同时关注多件事情.
⽐如⼀个⼈同时管理和维护⼀份代码, 要⽐多个⼈同时维护多份代码的效率⾼
⽐如电商系统
2. 服务⾃治
服务⾃治是指每个微服务都应该具备⾼度⾃治的能⼒, 即每个服务要能做到独⽴开发, 独⽴测试, 独⽴构建, 独⽴部署, 独⽴运⾏.
以上⾯的电商系统为例，每⼀个微服务应该有⾃⼰的存储, 配置，在进⾏开发, 构建, 部署, 运⾏和测试时，并不需要过多关注其他微服务的状态和数据
⽐如企业管理
每个部分负责每个部⻔的事情, 并且尽可能少的受其他团队影响
研发部⻔只负责需求功能的开发, ⽽不负责需求⽂档的书写和UI的设计. 并且其他部⻔的⼈员变动, 流程变更, 也尽可能少的影响研发部⻔. 部⻔和部⻔之间尽可能⾃治.
3. 单向依赖
微服务之间需要做到单向依赖, 严禁循环依赖, 双向依赖
循环依赖: A -> B -> C ->A
双向依赖: A -> B, B -> A
如果⼀些场景确实⽆法避免循环依赖或者双向依赖, 可以考虑使⽤消息队列等其他⽅式来实现
服务拆分⽰例
⼀个完整的电商系统是庞⼤的, 当然这也不是咱们课程的重点, 咱们课程中重点关注如何使⽤SpringCloud解决微服务架构中遇到的问题.
以订单列表为例:
简单来看, 这个⻚⾯提供了以下信息:
- 订单列表
- 商品信息
根据服务的单⼀职责原则, 我们把服务进⾏拆分为: 订单服务, 商品服务
订单服务: 提供订单ID, 获取订单详细信息
商品服务: 根据商品ID, 返回商品详细信息.
