wordpress不用ftpseo问答

1. 案例介绍

1.1 需求

实现⼀个电商平台(不真实实现, 仅为演⽰)

⼀个电商平台包含的内容⾮常多, 以京东为例, 仅从⾸⻚上就可以看到巨多的功能

我们该如何实现呢? 如果把这些功能全部写在⼀个服务⾥, 这个服务将是巨⼤的.

巨多的会员, 巨⼤的流量, 微服务架构是最好的选择.

微服务应⽤开发的第⼀步, 就是服务拆分. 拆分后才能进⾏"各⾃开发"

1.2 服务拆分

服务拆分原则

微服务到底多⼩才算"微", 这个在业界并没有明确的标准. 微服务并不是越⼩越好, 服务越⼩, 微服务架构的优点和缺点都会越来越明显.

服务越⼩, 微服务的独⽴性就会越来越⾼, 但同时, 微服务的数量也会越多, 管理这些微服务的难度也会提⾼. 所以服务拆分也要考虑场景

拆分微服务—般遵循如下原则:

1. 单⼀职责原则

单⼀职责原则原本是⾯向对象设计中的⼀个基本原则, 它指的是⼀个类应该专注于单⼀功能. 不要存在多于⼀个导致类变更的原因.

在微服务架构中, ⼀个微服务也应该只负责⼀个功能或业务领域, 每个服务应该有清晰的定义和边界, 只关注⾃⼰的特定业务领域.

组织团队也是, ⼀个⼈专注做⼀件事情的效率远⾼于同时关注多件事情.
⽐如⼀个⼈同时管理和维护⼀份代码, 要⽐多个⼈同时维护多份代码的效率⾼

⽐如电商系统

2. 服务⾃治

服务⾃治是指每个微服务都应该具备⾼度⾃治的能⼒, 即每个服务要能做到独⽴开发, 独⽴测试, 独⽴构建, 独⽴部署, 独⽴运⾏.

以上⾯的电商系统为例，每⼀个微服务应该有⾃⼰的存储, 配置，在进⾏开发, 构建, 部署, 运⾏和测试时，并不需要过多关注其他微服务的状态和数据

⽐如企业管理

每个部分负责每个部⻔的事情, 并且尽可能少的受其他团队影响
研发部⻔只负责需求功能的开发, ⽽不负责需求⽂档的书写和UI的设计. 并且其他部⻔的⼈员变动, 流程变更, 也尽可能少的影响研发部⻔. 部⻔和部⻔之间尽可能⾃治.

3. 单向依赖

微服务之间需要做到单向依赖, 严禁循环依赖, 双向依赖

循环依赖: A -> B -> C ->A
双向依赖: A -> B, B -> A

如果⼀些场景确实⽆法避免循环依赖或者双向依赖, 可以考虑使⽤消息队列等其他⽅式来实现

服务拆分⽰例

⼀个完整的电商系统是庞⼤的, 当然这也不是咱们课程的重点, 咱们课程中重点关注如何使⽤SpringCloud解决微服务架构中遇到的问题.

以订单列表为例:

简单来看, 这个⻚⾯提供了以下信息:

1. 订单列表
2. 商品信息

根据服务的单⼀职责原则, 我们把服务进⾏拆分为: 订单服务, 商品服务

订单服务: 提供订单ID, 获取订单详细信息

商品服务: 根据商品ID, 返回商品详细信息.

2. 项目搭建

步骤图示
见我的 gitee 仓库代码